Web Accessibility interview questions

What a strong answer covers

• List the four principles: Perceivable, Operable, Understandable, Robust (POUR).
• Explain 'Perceivable' as content being available to senses (e.g., text alternatives for non-text content).
• Explain 'Operable' as UI components and navigation being usable (e.g., keyboard accessibility).
• Explain 'Understandable' as information and UI operation being clear and predictable.
• Explain 'Robust' as content being interpretable by various user agents, including assistive technologies.

Where people lose the point

• ×Forgetting one or more of the POUR principles.
• ×Providing vague or incorrect explanations for each principle.
• ×Confusing the principles with specific WCAG guidelines or success criteria.

What a strong answer covers

• Explain that `alt` text provides a textual description of an image for users who cannot see it (e.g., screen reader users, broken images).
• State its importance for conveying information, context, and functionality.
• Describe good `alt` text as concise, descriptive, and conveying the image's purpose or content.
• Mention avoiding phrases like 'image of' or 'picture of' and ensuring it's not redundant if text nearby already describes the image.

Where people lose the point

• ×Providing `alt` text that is too long or too short to be useful.
• ×Using `alt` text for decorative images instead of an empty `alt=""` attribute.
• ×Focusing only on screen readers and forgetting other use cases like broken images or text-only browsers.

What a strong answer covers

• State that semantic HTML provides inherent meaning and structure to content.
• Explain how this meaning is conveyed to assistive technologies (like screen readers) without extra effort.
• Mention that semantic elements often come with built-in accessibility features (e.g., keyboard interaction for `<button>`).
• Contrast this with non-semantic elements (like `<div>`) which require ARIA and JavaScript to achieve the same accessibility.

Where people lose the point

• ×Focusing only on SEO benefits rather than accessibility benefits.
• ×Failing to explain *how* semantic HTML helps assistive technologies.
• ×Suggesting that semantic HTML completely eliminates the need for ARIA.

What a strong answer covers

• Explain that `tabindex="0"` makes an element focusable via keyboard in its natural tab order.
• State that it's used for non-interactive elements (like `<div>` or `<span>`) that need to receive focus.
• Provide examples such as making custom controls focusable or allowing users to focus on static content that becomes interactive.
• Emphasize that it should be used sparingly and only when a native interactive element isn't suitable.

Where people lose the point

• ×Confusing `tabindex="0"` with `tabindex="-1"` or positive `tabindex` values.
• ×Suggesting it's a replacement for using native interactive elements like `<button>` or `<a>`.
• ×Not mentioning the importance of its natural tab order behavior.

What a strong answer covers

• State the 'first rule of ARIA': If a native HTML element or attribute already provides the semantic meaning and behavior you need, use it instead of ARIA.
• Explain that native HTML elements have built-in accessibility features that are robust and widely supported.
• Provide an example: Using `<button>` instead of a `<div>` with `role="button"` and `tabindex="0"`.
• Elaborate on why the native element is superior (e.g., keyboard interaction, focus management, browser support).

Where people lose the point

• ×Incorrectly stating the rule or misinterpreting its meaning.
• ×Providing an example where ARIA is actually necessary, rather than where native HTML suffices.
• ×Failing to explain *why* native HTML is preferred over ARIA in such cases.

What a strong answer covers

• Explain that color contrast refers to the difference in luminance between foreground (text) and background colors.
• State the WCAG AA minimum contrast ratios: 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold).
• Mention the AAA level (7:1 for normal text) as an enhanced goal.
• Explain its importance for users with low vision, color blindness, or in challenging viewing conditions (e.g., bright sunlight) to ensure readability.
• Note that contrast applies to meaningful graphical objects and UI components, not just text.

Where people lose the point

• ×Forgetting the specific contrast ratios for AA compliance.
• ×Not mentioning the distinction between normal and large text.
• ×Failing to explain *why* color contrast is important for different user groups.

What a strong answer covers

• Explain that focus must be trapped within the modal when it's open, preventing users from tabbing to background content.
• Describe how to programmatically move focus to the first interactive element inside the modal when it opens.
• Explain that focus should return to the element that triggered the modal when it closes.
• Mention using `aria-modal="true"` and `aria-labelledby` to associate the modal with its title for screen readers.
• Discuss handling keyboard interactions like `Escape` to close the modal.

Where people lose the point

• ×Forgetting to return focus to the triggering element after the modal closes.
• ×Not mentioning the need to trap focus within the modal.
• ×Overlooking the importance of keyboard interaction (e.g., Escape key to close).

What a strong answer covers

• Define a 'skip link' as an invisible link (usually at the top of the page) that becomes visible on focus.
• Explain its purpose: to allow keyboard and screen reader users to bypass repetitive navigation or header content.
• State that it jumps directly to the main content area of the page.
• Highlight its importance for improving efficiency and reducing frustration for users who navigate sequentially.

Where people lose the point

• ×Incorrectly describing the visual behavior of a skip link (e.g., always visible).
• ×Failing to explain *who* benefits most from skip links and *why*.
• ×Confusing skip links with internal page anchors for general navigation.

What a strong answer covers

• Explain that dynamic content updates often go unnoticed by screen readers unless explicitly announced.
• Introduce `aria-live` regions (`aria-live="polite"` or `aria-live="assertive"`) to inform screen readers of changes.
• Describe `aria-live="polite"` for non-urgent updates (e.g., search results, stock tickers) that don't interrupt the user.
• Describe `aria-live="assertive"` for urgent, time-sensitive updates (e.g., error messages, critical status changes) that interrupt immediately.
• Mention `role="status"` or `role="alert"` as specific live region roles.

Where people lose the point

• ×Confusing `polite` and `assertive` live region behaviors.
• ×Suggesting that all dynamic content needs `aria-live` (only meaningful, non-focus-driven changes).
• ×Not mentioning the importance of placing the `aria-live` attribute on a stable container element.

What a strong answer covers

• Emphasize using the `<label>` element and associating it explicitly with its form control using `for` and `id` attributes.
• Explain that explicit association ensures screen readers announce the label when the control receives focus.
• Mention that clicking the label should activate the associated control, improving usability for all users.
• Discuss avoiding placeholder text as a substitute for labels, as it disappears on input and lacks persistent context.
• Suggest providing clear, concise, and descriptive labels for all form fields.

Where people lose the point

• ×Suggesting `placeholder` text is an adequate substitute for a `<label>` element.
• ×Forgetting the `for`/`id` association and relying only on visual proximity.
• ×Not mentioning the benefit of clicking the label to activate the control.

What a strong answer covers

• Explain that SPAs don't trigger full page reloads, so screen readers don't automatically announce new page titles or content changes.
• Describe the need to programmatically update the document title (`document.title`) to reflect the new 'page'.
• Explain the importance of programmatically moving focus to the main content area of the new 'page' after a route change.
• Mention using `aria-live` regions for dynamic content within the SPA that changes without a route update.
• Discuss ensuring all interactive elements in the new view are keyboard accessible and have visible focus indicators.

Where people lose the point

• ×Forgetting to update the document title, which is crucial for screen reader users to understand context.
• ×Not moving focus to the new content, leaving screen reader users disoriented.
• ×Assuming browser history management automatically handles accessibility for SPAs.

What a strong answer covers

• **ARIA Attributes:** Use `role="combobox"` for the input/trigger, `aria-haspopup="listbox"` to indicate a popup, `aria-expanded` to show open/closed state, `aria-controls` to link to the listbox, `role="listbox"` for the dropdown container, `role="option"` for each item, and `aria-selected` for the currently selected option.
• **Keyboard Interactions:** Implement `Tab` to move focus into and out of the component, `Enter`/`Space` to open/close the dropdown and select an option, `Up`/`Down` arrows to navigate options within the open dropdown.
• **Focus Management:** Ensure focus is managed correctly when opening/closing the dropdown and when navigating options.
• **Visual Cues:** Provide clear visual focus indicators for the trigger and each option.
• **Escape Key:** Allow `Escape` to close the dropdown without selecting an option.

Where people lose the point

• ×Missing critical ARIA attributes like `aria-expanded` or `role="listbox"`.
• ×Failing to implement essential keyboard interactions (e.g., arrow keys for navigation).
• ×Not considering focus management when the dropdown opens or closes, or when an option is selected.

What a strong answer covers

• **Automated Testing:** Integrate tools like Axe DevTools, Lighthouse, or WAVE into CI/CD pipelines and development workflows to catch common, easily detectable issues early.
• **Manual Keyboard Testing:** Systematically navigate the entire application using only the keyboard to check tab order, focus indicators, and operability of all interactive elements.
• **Screen Reader Testing:** Test with at least one popular screen reader (e.g., NVDA on Windows, VoiceOver on macOS) to understand the user experience for visually impaired users.
• **Color Contrast & Zoom Testing:** Manually verify color contrast for critical elements and test page responsiveness at various zoom levels (up to 200%).
• **User Testing:** Conduct testing with actual users with diverse disabilities to gain invaluable real-world feedback and uncover issues missed by other methods.

Where people lose the point

• ×Relying solely on automated testing and believing it covers all accessibility issues.
• ×Omitting manual keyboard or screen reader testing, which are crucial for operability and perception.
• ×Not mentioning the importance of testing with actual users with disabilities.

What a strong answer covers

• **When to use ARIA:** When native HTML elements lack the semantic meaning or behavior required for complex UI components (e.g., custom sliders, tree views, tab panels) or dynamic content updates.
• **When to use ARIA:** To enhance the accessibility of existing HTML elements that are not inherently accessible (e.g., adding `aria-label` to an icon-only button).
• **Potential Pitfalls:** Overusing ARIA when native HTML suffices (violating the first rule of ARIA), leading to redundant or conflicting semantics.
• **Potential Pitfalls:** Incorrectly implementing ARIA, which can break accessibility rather than improve it (e.g., wrong roles, missing states).
• **Potential Pitfalls:** ARIA only adds semantics; it doesn't provide behavior. Developers must still implement keyboard interaction and focus management with JavaScript.

Where people lose the point

• ×Suggesting ARIA is a replacement for semantic HTML rather than a supplement.
• ×Failing to mention that ARIA doesn't automatically provide behavior (e.g., keyboard interaction).
• ×Not highlighting the risk of *degrading* accessibility through incorrect ARIA usage.

What a strong answer covers

• **Visual Cues:** Provide clear, visible error messages near the relevant form field, using more than just color (e.g., text, icons).
• **Programmatic Association:** Link error messages to their respective form fields using `aria-describedby` to ensure screen readers announce the error when the field is focused.
• **Live Regions:** Use `aria-live="assertive"` on a container for general form submission errors to announce them immediately to screen reader users.
• **Focus Management:** Programmatically move focus to the first erroneous field upon form submission to guide users directly to the problem.
• **Clear Instructions:** Provide clear, actionable instructions on how to correct the error.

Where people lose the point

• ×Relying solely on visual cues (like red text) without programmatic association or live region announcements.
• ×Forgetting to move focus to the first error, forcing screen reader users to search for it.
• ×Providing vague error messages that don't clearly explain the problem or how to fix it.