Accessibility

Last updated: February 8, 2026

Our Commitment

Accessibility is a core principle at Slate, not an afterthought. Our team spent years customizing enterprise content management systems for learning and development, with a significant focus on templates, theming, and the accessibility of course outputs serving tens of thousands of learners.

We believe every learner deserves equal access to educational content. Slate is built to give course creators the tools and structure to produce accessible eLearning experiences by default, while providing the flexibility to go further.

Course Architecture

Slate courses are single-page applications. All content loads within a single HTML document, and navigation between lessons is handled by JavaScript without page reloads. This architecture provides several accessibility benefits:

  • Consistent landmarks and heading structure across the entire course experience
  • No page reloads that could disrupt assistive technology state or lose context
  • The course title (H1) anchors the document at all times, while lesson titles (H2) update as learners navigate
Slate theme settings showing layout options, logo upload, border radius and spacing controls, with a live course preview
Theme settings with live preview. Courses inherit accessible structure regardless of visual customization.

What Slate Provides

Every course built with Slate includes the following accessibility features automatically, with no additional effort required from the author.

Enforced Heading Hierarchy

Slate enforces a correct document outline in every course. The course title is always H1, lesson titles are H2, and authors are restricted to H3–H6 for content headings. This ensures screen readers can navigate the document structure reliably.

Responsive Visibility

Content blocks can be configured as mobile-only, desktop-only, or visible on both. When content is hidden for a given viewport, it is properly excluded from the accessibility tree. Screen readers only encounter content that is visible at the current screen size.

Keyboard Navigation

All interactive elements in the course player are fully keyboard accessible. Learners can navigate using Tab, Enter, Space, and Arrow keys. This includes lesson navigation, accordions, tabs, carousels, knowledge checks, and assessments.

ARIA Landmarks and Roles

The player uses semantic HTML5 landmarks (header, nav, main, footer) and appropriate ARIA roles for interactive components including tab panels, accordions, dialogs, and form controls.

Screen Reader Support

Descriptive aria-labels are provided on all icon-only buttons. Live regions announce dynamic content updates such as search results and quiz feedback. Visually hidden content (sr-only) provides additional context where needed, such as the course title when a logo is displayed.

Audio Narration

Content blocks support optional audio narration with a built-in player featuring play, pause, and progress controls. All narration controls are keyboard accessible and include appropriate aria-labels for screen readers.

Document Block Accessibility

Document blocks include title and description fields that provide context for downloadable files. These fields ensure screen readers can convey the purpose of attached documents without relying solely on file names.

Focus Management

Visible focus indicators are displayed on all interactive elements using the :focus-visible standard. Focus is managed appropriately when navigating between lessons and interacting with modals and forms.

Skip Navigation

A skip-to-content link is included at the top of every course, allowing keyboard users to bypass the navigation and jump directly to the lesson content.

Reduced Motion

Slate respects the prefers-reduced-motion operating system setting. When enabled, animations and transitions are disabled throughout the course player.

Color Contrast

The default color palette meets WCAG AA contrast requirements. All text and interactive elements maintain sufficient contrast ratios against their backgrounds.

Form Accessibility

All form inputs include proper labels, required field indicators, and error messages that are announced to screen readers via ARIA live regions.

Responsive Design

Courses adapt to all viewport sizes, from mobile devices to large desktop displays, ensuring content remains accessible regardless of how learners access it.

SCORM Exports

All accessibility features are included in SCORM exports. Courses deployed to any SCORM-compatible LMS retain the full set of keyboard navigation, screen reader support, and semantic structure.

Authoring Best Practices

While Slate provides a strong accessible foundation, course creators play an important role in ensuring their content is accessible to all learners. We recommend the following practices:

  • Use descriptive alt text on images. Every image block includes an alt text field. Describe the content and purpose of the image for learners who cannot see it.
  • Structure content with headings. Use the available heading levels (H3–H6) to create a logical content hierarchy within your lessons.
  • Ensure sufficient color contrast. When customizing themes, verify that text remains readable against background colors.
  • Provide captions and transcripts. For video and audio content, upload SRT or VTT subtitle files to provide text alternatives. Slate includes built-in support for subtitle file uploads on video and audio blocks.
  • Use meaningful link text. Avoid generic labels like "click here" or "read more." Instead, describe where the link leads.
  • Keep content well-structured. Use short paragraphs, lists, and clear language to make content easier to follow for all learners.

Custom Code Blocks

Slate includes a code block type that allows authors to inject custom HTML, CSS, and JavaScript into their courses. This provides powerful flexibility for creating bespoke interactive experiences, but it operates outside the boundaries of what Slate can control.

Slate cannot validate or enforce accessibility standards within custom code blocks. Authors who use this feature are responsible for ensuring their custom content meets accessibility requirements. We recommend:

  • Testing custom blocks with a keyboard (can all elements be reached and activated?)
  • Testing with a screen reader (is content announced clearly?)
  • Using semantic HTML elements rather than generic divs and spans
  • Including appropriate ARIA attributes on interactive elements
  • Ensuring sufficient color contrast in custom styles

Standards

Slate targets conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. We continuously evaluate and improve our platform against these guidelines.

Feedback

We welcome feedback on the accessibility of Slate courses and the authoring platform itself. If you encounter an accessibility barrier or have suggestions for improvement, please .