Accessibility Testing Interview Questions and Answers (2026)

TL;DR

Prepare WCAG 2.2, HTML, ARIA, keyboard, screen-reader, visual, mobile, and axe topics. Define the issue, connect user impact, show verification, and state limitations.

Key Takeaways

• Explain barriers through user tasks.
• Combine automation with manual testing.
• Prefer native HTML before ARIA.
• Separate conformance level from severity.
• Document assistive-technology environments.
• Prevent regressions in shared components.

Accessibility testing interview questions assess whether you can turn WCAG and assistive-technology knowledge into reliable product decisions. Strong candidates explain the user barrier, test a complete task, collect reproducible evidence, distinguish automation from manual judgment, and prevent recurrence. This guide provides 60 model answers covering WCAG 2.2, ARIA, screen readers, keyboard access, low vision, mobile testing, axe automation, and strategy.

Review accessibility testing basics and the accessibility testing checklist while rehearsing. Replace each model with a real example from your work.

TL;DR

Use a six-part answer: definition, affected user and task, example, verification, limitation, and prevention. A passing scanner result never proves that a journey is accessible.

1. Foundations

Q: What does accessibility testing evaluate?

Accessibility testing checks whether disabled people can perceive, understand, navigate, and operate a product, not merely whether markup passes a scanner. I select representative journeys such as sign-in, search, checkout, and error recovery, then combine semantic inspection, keyboard use, zoom, contrast checks, and assistive technology. A useful defect states the blocked task and affected interaction, includes exact reproduction steps, and names the relevant WCAG success criterion without pretending that conformance alone describes usability.

Q: How do the four POUR principles guide test coverage?

POUR organizes WCAG under perceivable, operable, understandable, and robust principles. I apply it as a coverage prompt: text alternatives and captions for perception, keyboard and timing for operation, predictable labels and errors for understanding, and valid name-role-state exposure for robustness. I would trace one journey through all four because a control can be announced correctly yet remain unreachable by keyboard, or be operable while its error message is never communicated.

Q: What is the difference between accessibility and usability?

Accessibility asks whether people with disabilities can complete the task; usability asks how effectively and comfortably people complete it. The sets overlap, but a formally labeled date picker can still be exhausting with a screen reader, while a generally confusing instruction may not map cleanly to one WCAG failure. I report standards violations separately from broader experience findings, provide evidence for each, and use disabled-user research to resolve questions that conformance testing cannot answer.

Q: How do you build coverage across different disabilities?

Disability coverage must include visual, auditory, motor, speech, cognitive, language, learning, and neurological needs, including temporary and situational limitations. I map product risks to interaction modes rather than claiming one screen reader represents every user: keyboard-only, switch-like navigation, magnification, reduced motion, captions, voice input, and plain-language review expose different barriers. The matrix is risk based, so a video editor receives deeper media coverage while a banking flow receives stronger authentication and error-recovery coverage.

Q: What is the accessibility tree, and how do you inspect it?

The accessibility tree is the browser or platform representation consumed by assistive technologies; it contains exposed roles, names, states, values, and relationships rather than every DOM node. I inspect it in browser developer tools, then verify behavior with the target assistive technology because correct-looking tree data can still be announced differently across combinations. A div with a click handler is usually absent as an actionable control, while a native button supplies semantics, focusability, keyboard activation, and disabled behavior together.

2. WCAG 2.2 Accessibility Testing Interview Questions

Q: How do WCAG A, AA, and AAA conformance levels affect testing?

WCAG success criteria are grouped into A, AA, and AAA, but severity is not the same as conformance level. A product claiming AA must satisfy all applicable A and AA criteria for the complete pages and processes in scope, with no inaccessible alternate step hidden inside a journey. I test at the organization target, usually AA, then prioritize by user impact: an A-level missing page language may be less urgent than an AA focus issue that blocks payment.

Q: What changed in WCAG 2.2?

WCAG 2.2 adds nine success criteria and removes 4.1.1 Parsing; important additions include Focus Not Obscured, Focus Appearance at AAA, Dragging Movements, Target Size Minimum, Consistent Help, Redundant Entry, and Accessible Authentication. I add scenarios for sticky overlays, small controls, drag-only actions, repeated data, and cognitive-function tests in login. Existing WCAG 2.1 coverage remains relevant, so migration is an extension of the suite rather than a reset.

Q: How do you test WCAG 2.2 Focus Not Obscured?

WCAG 2.2 requires a keyboard-focused component not to be entirely hidden at AA, and AAA requires it not to be even partially obscured. I tab through the page at common responsive widths while sticky headers, cookie banners, chat widgets, and open drawers are present. For each focus stop I inspect the visible focus indicator and bounding rectangle; if an author-created overlay covers it, I capture the focused element and overlay in one screenshot and test the fix with scroll padding or layout changes.

Q: How do you verify Target Size Minimum?

WCAG 2.2 AA sets a 24 by 24 CSS pixel minimum target size, with exceptions for sufficient spacing, inline text, user-agent controls, essential presentation, and equivalent controls. I measure the clickable region, not the icon artwork, and check adjacent-target spacing when the box is smaller. Tests cover touch emulation and a real device because CSS dimensions alone do not reveal overlapping hit areas or controls that move during activation.

Q: How would you test Accessible Authentication?

Accessible Authentication at AA prohibits forcing a cognitive function test such as memorizing or transcribing a password unless an exception applies, including an alternative method or mechanism assistance. I verify paste, password managers, passkeys, and copy-friendly one-time codes, and I ensure CAPTCHA has an accessible alternative. At AAA, object recognition and personal-content recognition face tighter restrictions, so I document the claimed level and test every recovery path, not only the happy login.

3. Semantic HTML

Q: Why should native HTML be preferred over custom controls?

Native HTML is the first choice because elements carry interoperable behavior: button activates with Enter and Space, label focuses its input, and details exposes disclosure state. I compare a custom component against the native contract across keyboard, focus, disabled state, high contrast, and name-role-state output. ARIA can repair semantics but does not add event handling, so role="button" on a div still requires focusability and both keyboard activation paths.

Q: How do you verify a control's accessible name?

An accessible name identifies a control in the accessibility tree and may come from visible text, a label, aria-labelledby, aria-label, or element-specific sources according to the naming computation. I inspect the computed name and assert it through a role query, then confirm that visible wording is included so speech-input users can say what they see. Duplicate names are acceptable only when context distinguishes purpose; a page full of unqualified "Edit" buttons usually needs row or item context.

Q: How do you decide whether an image needs alternative text?

Alternative text communicates the image purpose in context, not a mechanical inventory of pixels. I expect alt="" for decorative images, concise purpose for informative images, and an equivalent nearby explanation for complex charts; linked images need the destination or action as their name. I test with images disabled and a screen reader, then ask whether the same decision can be made without sight. Filename text, redundant "image of" wording, and hidden critical data are clear defects.

Q: How do you test form labels?

Every form control needs a persistent programmatic label, preferably a visible label associated by for/id or nesting. Placeholder text is not a substitute because it disappears, often has weak contrast, and is inconsistently announced. I click the label, inspect the computed name, navigate with a screen reader form list, and test errors after submission. For grouped choices I use fieldset and legend so each radio label is heard with the question context.

Q: How do headings and landmarks support navigation?

Headings describe document hierarchy while landmarks provide broad navigation regions such as main, nav, header, and footer. I inspect the heading outline for meaningful nesting and use the screen reader heading and landmark lists to detect missing labels or duplicate unlabeled navigation regions. Heading ranks should represent structure rather than visual size; CSS can style an h2, but replacing it with bold text removes a navigation destination.

4. Keyboard and Focus

Q: How do you perform a keyboard-only accessibility test?

Keyboard access means every interactive task works without a pointer using expected keys, with visible focus and no surprise context changes. I start at the browser chrome, use Tab and Shift+Tab, activate controls with Enter or Space as appropriate, use arrow keys inside composite widgets, and finish the entire journey. I record unreachable controls, incorrect key behavior, focus loss, and pointer-only instructions separately because each suggests a different fix.

Q: What is a keyboard trap, and how do you detect one?

A keyboard trap occurs when focus enters a region but the user cannot leave using standard or documented keys. I test forward and reverse tabbing around editors, embedded frames, menus, modals, and media players, including Escape where the pattern defines dismissal. A modal intentionally containing focus is not a failure if it can be closed and focus returns logically; an undocumented plugin shortcut that is the only exit is risky and must be clearly conveyed.

Q: How do you determine whether focus order is logical?

Focus order should preserve meaning and operability, usually following DOM order rather than visual CSS placement. I number focus stops while tabbing and compare them with reading order at desktop, mobile, zoom, and right-to-left layouts. Positive tabindex values are a warning because they create a second ordering system; I prefer source-order fixes and tabindex="0" only when a custom interactive element genuinely belongs in sequential navigation.

Q: What focus behavior should an accessible modal provide?

An accessible modal moves focus inside when opened, keeps keyboard focus within while active, exposes a dialog name, makes background content unavailable, supports Escape when dismissal is allowed, and restores focus to a logical control. I test open, initial focus, forward and reverse wrapping, validation inside the dialog, close, and opener removal. Native dialog with showModal can supply modality, but the team still owns naming, initial-focus judgment, and return-focus behavior.

Q: How do you test alternatives to dragging movements?

WCAG 2.2 requires functionality using dragging to have a single-pointer alternative unless dragging is essential or controlled by the user agent. For a sortable list, I look for Move up, Move down, or position controls that work by click, touch, keyboard, and assistive technology. I verify the new order is announced, focus stays on the moved item, and the saved data matches the visual order; merely adding keyboard drag keys does not satisfy a user who cannot perform a path gesture.

5. Screen Readers

Q: Which browser and screen-reader combinations belong in a test matrix?

A screen reader matrix pairs supported operating systems, browsers, and assistive technologies rather than testing random combinations. Common high-value pairs include NVDA with Firefox or Chrome on Windows, JAWS with Chrome on Windows, and VoiceOver with Safari on Apple platforms; product analytics and support commitments determine the final set. I keep smoke coverage broad, run deep task testing on primary pairs, and document versions and settings so announcement differences are reproducible.

Q: What are browse mode and focus mode in a desktop screen reader?

Desktop screen readers use browse or virtual-cursor mode to read document content and focus or forms mode to send keys to interactive controls. I test headings and text in browse mode, then enter forms and composite widgets to confirm mode changes do not swallow expected keys. A custom widget that relies on printable-letter shortcuts may conflict with screen reader navigation, so native patterns and documented ARIA keyboard behavior reduce ambiguity.

Q: When should a live region be used, and how do you test it?

Live regions announce asynchronous changes without moving focus; aria-live="polite" queues ordinary status while assertive content interrupts and should be rare. I place the live container in the DOM before updating its text, trigger one change at a time, and listen for duplicate, missing, or overly verbose announcements. A loading spinner also needs a meaningful state, and a completed action should say what changed rather than repeatedly announcing generic words such as "updated."

Q: How do you verify that dynamic updates are announced correctly?

For dynamic updates I decide whether the user needs focus movement, a status announcement, or no interruption. Adding search results usually calls for a concise polite count while focus stays in the query field; opening a dialog requires focus transfer; background refresh often needs silence. I test slow responses, repeated requests, empty results, errors, and rapid typing because stale live messages and unexpected focus jumps frequently appear only under timing pressure.

Q: What are the limitations of screen-reader testing?

Screen reader testing validates the delivered experience but cannot prove coverage for low vision, motor access, cognition, captions, contrast, or keyboard-only use. Results also depend on browser, operating system, verbosity, user settings, and tester skill, so one clean VoiceOver run is not universal evidence. I combine standards-based inspection with representative combinations and disabled-user feedback, and I report exact environments instead of saying that the page "works with screen readers."

6. ARIA Accessibility Testing Interview Questions

Q: How do you validate ARIA roles, states, and properties?

ARIA roles define what an object is, while states and properties communicate conditions and relationships such as expanded, selected, checked, pressed, controls, and describedby. I verify the allowed role, update state at the same moment as the UI, and test the computed accessibility tree plus real interaction. An accordion button must expose aria-expanded and identify its panel, but it still needs native button keyboard behavior and sensible focus order.

Q: When would you use aria-label instead of aria-labelledby?

aria-label provides a string, while aria-labelledby references visible or hidden text and normally wins in the accessible-name computation. I prefer labelledby when existing visible wording should remain synchronized and use aria-label for genuinely icon-only controls. I inspect the computed name after localization and responsive changes; referencing a missing ID, overriding useful button text, or naming a control differently from its visible label creates avoidable failures.

Q: What can go wrong when aria-hidden is used?

aria-hidden="true" removes an element and its descendants from the accessibility tree without visually hiding them. I use it for duplicated decorative content, never on a focusable element or an ancestor containing focusable controls. I inspect descendants, tab through the region, and toggle the state while a screen reader runs; hiding the currently focused subtree creates a severe mismatch, while the HTML hidden attribute or inert is often more appropriate for inactive UI.

Q: What semantics and keyboard behavior should an ARIA tabs widget expose?

An ARIA tabs widget exposes tablist, tab, and tabpanel roles, one selected tab, relationships through aria-controls and aria-labelledby, and roving tabindex. Tab enters the active tab, arrow keys move among tabs according to orientation, and activation may be automatic only when panels appear without noticeable latency. I test wrap behavior, Home and End when supported, focus visibility, dynamic tab removal, and whether only the selected panel is presented.

Q: How would you test an editable combobox?

A combobox requires a clearly named input or button, expanded state, popup relationship, and correct active-option communication. I test typing, filtering, arrow navigation, selection, Escape, blur, empty results, and editing an existing value with both keyboard and screen reader. Implementations using aria-activedescendant must keep DOM focus on the input while updating the referenced option; virtualization must not remove the active option before assistive technology can perceive it.

7. Visual and Low Vision

Q: What contrast ratios does WCAG AA require for text?

WCAG AA requires normal text contrast of at least 4.5:1 and large text of at least 3:1, with specific definitions and exceptions. I sample rendered foreground and background colors in each state, including text over images, gradients, disabled styling, and forced themes, then calculate the ratio rather than judging by eye. Large-text thresholds do not apply merely because CSS says bold; rendered size and weight determine the category.

Q: How do you evaluate non-text contrast?

Non-text contrast requires at least 3:1 for visual information needed to identify UI components and meaningful graphical objects against adjacent colors. I inspect input boundaries, unchecked controls, icons, focus indicators, chart segments, and error states, while distinguishing essential information from decoration. A pale border may pass if another clear cue defines the field, but a low-contrast focus ring with no alternative visible indicator blocks keyboard orientation.

Q: How do you test zoom and responsive reflow?

I test text resize to 200 percent and content reflow at a 320 CSS pixel viewport equivalent, checking that information and functionality remain available without two-dimensional scrolling except for legitimate content such as data tables. I complete tasks rather than taking a single screenshot because menus, dialogs, validation, and sticky bars often fail after zoom. Clipped labels, overlapping controls, lost content, and horizontal scrolling caused by fixed widths are actionable findings.

Q: How do you run the WCAG text-spacing test?

WCAG text-spacing tests override line height to 1.5 times font size, paragraph spacing to 2 times, letter spacing to 0.12 times, and word spacing to 0.16 times. I inject those values and inspect all content and controls for clipping, overlap, or loss of function. The requirement does not demand that the design always use those values; it demands resilience when users apply them, so fixed-height buttons and cards are common failure sources.

Q: What requirements apply to content shown on hover or focus?

Content appearing on hover or focus must be dismissible, hoverable, and persistent unless an exception applies. I open tooltips with both pointer and keyboard, move the pointer onto the popup, press Escape without moving focus, and wait to ensure it remains until the trigger is removed or the information is no longer valid. Tooltips that vanish when crossing a small gap are especially harmful at magnification, where pointer travel is less precise.

8. Forms and Errors

Q: What makes a form error accessible?

A useful form error identifies the field, explains the problem in text, and suggests a correction when known. I submit empty and malformed values, verify focus strategy, inspect aria-invalid and the programmatic error association, and confirm the message survives zoom and screen-reader navigation. Color and an icon can reinforce status but cannot be the only cue; successful correction must also clear stale error semantics.

Q: When should a form provide an error summary?

An error summary at the top of a long form gives a count and linked list of problems, while inline messages provide local correction detail. After failed submission I expect focus on a suitably labeled summary or heading, then each link should move to the exact control without hiding it under a sticky header. I test repeated submissions and dynamic removal so the count, links, and inline associations never point to resolved or nonexistent errors.

Q: How should required fields be communicated?

Required status must be communicated before submission in text and programmatically, using the native required attribute where possible. I verify that a symbol such as an asterisk has an explained meaning, inspect the control state, submit it blank, and listen to the resulting error. aria-required can expose state for custom widgets but does not trigger native validation; teams must not assume it supplies behavior.

Q: How do you test time limits and session expiration?

For time limits I identify the source, warning, extension mechanism, and any essential or real-time exception. Users generally need a way to turn off, adjust, or extend the limit, and a session warning must be perceivable, keyboard operable, and announced early enough to act. I test idle expiry with assistive technology, extend and decline paths, preserved form data, multiple tabs, and server-side expiry because a perfect client dialog cannot recover an already invalid session.

Q: How do you test an accessible data table?

Data tables need genuine table structure, header cells, and associations that let users understand each value in context. I navigate by rows and columns with a screen reader, verify caption or nearby purpose, inspect scope for simple tables, and use explicit headers relationships only when complexity requires them. Responsive card transformations must retain associations, and sortable headers must remain buttons with announced sort direction rather than clickable th elements alone.

9. axe Automation and CI

Q: What can axe-core detect, and what must still be tested manually?

axe-core detects many deterministic markup and contrast problems, but it cannot decide whether alt text is meaningful, focus order is logical, a screen-reader journey is usable, or instructions are cognitively clear. I scan stable states after opening menus, dialogs, errors, and authenticated content, then triage each node in context. Incomplete results need human review, and passes describe only the rules and DOM state tested, not total accessibility.

Q: How do you integrate axe-core with Playwright?

I integrate axe through @axe-core/playwright, navigate to a deterministic state, instantiate AxeBuilder with the Playwright page, analyze, and assert on violations. Scans belong after meaningful interactions because a home-page scan misses modal, validation, and expanded-menu defects. I keep the rule configuration visible in code, attach reports on failure, and pair the scan with role-based assertions and keyboard tests so semantic regressions are caught closer to their cause.

Q: What accessibility checks should block a CI build?

A sustainable CI policy blocks newly introduced serious or critical violations in owned code, reports the full result, and tracks an explicit baseline with owners and expiry dates. I avoid silently disabling rules or excluding broad containers; exceptions require a documented reason and compensating manual test. Fast component scans run on pull requests, representative journeys run later, and scheduled audits detect template or dependency changes across a wider page inventory.

Q: Why can a clean automated scan create false confidence?

Automation creates false confidence when teams equate zero detected violations with an accessible product. A button can have a perfect role and name yet open a dialog that loses focus, a chart can meet markup rules yet convey no equivalent insight, and the checkout order can remain illogical. I present scanner coverage as one evidence layer, publish the manual matrix beside it, and track task completion findings separately from machine-detectable rule counts.

Q: How would you test accessibility in a shared component library?

A component library concentrates accessibility risk and leverage, so I test contracts at the primitive level and realistic composition in consuming products. For each interactive component I document semantics, keyboard model, focus behavior, states, high-contrast behavior, zoom resilience, and allowed labels. Automated stories catch structural regressions, while manual screen-reader and keyboard checks cover behavior; fixes at the shared component prevent dozens of repeated product defects.

Hands-on Playwright and axe tutorial

Use this compact exercise when an interviewer asks you to demonstrate automation rather than describe it. It adds a scanner to a real browser test, verifies semantics separately, exercises the keyboard, and shows what CI should report.

Step 1: Install the runner

Create a clean Node project and install current packages.

npm init playwright@latest
npm install --save-dev @axe-core/playwright

Verify the setup with npx playwright test --list. The command should list the generated example test without a module-resolution error.

Step 2: Scan the rendered state

Replace the example with a complete TypeScript test.

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('home page has no automatically detectable WCAG A or AA violations', async ({ page }, testInfo) => {
  await page.goto('http://127.0.0.1:4173/');
  await expect(page.getByRole('main')).toBeVisible();

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();

  await testInfo.attach('axe-results', {
    body: JSON.stringify(results, null, 2),
    contentType: 'application/json',
  });
  expect(results.violations).toEqual([]);
});

Start the application, run npx playwright test, and open the HTML report. Verification succeeds only when the test passes and the attachment contains an empty violations array. Do not exclude failing selectors merely to make the build green.

Step 3: Assert the accessible contract

Add role and name assertions because a broad scan is not a component specification.

test('menu button exposes its state', async ({ page }) => {
  await page.goto('http://127.0.0.1:4173/');
  const menu = page.getByRole('button', { name: 'Menu' });
  await expect(menu).toHaveAttribute('aria-expanded', 'false');
  await menu.click();
  await expect(menu).toHaveAttribute('aria-expanded', 'true');
  await expect(page.getByRole('navigation', { name: 'Primary' })).toBeVisible();
});

Run this test against a known-good fixture. Verify that changing the button name or leaving aria-expanded stale produces a focused assertion failure that tells the developer which contract broke.

Step 4: Exercise keyboard behavior

Test the interaction rather than calling click() for every path.

test('dialog contains and restores keyboard focus', async ({ page }) => {
  await page.goto('http://127.0.0.1:4173/');
  const opener = page.getByRole('button', { name: 'Delete account' });
  await opener.focus();
  await page.keyboard.press('Enter');

  const dialog = page.getByRole('dialog', { name: 'Delete account' });
  await expect(dialog).toBeVisible();
  await expect(page.getByRole('button', { name: 'Cancel' })).toBeFocused();
  await page.keyboard.press('Escape');
  await expect(dialog).toBeHidden();
  await expect(opener).toBeFocused();
});

Verify the negative case by temporarily removing the return-focus logic. The final assertion must fail; if it still passes, the test is not observing the behavior it claims to protect.

Step 5: Gate new violations in CI

Run the same tests in a clean environment and retain the report.

name: accessibility
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npm run build
      - run: npm run preview -- --host 127.0.0.1 &
      - run: npx wait-on http://127.0.0.1:4173
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

Verify the workflow by introducing a button with no accessible name in the test fixture. The pull request must fail, and the uploaded report must identify the axe rule and affected node. Restore the fixture, rerun, and record the manual keyboard and screen-reader checks that automation still cannot perform. For broader implementation detail, use the complete Playwright accessibility automation guide.

10. Mobile Accessibility

Q: How does mobile accessibility testing differ from desktop web testing?

Mobile accessibility adds touch exploration, swipe navigation, rotor or local-context menus, orientation, dynamic type, platform semantics, and small-screen reflow to web concerns. I test a real iOS and Android device for primary paths because emulators do not fully represent gestures, speech timing, keyboards, or vendor behavior. Coverage includes external keyboard use, screen rotation, large text, reduced motion, target spacing, and interruption recovery such as calls or app backgrounding.

Q: How do you test an iOS app with VoiceOver?

On iOS I enable VoiceOver, explore by touch, swipe left and right through elements, activate with a double tap, and use the rotor for headings, links, form controls, and adjustable values. I check label, trait, value, hint only when useful, focus order, custom actions, and announcements after state changes. A visual overlay inspection is insufficient because swipe order, grouped elements, and modal containment appear only during actual assistive-technology navigation.

Q: How do you test an Android app with TalkBack?

On Android I use TalkBack touch exploration, linear swipes, double-tap activation, reading controls, and local or global menus supported by the device version. I verify content descriptions, roles, states, traversal order, headings, editable fields, and announcements after navigation. Differences from VoiceOver are expected, so I report Android version, device, app build, and TalkBack settings rather than treating one platform result as proof for the other.

Q: What evidence belongs in a mobile accessibility defect?

A mobile accessibility defect should describe the gesture or navigation mode, focused element, spoken output, expected platform behavior, and user impact. I attach a short screen recording with speech when policy permits, plus device, OS, assistive-technology version, orientation, text scale, and reproduction path. Coordinates alone are poor evidence because layouts shift; stable element names and the preceding focus stop make the issue easier for developers to reproduce.

Q: What are the limits of Appium-based accessibility checks?

Appium can automate selected accessibility properties and flows through platform drivers, but it does not reproduce how a person interprets VoiceOver or TalkBack speech and gestures. I use it for stable identifiers, enabled state, element reachability, and regression paths, then reserve real-device manual sessions for reading order, announcements, rotor behavior, and gesture quality. Driver-exposed attributes can differ from the final spoken experience, so an Appium pass is supporting evidence rather than an assistive-technology certification.

11. Media and Dynamic Content

Q: How do you evaluate the accessibility of video content and its player?

Accessible prerecorded video needs synchronized captions for dialogue and meaningful sounds, audio description when visual information is not otherwise conveyed, and an operable player. I verify caption accuracy, timing, speaker identification, sound cues, keyboard controls, focus visibility, control names, full-screen escape, and behavior at zoom. Auto-generated captions are a draft, not evidence, and transcripts complement but do not replace synchronized captions when timing matters.

Q: What should an accessible PDF test cover?

PDF accessibility testing covers tags, logical reading order, headings, lists, table headers, form fields, link purpose, document language, title, bookmarks where useful, and text alternatives. I use a PDF checker as a starting point, inspect the tag tree, then complete reading and form tasks with a screen reader. A source document should be remediated when possible, and an accessible HTML alternative is often easier to maintain, but merely posting both formats does not excuse an inaccessible required PDF.

Q: How should a single-page application handle route changes?

A single-page application must communicate route changes and place focus predictably because the browser may not perform a full navigation. I update the document title, move focus to the main heading or a deliberate destination after navigation, and avoid announcing intermediate loading noise. Tests cover browser Back and Forward, deep links, validation preservation, slow routes, and screen-reader history so focus does not remain on a removed navigation link.

Q: How do you make infinite scroll accessible?

Infinite scroll needs a discoverable loading state, stable focus, understandable result counts, and a way to reach content that would otherwise remain beyond an endless feed, such as pagination or Load more. I trigger loading by keyboard and screen reader, ensure new items appear after the control without resetting position, and verify live announcements are concise. Virtualization must retain the active accessibility node and not make previously read content impossible to revisit.

Q: What accessibility risks appear during localization?

Localization testing covers language metadata, translated accessible names, reading direction, text expansion, pronunciation changes, and error messages, not only visible strings. I switch locale and direction, inspect computed names for untranslated aria-label values, verify document and passage language, and complete keyboard flows in right-to-left layouts. Concatenated announcements and hard-coded English labels frequently escape visual review because they live only in accessibility attributes.

12. Strategy and Leadership

Q: When should an accessibility defect block a release?

I prioritize releases by blocked critical tasks, number and vulnerability of affected users, frequency, workaround quality, legal or contractual exposure, and whether the defect sits in a shared component. A keyboard trap in payment can stop release even if only one page is affected, while low-impact duplicate landmarks may enter a scheduled backlog. The decision includes an owner, mitigation, retest date, and explicit acceptance authority rather than a vague promise to fix accessibility later.

Q: How do you manage accessibility risk in a third-party widget?

Third-party code remains part of the user journey even when the team cannot edit its source. I evaluate vendors against task-specific criteria, include accessibility obligations and remediation timelines in procurement, test the integrated state, and maintain a replacement or fallback plan. If a payment widget traps keyboard focus, I escalate with reproducible evidence and offer an accessible channel; an accessibility statement alone is not a technical workaround.

Q: How do you set priority for an accessibility defect?

Accessibility defect priority begins with user impact: blocked, severely hindered, confusing, or cosmetic, then adds reach, frequency, workflow criticality, workaround, and component reuse. WCAG level and automated impact labels inform the decision but do not dictate it. I include the affected population and task in the ticket, separate severity from scheduling priority, and retest with the original interaction mode before closure.

Q: What belongs in an organization-wide accessibility test strategy?

An accessibility test strategy defines scope, conformance target, supported environments, journey inventory, component risks, automation layers, manual methods, disabled-user involvement, release gates, ownership, and evidence. I shift checks into design and component development, then validate integrated tasks before release and audit production periodically. Risk-based sampling changes with new templates, frameworks, acquisitions, and user feedback, so the strategy is maintained as a product control rather than a one-time certification project.

Q: Which accessibility metrics are useful to engineering leaders?

Useful metrics show risk reduction and capability: critical-task coverage, open blocked-task defects, age by severity, regression rate, component conformance, remediation time, exception expiry, and disabled-user findings resolved. Raw violation counts are unstable because one template defect may create thousands of nodes and scanning more pages can look like deterioration. I pair trend data with scope and qualitative outcomes, then use it to fund systemic fixes instead of rewarding teams for suppressing findings.

Manual accessibility test exercise

Interviewers often ask for a live test plan because tool knowledge is easier to memorize than investigative judgment. Use the following exercise on a sign-up flow. It demonstrates how to choose coverage, run checks in a stable sequence, capture evidence, and distinguish an observation from a standards failure.

Step 1: Define the task and test oracle

Write the user goal before opening a scanner: create an account, recover from invalid input, accept the terms, and reach the confirmation screen without sight or a pointer. List all states that can change the result, including an unavailable username, password guidance, a disabled submit button, a network error, and an expired verification code. State the oracle in user language: every instruction is perceivable, every control is operable, errors identify a correction, and status changes are communicated without losing work.

Verify this step by asking another tester to name the start condition, successful end condition, and recovery route from your notes. If the plan only says "check WCAG" or "run axe," it is not yet reproducible. Add the supported browsers, viewport, build, account data, and assistive-technology combinations so later differences have context.

Step 2: Inspect structure before interaction

Turn off CSS temporarily and read the DOM order. Confirm that the page title identifies sign-up, one main heading introduces the form, landmarks are sensible, instructions precede the controls they explain, and visual rearrangement has not changed the logical sequence. Inspect each control in the accessibility tree for its computed role, name, state, value, and description. Check that the terms link is a link, the password reveal control is a button, and required state is not conveyed solely by color.

Verify with the browser accessibility panel and role-based queries. Record the computed output rather than copying the source attribute because accessible-name precedence can override what a developer intended. A useful result reads "button, Show password, not pressed" and changes consistently after activation. If the visible label says "Create account" while the computed name says "Submit," report the speech-input and screen-reader mismatch even though both strings sound reasonable alone.

Step 3: Complete the flow with only a keyboard

Put the pointer aside. Start before the page content and use Tab, Shift+Tab, Enter, Space, arrow keys, and Escape according to each control pattern. Follow focus visually, open password help, traverse the terms content, submit blank values, repair each error, and complete verification. Test forward and reverse navigation because a focus trap may appear in only one direction. Repeat at a narrow viewport where sticky banners and responsive menus alter the layout.

Verify that every actionable item is reachable once in a logical order, focus is always visible, no control requires mouse hover, and activation uses the expected key. When an error appears, determine exactly where focus stays or moves and whether that choice helps correction. After closing any dialog, confirm focus returns to the opener or another logical location. Capture a short focus-order list; a screenshot alone cannot prove the sequence.

Step 4: Test zoom, spacing, contrast, and motion

Zoom text and the page according to the applicable WCAG tests, then apply the text-spacing overrides. Complete sign-up again rather than inspecting the initial screen. Look for clipped password rules, horizontal scrolling, inaccessible off-screen errors, overlapping consent controls, and fixed footers that cover keyboard focus. Measure text and non-text contrast in default, hover, focus, error, disabled, and selected states. Enable forced colors and reduced motion to find cues that disappear when author colors or animation change.

Verify each visual finding with measurable evidence. Include foreground and background values for a contrast result, viewport and zoom for reflow, and the exact spacing override for a clipping problem. For motion, identify the triggering interaction and whether the operating-system preference is respected. Do not fail a design merely because it looks different after adaptation; fail it when information, operation, or a necessary visual indicator is lost.

Step 5: Run a screen reader task, not an announcement tour

Choose a supported combination and record its versions. Navigate first by headings, landmarks, links, and form controls to learn whether shortcuts reveal a coherent structure. Then create the account from beginning to end. Listen for labels, required state, password constraints, reveal-button state, error associations, loading feedback, and final confirmation. Try invalid data twice because repeated live-region updates can be suppressed or duplicated even when the first announcement works.

Verify outcomes by writing the speech that changes the decision, not every word spoken. For example, note that the email field announces "invalid entry" and its correction message when focused after submission. Compare the speech with visual text and the accessibility tree, then isolate whether the fault lies in markup, focus management, timing, or an assistive-technology difference. Repeat a suspected interoperability defect in a second supported pairing before generalizing it.

Step 6: Probe cognitive and recovery risks

Read instructions as a first-time user. Check whether password rules are available before entry, examples are concrete, controls use consistent names, help remains in the same relative location, and previously supplied information is not requested again without a valid reason. Paste a generated password, use a password manager, request a one-time code, let it expire, and recover from an interrupted network response. Confirm that users are not forced to memorize or transcribe information when platform assistance can perform the task.

Verify that data survives recoverable errors and that the next action is explicit. A message such as "Something went wrong" is observable but not actionable; the user needs to know whether to retry, correct a field, request another code, or contact support. Treat plain language and predictability as testable properties, while acknowledging that expert review cannot replace research with people who have relevant cognitive and learning disabilities.

Step 7: Scan every meaningful state

Run axe after the blank form loads, after validation errors appear, with password help expanded, inside any terms dialog, and on confirmation. Scope intentionally if the product embeds third-party content, but document exclusions and test those regions through another method. Review incomplete findings instead of discarding them. Map duplicate violations back to shared components so the remediation owner fixes the source rather than closing many identical tickets.

Verify that the report identifies the URL, state setup, rule, impact, affected nodes, and help reference. Reproduce at least one violation manually and explain its user consequence. Also list what the scan did not evaluate: logical focus order, useful alternative text, understandable errors, screen-reader timing, accessible authentication, and task completion. This limitation statement is part of the evidence, not a disclaimer added after release.

Step 8: Write a defect a developer can close correctly

Use a title that names the barrier and task, such as "Keyboard focus moves behind the verification dialog." Include environment, prerequisites, minimal steps, expected behavior, actual behavior, affected users, task impact, relevant success criterion, and attachments. Show the focused element and accessibility-tree output when they matter. Suggest the behavioral contract for a fix, but avoid prescribing fragile markup unless you own the component design.

Verify the ticket by handing it to someone unfamiliar with the feature. They should reproduce the issue without asking where to click or which setting was enabled. During retest, use the original interaction mode, cover the failure state and neighboring regressions, and confirm the accessible output rather than merely observing that code changed. Close the issue only when the user can complete the blocked task and the reusable regression check passes.

Evidence matrix for an interview answer

Use this matrix to keep answers falsifiable. Interviewers award more credit for a narrow claim backed by repeatable evidence than for broad assurance language. When evidence conflicts, report the conflict, reduce the claim, and investigate the browser, platform, timing, or test-data difference instead of selecting the result that makes the release easiest.

How Interviewers Grade Your Answers

Interviewers grade correctness, user-centered reasoning, depth, communication, and engineering judgment. Correctness means distinguishing WCAG conformance from severity, native semantics from ARIA, and automated detection from complete evaluation. User-centered reasoning identifies who is blocked, which task fails, and whether a practical workaround exists. Depth appears when you cover state changes, error recovery, zoom, input methods, and supported assistive-technology combinations.

Use concise, reproducible evidence. Senior answers should add ownership, design-system fixes, release policy, metrics, and collaboration with disabled users. For technical preparation, study the Playwright accessibility automation complete guide and automated accessibility with axe-core.

Common Mistakes

• Treating WCAG A, AA, and AAA as defect severity.
• Claiming axe or Lighthouse certifies accessibility.
• Testing one screen reader while ignoring keyboard, low vision, cognition, speech input, touch, and switch access.
• Reciting ARIA without describing focus, keyboard behavior, and state synchronization.
• Using aria-label instead of visible native labels.
• Reporting scanner output without task impact and reproducible evidence.
• Adding positive tabindex instead of correcting DOM order.
• Blocking paste or password managers for security.
• Deferring accessibility until release.

Keep Practicing

Practice aloud at /interview-prep and connect evidence to your experience at /resume-studio. Continue with accessibility testing with Playwright, accessibility testing with Cypress, how to add accessibility checks to CI, and the mobile accessibility automation complete guide. The strongest accessibility testing interview questions reward applied judgment, not memorization.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• 500+ QA and Manual Testing Interview Questions and Answers (2026)
• API testing Scenario-Based Interview Questions and Answers (2026)
• Manual Testing Interview Questions and Answers (2026)
• Manual testing Scenario-Based Interview Questions and Answers (2026)
• Top 30 API testing Interview Questions and Answers (2026)
• Top 30 Automation Testing Interview Questions and Answers (2026)