Accessibility
Foundations
Accessibility means designing digital content so that people with disabilities can perceive, understand, navigate, and interact with it effectively. It is not a feature to add at the end — it is a design constraint that shapes every decision from the start.
This site is built for instructional designers, learning experience designers, and L&D professionals who create digital learning content — courses, job aids, documentation, presentations — and want to build it accessibly.
You don't need to be a developer. The principles, standards, and patterns on this site apply whether you're writing HTML, configuring an authoring tool, reviewing a vendor's output, or writing a requirements document that someone else will build from.
Every WCAG success criterion maps to one of four principles. Together, they define the minimum conditions for digital content to be accessible.
Perceivable
Information and user interface components must be presentable in ways users can perceive. Nothing can be invisible to all of a user's senses.
Images need alt text. Videos need captions. Text needs sufficient contrast. Content must not rely solely on color to convey meaning.
Experience vision barriers →Operable
User interface components and navigation must be operable by everyone. No interaction should require a specific input device.
All functionality must be available via keyboard alone. Focus indicators must be visible. Touch targets must be at least 24×24px. No content should cause seizures.
Experience motor barriers →Understandable
Information and the operation of the user interface must be understandable. Content must be readable, predictable, and users must be helped to avoid and correct mistakes.
Pages must declare their language. Form inputs need visible labels. Error messages must describe the problem and suggest a fix. Navigation must be consistent across pages.
Experience cognitive barriers →Robust
Content must be robust enough to be reliably interpreted by a wide variety of user agents, including current and future assistive technologies.
Use semantic HTML (button, not div). All interactive components must expose name, role, and state. Status messages must be announced programmatically.
See code patterns →When a browser parses HTML, it builds two parallel structures: the visual DOM (what you see) and the accessibility tree (what assistive technology reads). Screen readers, voice control software, and switch devices navigate exclusively through the accessibility tree.
The accessibility tree retains only three things about each element: its role (what it is), its name (what it's called), and its state (its current condition). Toggle between the three views below to see how a simple search form appears in each layer.
This is what a sighted user sees. Switch to HTML to see the markup, or Tree to see what a screen reader sees.
Now that you understand the framework, explore the site: