21 Web Accessibility Interview Questions

Accessibility interview answers should connect standards to real user tasks. Naming an ARIA attribute is not enough: explain the native baseline, keyboard behavior, focus, visual presentation, assistive-technology output, and how you verified the result.

This guide contains 21 questions grounded in WCAG 2.2, HTML, and WAI-ARIA. It is technical guidance, not a legal opinion; applicable laws, contracts, versions, scopes, and deadlines vary by product and jurisdiction.

Table of Contents

1. Accessibility Fundamentals
2. Semantic HTML
3. ARIA
4. Keyboard Navigation
5. Accessible Forms
6. Dialog and Focus Management
7. Testing

Accessibility Fundamentals

1. What is web accessibility and why does it matter?

Web accessibility means designing and building content and interactions so people with disabilities can perceive, understand, navigate, and operate them. Disability and access needs are diverse: users may rely on a screen reader, magnification, reflow, captions, voice input, a keyboard, a switch, reduced motion, high-contrast settings, or clear and consistent language.

Accessibility is part of product quality. It affects whether someone can learn, work, buy, communicate, or complete a public-service task. It can also be required by laws, procurement rules, and contracts, but WCAG is a technical standard rather than a universal statement of legal compliance. Ask which jurisdiction, product, content, and standard version apply; involve qualified counsel for legal conclusions.

Do not justify accessibility only through SEO or litigation. Search engines and assistive technologies sometimes benefit from the same sound structure, but ranking and accessibility are different goals.

2. What are WCAG principles and conformance levels?

WCAG 2.2 is a W3C Recommendation organized under four principles: perceivable, operable, understandable, and robust (POUR). Guidelines sit under those principles, and testable success criteria have levels A, AA, or AAA.

Conformance levels are cumulative:

• Level A requires every applicable A success criterion;
• Level AA requires every applicable A and AA criterion;
• Level AAA requires every applicable A, AA, and AAA criterion.

Conformance is evaluated for complete web pages and, where a process spans pages, the complete process. It also includes requirements such as accessibility-supported ways of using technologies and non-interference. Passing a few examples or reaching a tool score is not “AA compliant.” W3C does not recommend requiring Level AAA for an entire site because some content cannot meet every AAA criterion.

3. What changed in WCAG 2.2, and what does Level AA cover?

WCAG 2.2 adds nine criteria to WCAG 2.1 and marks 4.1.1 Parsing obsolete. New AA criteria include Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum); new A criteria include Consistent Help and Redundant Entry.

AA also includes many earlier requirements, such as:

• 4.5:1 contrast for normal text and 3:1 for large text, subject to stated exceptions;
• 3:1 contrast for relevant non-text UI components and graphical objects, subject to exceptions;
• keyboard operation, visible focus, meaningful sequence, labels, error identification, captions, zoom, and reflow;
• content remaining usable at 200% text resize and at the reflow viewport defined by the criterion.

Do not treat those examples as a checklist of all AA requirements. Use the WCAG 2.2 Quick Reference, define the page/process scope, and record how every applicable criterion was evaluated. A law or contract may still explicitly require WCAG 2.1 AA, so follow that normative reference while using 2.2 improvements where possible.

Semantic HTML

4. What is semantic HTML and why is it important?

Semantic HTML uses the native element whose meaning matches the content or control: headings for headings, links for navigation, buttons for actions, lists for lists, tables for tabular relationships, and labeled controls for form input.

Browsers map native semantics into accessibility APIs and usually provide expected focus and keyboard behavior. This creates a stronger baseline and reduces custom code. It does not guarantee accessibility: headings can still be unclear, a button can lack an accessible name, DOM order can be confusing, and CSS can hide focus or fail at zoom.

5. How does semantic markup compare with “div soup”?

A generic div carries no button, link, heading, list, or landmark semantics. Compare the accessibility tree and interaction contract, not merely the visual result:

<!-- Generic containers and pointer-only handlers -->
<div class="nav-item" onclick="location.href='/pricing'">Pricing</div>
<div class="title">Plans</div>
 
<!-- Native navigation and heading semantics -->
<nav aria-label="Primary">
  <a href="/pricing">Pricing</a>
</nav>
<main>
  <h1>Plans</h1>
</main>

The link works with keyboard activation, link context menus, copying, status display, and assistive technologies. The heading contributes to document navigation. The DOM should still follow a meaningful reading and focus order, and repeated landmarks need distinguishable names.

6. Why use a native button instead of div role="button"?

A native button has button semantics, is focusable in the normal tab sequence, and implements activation for keyboard and pointer input. It also participates in forms and platform states such as disabled.

<button type="button" aria-pressed="false">
  Mute
</button>

Adding role="button" to a div changes what assistive technology perceives; it does not add focusability, Enter/Space behavior, disabled behavior, form behavior, or styling for forced-colors modes. If a native element truly cannot express a custom widget, implementing the role is a promise to implement and test the entire WAI-ARIA Authoring Practices interaction pattern.

7. How do you make images accessible?

Choose the text alternative from the image's purpose in its current context:

<!-- Informative: convey the information, not every visual detail. -->
<img src="trend.svg" alt="Support requests fell from 120 in January to 75 in March">
 
<!-- Decorative: keep it out of the accessibility tree. -->
<img src="divider.svg" alt="">
 
<!-- Functional: name the action or destination. -->
<a href="/reports/quarterly">
  <img src="report.svg" alt="Open the quarterly report">
</a>
 
<!-- Complex: short identification plus an equivalent nearby. -->
<figure>
  <img src="sales-chart.svg" alt="Quarterly sales by region; details follow">
  <figcaption>
    <a href="#sales-data">View the sales data table</a>
  </figcaption>
</figure>

A complex chart needs an equivalent explanation or data table, not an enormous alt string. Adjacent text may already provide the alternative. “Image of” is usually redundant, but can be meaningful when the medium or type of image matters. For an icon-only button, name the button and hide a redundant decorative SVG:

<button type="button" aria-label="Close dialog">
  <svg aria-hidden="true" focusable="false"><!-- icon --></svg>
</button>

ARIA

8. What is ARIA, and when should you use it?

WAI-ARIA defines roles, states, and properties that influence how an element is exposed in the accessibility tree. Examples include aria-expanded, aria-controls, aria-labelledby, aria-live, and widget roles.

Prefer native HTML when it provides the needed semantics and behavior. Use ARIA to fill a semantic gap, distinguish landmarks, expose state or relationships, name a control without visible text, or announce a dynamic update. ARIA can override native semantics, and invalid or stale state can make the non-visual interface misleading.

9. When is ARIA necessary for a custom widget?

Before building a widget, check whether HTML already has an appropriate control, such as <button>, <details>, <select>, or modal <dialog>. If not, use a documented pattern and implement all of it: role, accessible name, state, relationships, keyboard model, focus movement, disabled behavior, visual state, and high-contrast support.

For example, tabs need more than role="tab": selected state, roving tab focus, relationships to panels, arrow-key behavior, and activation policy must agree. The ARIA Authoring Practices Guide is informative guidance, not a drop-in component library. Test its pattern against the actual browser and assistive-technology combinations in scope.

10. How do aria-label, aria-labelledby, and aria-describedby differ?

• aria-label supplies an accessible name string, often for a control with no visible text.
• aria-labelledby builds the accessible name from referenced elements and can combine multiple IDs.
• aria-describedby references supplementary description; it does not replace the name.

<section role="region" aria-labelledby="billing-title">
  <h2 id="billing-title">Billing address</h2>
 
  <label for="postal-code">Postal code</label>
  <input id="postal-code" aria-describedby="postal-hint postal-error">
  <p id="postal-hint">Use the format shown on your address.</p>
  <p id="postal-error" hidden>Enter a valid postal code.</p>
</section>

Prefer a persistent visible label when possible. An aria-label can override visible text in the accessible name and create a mismatch for speech-input users. Do not rely on a simplistic universal precedence mnemonic; use the Accessible Name and Description Computation for the element and inspect the computed accessibility tree.

11. How do you announce dynamic content?

Use a live region for important changes that occur without moving focus. Create the region before the update, then change its content. role="status" is suitable for polite status information; role="alert" is assertive and should be reserved for urgent interruptions.

<div id="save-status" role="status" aria-atomic="true"></div>

const status = document.querySelector("#save-status");
 
async function save() {
  status.textContent = "Saving…";
  await saveChanges();
  status.textContent = "Changes saved";
}

Do not announce every visual update. Avoid combining redundant live-region roles and properties without a reason, and test timing because browser/screen-reader support differs. For form errors, connect the message to its control, set aria-invalid only while invalid, provide a summary for multiple errors, and move focus only when that supports recovery.

Keyboard Navigation

12. How do you ensure keyboard accessibility?

Start with native interactive elements in meaningful DOM order. Every function available by pointer should have a keyboard path unless the task inherently depends on path movement, and no component should trap focus except a correctly implemented modal interaction.

Avoid positive tabindex values and do not “repair” a confusing visual order with manual tab numbers. Align DOM, reading, visual, and focus order. Use tabindex="0" only to add a non-native element to the natural sequence when its full interaction is implemented; use tabindex="-1" for programmatic focus targets.

Test more than Tab: Shift+Tab, activation keys, Escape, arrow keys where the widget pattern calls for them, browser zoom, scrolling, and operation with a visible focus indicator. Pointer, touch, speech, and switch access also matter; keyboard testing is an important proxy, not complete coverage.

13. How do you implement a skip link?

A skip link lets users bypass repeated blocks and should appear at or near the start of the focus order. Its target must exist, and focus plus scroll behavior must be tested in supported browsers.

<a class="skip-link" href="#main">Skip to main content</a>
 
<header><!-- repeated site header and navigation --></header>
 
<main id="main" tabindex="-1">
  <h1>Account settings</h1>
</main>

.skip-link {
  position: fixed;
  inset-block-start: 0.5rem;
  inset-inline-start: 0.5rem;
  transform: translateY(-200%);
}
 
.skip-link:focus {
  transform: translateY(0);
}

Do not use a negative tabindex on the link itself. If a sticky header could cover the target or its focus indicator, account for it with layout or scroll-margin and verify WCAG 2.2 Focus Not Obscured.

14. How should focus indicators be styled?

Keep a visible indicator for keyboard-operable controls. :focus-visible lets the browser apply the indicator when its heuristics say it is needed, while :focus can provide a fallback:

:focus {
  outline: 2px solid CanvasText;
  outline-offset: 3px;
}
 
:focus-visible {
  outline: 3px solid #0b57d0;
  outline-offset: 3px;
}
 
@media (forced-colors: active) {
  :focus-visible {
    outline-color: Highlight;
  }
}

Do not globally remove outlines for pointer aesthetics. Check the indicator against adjacent colors, at zoom, in forced-colors mode, on every component state, and near sticky or overlapping content. WCAG 2.2 AA requires visible focus and that the focused component is not entirely hidden; the more prescriptive Focus Appearance criterion is Level AAA.

15. Which keys should custom widgets support?

Keyboard behavior is pattern-specific. Native buttons activate with Enter and Space. A disclosure button toggles with its button behavior and exposes aria-expanded. Tabs commonly use a single tab stop plus arrow navigation. Menus, listboxes, grids, trees, and comboboxes have different focus, selection, type-ahead, Home/End, and Escape rules.

Do not attach one generic keydown handler to every widget. Follow the relevant APG pattern, distinguish focus from selection, prevent browser defaults only for keys the widget consumes, handle orientation and writing expectations, and test empty/disabled/dynamic items. If that implementation burden is unnecessary, choose a simpler native control.

Accessible Forms

16. How do you label form controls and report errors?

Prefer a persistent visible <label> whose for exactly matches the control's unique id. Placeholder text is an example or hint, not a label.

<label for="email">Email address</label>
<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
  required
  aria-describedby="email-hint email-error"
>
<p id="email-hint">We will send the receipt here.</p>
<p id="email-error" hidden>Enter an email address in the format name@example.com.</p>

On validation failure, show text that identifies the field and explains how to recover, set aria-invalid="true", reveal the associated error, and preserve the user's input. Native required already exposes the required state in supported HTML controls, so aria-required="true" is usually redundant. Never communicate an error through color alone.

17. When should you use fieldset and legend?

Use a fieldset with a legend when controls form a group that needs a shared accessible name, especially radio buttons, related checkboxes, or a set of address fields.

<fieldset>
  <legend>Preferred contact method</legend>
 
  <input id="contact-email" name="contact" type="radio" value="email">
  <label for="contact-email">Email</label>
 
  <input id="contact-phone" name="contact" type="radio" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>

The legend names the group; each control still needs its own label. “Always use a fieldset for every radio button” is too broad: the need is a programmatically conveyed group and prompt, and alternative supported techniques can fit some structures. Avoid deeply nested fieldsets and test how the target browser/screen-reader combinations announce them.

Dialog and Focus Management

18. What makes a modal dialog accessible?

A modal dialog needs all of these behaviors:

• an accessible name, usually from its visible title;
• focus moved to an appropriate element inside when opened;
• content outside the modal made inert for pointer, keyboard, and assistive-technology interaction;
• Tab and Shift+Tab contained within the dialog;
• a visible close action and normally Escape support;
• focus returned to the invoker, or another logical target if the invoker no longer exists;
• scroll, zoom, nested-dialog, and destructive-action behavior designed deliberately.

aria-modal="true" communicates modality but does not make the background inert or trap focus. aria-describedby is optional and can be counterproductive for long, structured dialog content that users should navigate element by element.

19. Should you use the HTML dialog element or a custom ARIA dialog?

Prefer the native <dialog> with showModal() when its behavior and browser support fit. Modal opening places it in the top layer and makes the rest of the document inert, reducing custom focus-trap code.

<button id="open-delete" type="button">Delete project</button>
 
<dialog id="delete-dialog" aria-labelledby="delete-title">
  <h2 id="delete-title" tabindex="-1">Delete project?</h2>
  <p>This cannot be undone.</p>
  <form method="dialog">
    <button value="cancel" autofocus>Cancel</button>
    <button value="confirm">Delete</button>
  </form>
</dialog>

const dialog = document.querySelector("#delete-dialog");
const openButton = document.querySelector("#open-delete");
 
openButton.addEventListener("click", () => {
  dialog.returnValue = "cancel"; // Do not reuse a previous confirmation.
  dialog.showModal();
});
dialog.addEventListener("close", () => {
  if (dialog.returnValue === "confirm") deleteProject();
});

Initial focus depends on content and risk; putting it on the least destructive action can be appropriate. Native behavior still needs testing for the supported platform combinations and application framework. If you implement role="dialog" yourself, use a well-tested component because simplistic focusable-element selectors fail with dynamic content, shadow DOM, removed triggers, nesting, and background interaction.

Testing

20. How do you test accessibility?

Use complementary layers throughout design and development:

1. Static and component checks: lint rules, semantic assertions, accessible-name checks, and automated engines such as axe.
2. Keyboard and interaction review: meaningful focus order, complete operation, no unintended traps, visible/unobscured focus, errors, timeouts, and drag alternatives.
3. Visual adaptation: text spacing, zoom, reflow, contrast, non-color cues, reduced motion, and forced-colors modes.
4. Assistive technology: representative browser/screen-reader and other input combinations chosen from user and support data.
5. Human task evaluation: knowledgeable reviewers and, where possible, people with disabilities exercising critical journeys.
6. Regression coverage: automated assertions plus repeatable manual checks for components and full processes.

Automated tools find only issues they have rules and evidence for; no percentage applies universally, and a zero-issue report does not establish WCAG conformance. Record scope, versions, pages, states, test environment, methods, failures, exceptions, and remediation evidence.

21. How do you create visually hidden content?

Use visually hidden text only when it supplies necessary information to non-visual presentation without withholding useful instructions from sighted users. Visible labels are usually more robust. display: none, the hidden attribute, and visibility: hidden normally remove content from both visual rendering and the accessibility tree.

.visually-hidden:not(:focus):not(:active) {
  position: absolute;
  inline-size: 1px;
  block-size: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}

The focus exceptions make a focusable skip link visible when used. Test in high zoom, RTL and vertical writing modes, forced colors, and supported assistive technologies. Do not put focusable controls inside a permanently clipped container.

Quick Reference

Frequently Asked Questions

What is web accessibility and why does it matter?

Web accessibility means designing and building content and interactions so people with disabilities can perceive, understand, navigate, and operate them. It requires more than screen-reader support: keyboard and switch access, zoom and reflow, captions, clear language, robust semantics, and compatible input methods all matter.

Which WCAG version should teams use?

W3C encourages teams to use WCAG 2.2, its latest published Recommendation, because WCAG 2.2 includes the requirements from 2.1 and 2.0 with one obsolete criterion removed. A contract or law may still name WCAG 2.0 or 2.1, so verify the applicable version, scope, level, exceptions, and jurisdiction.

What is semantic HTML and why is it important?

Semantic HTML uses the native element whose meaning and behavior match the content, such as a heading, link, button, navigation region, table, or form control. This gives browsers and assistive technologies a stronger baseline, but correct elements alone do not guarantee accessible names, keyboard flows, focus, contrast, or understandable content.

When should you use ARIA?

Use native HTML semantics and behavior when they fit. Add ARIA when the accessibility tree needs a name, relationship, state, live update, landmark distinction, or widget role that HTML does not provide. ARIA does not add keyboard behavior or focus management, so custom widgets must implement and test the complete interaction pattern.

How do you make images accessible?

Choose text alternatives from the image's purpose and context. Informative images need concise equivalent information, functional images describe the action or destination, decorative images use alt='', and complex charts need a nearby detailed equivalent such as a data table or explanation. Avoid duplicating information already conveyed in adjacent text.

How do you test accessibility?

Combine automated checks with human evaluation: inspect semantics and accessible names, use keyboard and relevant input methods, test zoom and reflow, review contrast and non-color cues, and exercise representative browser and assistive-technology combinations. Include people with disabilities where possible; no automated tool alone can determine conformance.

Official Sources

• W3C WAI: WCAG 2 overview
• Web Content Accessibility Guidelines 2.2
• What's New in WCAG 2.2
• WAI-ARIA Authoring Practices Guide
• WAI-ARIA APG: Modal Dialog Pattern
• W3C WAI Images Tutorial
• W3C WAI Forms Tutorial
• W3C WAI: Evaluating Web Accessibility
• WHATWG HTML Living Standard
• ADA.gov: Title II web and mobile accessibility rule

Related Articles

• Complete Frontend Developer Interview Guide
• CSS Flexbox vs Grid Interview Guide
• React 19 Interview Guide