♿ Accessibility & Inclusive Design Language
6 exercise sets. Master the vocabulary for WCAG conformance, ARIA patterns, accessibility audits, and inclusive design advocacy.
WCAG Vocabulary
Perceivable, Operable, Understandable, Robust — core WCAG principles and conformance levels vocabulary.
ARIA Language
ARIA roles, states, properties, landmarks — vocabulary for discussing accessible rich internet applications.
Accessibility Audit Vocabulary
Audit findings language: WCAG success criterion, violation, remediation, axe report vocabulary.
Assistive Technology Vocabulary
Screen readers, keyboard navigation, magnification, captions — vocabulary for discussing assistive technologies.
Inclusive Design Language
Inclusive design vocabulary: designing for the margins, permanent vs. temporary vs. situational disability, design justice.
Accessibility Advocacy Language
Arguing for accessibility investment: business case vocabulary, legal risk (ADA, EAA), cost of retrofitting.
Frequently Asked Questions
What's the difference between ARIA attributes like `aria-label` and plain text labels for screen readers?
ARIA attributes provide semantic information to assistive technologies, essentially describing roles and states of elements that aren't inherently obvious. Plain text labels offer a more direct, human-readable description directly associated with the content, which is often preferred by users who rely solely on screen readers for navigation and understanding. Using both provides redundancy and caters to different user preferences.
I'm using `role='dialog'` – how do I correctly use `aria-modal` to ensure the dialog is focused appropriately?
`aria-modal='true'` signals to screen readers that the dialog is a modal window, preventing focus from being trapped within it and allowing users to navigate back to the main content. This attribute ensures keyboard navigation works predictably and doesn't get stuck within the dialog itself; it's crucial for usability.
When should I use `aria-expanded` versus `aria-hidden='true'` on a collapsible element?
`aria-expanded='true'` indicates whether the content within the collapsed state is currently visible, allowing screen readers to accurately convey this status. Conversely, `aria-hidden='true'` hides the visual representation of the element from sighted users while still providing its semantic role for assistive technology; they serve distinct purposes.
How does using `role='alert'` affect how a screen reader announces an error message?
`role='alert'` specifically instructs screen readers to announce the alert as important information requiring immediate attention, often with a higher priority in the reading order. This is distinct from other roles like `role='status'`, which are for informational messages that don't necessarily demand immediate action.
Can I use ARIA attributes to create custom keyboard navigation patterns beyond basic tab ordering?
Yes, you can utilize ARIA attributes like `aria-keyshortcuts` and `role='menubar'` to define complex keyboard interactions for custom UI elements. However, ensure that your implementation is thoroughly tested with screen readers to verify the navigation is intuitive and doesn't introduce confusion.
What's the best practice when implementing `aria-describedby` in a form?
`aria-describedby` links an element to another element that provides additional context or information, such as a help text field. This is particularly useful for complex form fields where providing clear instructions via ARIA enhances accessibility and reduces user confusion.
I'm using `role='region'` – what are the recommended regions to use and how do I define them?
`role='region'` groups related content into logical areas, allowing screen readers to present information in a more organized manner (e.g., 'navigation', 'main', 'footer'). Defining these regions correctly helps users understand the overall structure of the page.
How does ARIA impact semantic HTML5 elements like `<article>` and `<nav>`?
While using ARIA with semantic HTML5 elements is possible, it's often redundant if the elements are correctly implemented. ARIA primarily enhances accessibility for custom or complex controls that don't have inherent semantics, not replacing well-structured semantic HTML.
What's the role of `aria-live` when dynamically updating content on a page?
`aria-live='polite'` indicates that screen readers should be notified of changes to the associated element, but without interrupting the user's current navigation. `aria-live='assertive'` forces a screen reader to immediately announce the change, useful for critical updates like error messages.
How do I correctly use `aria-label` when an image lacks alternative text (alt attribute)?
When no meaningful `alt` text exists, using `aria-label` provides a descriptive label for the image that screen readers can announce. The `aria-label` should accurately describe the purpose or content of the image to ensure users understand its role within the page.