Web Accessibility (a11y) Standards Interview Preparation Guide

WCAG AA is the standard legal baseline required by most global regulations (such as the ADA and EAA), requiring a 4.5:1 contrast ratio for normal text, keyboard accessibility, and basic ARIA support. WCAG AAA represents the highest and most stringent tier of accessibility, demanding a 7:1 contrast ratio, sign language interpretations for audio content, and advanced context-specific help. Reaching AAA across an entire complex web application is often impractical or impossible, which is why AA remains the universal target for enterprise compliance.

You should always follow the first rule of ARIA: use native HTML elements whenever an equivalent element exists. For example, use a native <button> instead of a <div role='button'>. Native elements come with built-in keyboard navigation, focus management, and screen reader semantics out of the box. ARIA attributes and roles should be reserved strictly for complex custom widgets (such as comboboxes, tree views, and sliders) where native HTML equivalents do not exist or lack necessary state communication capabilities.

Screen readers do not parse raw HTML source code or rendered CSS pixels directly. Instead, the browser engine translates HTML, CSS, and JavaScript into an Accessibility Tree via platform-specific accessibility APIs (such as NSAccessibility on macOS or UI Automation on Windows). Assistive technologies query this Accessibility Tree to read semantic roles, states, and properties. This architectural separation means developers must ensure their DOM modifications accurately update the Accessibility Tree rather than just visual pixels.

A focus trap is a programmatic mechanism that confines keyboard focus within a specific container element, such as an open modal dialog or dropdown menu. When a user tabs past the last focusable element inside the modal, the focus trap cycles focus back to the first element, preventing keyboard and screen reader users from tabbing out into background content. Without a focus trap, users get lost in the background DOM, destroying the usability of modal overlays.

ARIA live regions are specialized markup containers (using aria-live='polite' or 'assertive') that instruct screen readers to announce dynamic content updates that happen outside of user focus. Use 'polite' for non-urgent background updates, toast notifications, and search results; the screen reader waits until the user finishes their current sentence before speaking. Use 'assertive' sparingly for critical, time-sensitive errors or emergency warnings that require immediate interruption of current speech output.

Automated accessibility linters only scan static DOM states and code structure, catching roughly 30% to 50% of WCAG criteria. They cannot evaluate subjective human requirements such as logical reading order, whether alt text accurately describes an image's context, intuitive keyboard navigation flows, or whether screen reader announcements make sense during complex workflows. Achieving true compliance requires combining automated CI/CD checks with mandatory manual keyboard testing and screen reader audits.

Duplicate announcements usually happen when an input field has both a visible <label> and an aria-label or aria-labelledby attribute that repeats or conflicts with the label text. When multiple labeling mechanisms are present, screen readers may concatenate them or read them twice. To prevent this, ensure an input uses a single clear labeling source, preferring native associated <label> elements whenever possible.

Both CSS properties (visibility: hidden and display: none) remove the affected DOM nodes from the accessibility tree, meaning screen readers will ignore them entirely. However, display: none removes the element from the render layout flow completely, whereas visibility: hidden reserves its layout space on the page while hiding it visually. Neither should be used if content needs to remain accessible to screen readers while hidden visually; for that, the specialized .sr-only utility pattern must be used.

A roving tabindex is a keyboard navigation pattern used for composite widgets like tab lists or toolbars where only one item in the group is in the tab order at any given time (tabindex='0'), while all other sibling items have tabindex='-1'. When the user presses arrow keys, JavaScript programmatically moves tabindex='0' to the newly focused sibling and shifts focus, allowing efficient arrow-key navigation without forcing users to tab through every single sub-item.

In traditional multi-page websites, navigating to a new URL causes a full browser page load, which automatically resets focus to the top of the new document. In SPAs, route transitions happen asynchronously via JavaScript without a full reload, leaving keyboard focus lingering on the old navigation link. If engineers do not programmatically move focus to the new page heading and update live regions upon route change, screen reader users remain disoriented and unaware that new content has loaded.

Failing WCAG compliance exposes organizations to severe legal risks, including class-action lawsuits under the Americans with Disabilities Act (ADA), regulatory fines under the European Accessibility Act (EAA), and the loss of lucrative government and enterprise contracts. From a business perspective, poor accessibility alienates millions of potential users with disabilities, resulting in lost revenue and brand damage. Proactive accessibility engineering mitigates these risks while improving overall code quality.