Accessibility Testing Interview Questions

Overview

Accessibility is one of the few QA specialties where a strong candidate can stand out in minutes, because most testers can describe a broken button but few can cite the exact WCAG criterion it violates. Interviewers use accessibility questions to separate people who have run a screen reader in anger from people who have only read a blog post about alt text. This guide gets you into the first group.

You will find the questions that come up in accessibility-focused QA loops and in general interviews that include an a11y round: WCAG structure, the POUR principles, ARIA, keyboard and screen-reader testing, the automation tools, and the legal backdrop. Every question includes a sample answer with the specific success criteria and behaviors an interviewer wants to hear, in plain language you can actually say out loud.

A note on numbers. Knowing a few criterion IDs like 1.4.3 for contrast or 2.1.1 for keyboard access signals real experience. You do not need to memorize all of WCAG, but a handful of precise references will do more for your credibility than a paragraph of good intentions.

Why Accessibility Questions Reveal Real Experience

An interviewer asking about accessibility is usually checking two things at once: whether you understand that accessibility is a requirement rather than a nice-to-have, and whether you have actually tested with assistive technology. The tell is specificity. A candidate who says 'I make sure images have alt text' has read the checklist. A candidate who says 'I check that decorative images use an empty alt so the screen reader skips them, and that meaningful images describe the information, not the file name' has done the work.

Bring the disability perspective, not just the compliance one. Roughly one in five users has a disability that affects how they use software, spanning vision, motor, hearing, and cognitive differences. When you frame answers around real users (a keyboard-only user who cannot see a focus ring, a screen-reader user trapped in a modal), you sound like someone who tests for humans rather than for a lawsuit.

• Cite specific WCAG success criteria by number when you can.
• Talk about assistive tech you have actually driven: NVDA, VoiceOver, JAWS, keyboard-only.
• Frame accessibility around users and legal risk, not just an audit score.

WCAG Foundations: POUR and Conformance Levels

'What is WCAG, and what do POUR and the conformance levels mean?' WCAG (Web Content Accessibility Guidelines, currently version 2.2) organizes its success criteria under four principles: Perceivable, Operable, Understandable, and Robust, remembered as POUR. Content must be perceivable to the senses, the interface operable by keyboard and other inputs, the information understandable, and the markup robust enough for assistive technologies to interpret. Each criterion carries a level: A (essential), AA (the common legal and contractual target), and AAA (enhanced, rarely required wholesale).

'Which conformance level do teams usually target, and why?' Almost always AA. Level A alone leaves serious gaps (it does not even require 4.5:1 text contrast), while full AAA is often impractical or impossible for some content types. AA is the level referenced by most regulations and procurement standards worldwide, so 'WCAG 2.2 Level AA' is the phrase you want ready. Mention that WCAG 2.2 added criteria like 2.4.11 Focus Not Obscured and 2.5.8 Target Size (Minimum).

Perceivable: Text Alternatives and Contrast

'How do you test images for accessibility?' Distinguish three cases. Informative images need an alt value that conveys the same information the image does. Decorative images (dividers, background flourishes) need an empty alt attribute so screen readers skip them rather than announcing a file name. Complex images like charts need a short alt plus a longer description nearby or linked. The classic failure is alt text that just says 'image' or repeats adjacent visible text, which only adds noise for screen-reader users.

'What are the contrast requirements?' Success criterion 1.4.3 (Contrast Minimum, Level AA) requires a ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 18pt, or 14pt bold). Non-text elements like icons and input borders fall under 1.4.11 Non-text Contrast at 3:1. Test with a contrast checker or the browser dev tools, and remember that contrast must hold in every state: hover, focus, disabled, and placeholder text, which teams routinely fail.

Operable: Keyboard and Focus Questions

'How do you test keyboard accessibility?' Put the mouse down and drive the whole flow with Tab, Shift+Tab, Enter, Space, and the arrow keys. Every interactive element must be reachable and operable (2.1.1 Keyboard), the tab order must follow a logical reading sequence (2.4.3 Focus Order), and you must never get trapped somewhere you cannot Tab out of (2.1.2 No Keyboard Trap). Custom widgets like menus and comboboxes are where this breaks, because a div styled as a button is not keyboard-operable unless someone wired it up.

'What is a visible focus indicator, and why does it matter?' Criterion 2.4.7 Focus Visible requires that the currently focused element is clearly indicated, the ring or outline that shows a keyboard user where they are. Designers often strip the default outline for aesthetics and forget to replace it, which strands keyboard and low-vision users. WCAG 2.2 tightened this with 2.4.11 Focus Not Obscured, meaning a sticky header or cookie banner must not hide the focused element. Always test focus visibility against the real background, not a mockup.

Understandable and Robust: Forms, Errors, and Semantics

'How should an accessible form handle errors?' Every field needs a programmatically associated label, not just placeholder text, which disappears on input and often fails contrast. Errors must be identified in text, not by color alone (3.3.1 Error Identification and 1.4.1 Use of Color), associated with the offending field, and announced to assistive tech, commonly via an aria-live region or by moving focus to an error summary. Bonus points for mentioning 3.3.3 Error Suggestion, which asks you to tell the user how to fix the problem, not just that it exists.

'What does Robust mean in practice, and what is 4.1.2?' Robust is about markup that assistive technologies can reliably parse. The workhorse criterion is 4.1.2 Name, Role, Value: every interactive control must expose an accessible name (what it is called), a role (what kind of control it is), and its current value or state (checked, expanded, selected). Native HTML elements provide this for free, which is why a real button beats a div with a click handler every time. When you must build a custom control, ARIA supplies the missing name, role, and state.

ARIA Questions

'What is ARIA, and what is the first rule of ARIA?' ARIA (Accessible Rich Internet Applications) is a set of attributes that add roles, states, and properties to markup so assistive technologies understand custom widgets. The first rule of ARIA is: do not use ARIA if a native HTML element already does the job. A native checkbox or select is more reliable than a re-implemented one, because ARIA only changes what is announced, not how the element behaves. You still have to wire up the keyboard interaction yourself.

'Give an example of ARIA done wrong.' A common one is adding a button role to a div but never adding keyboard handlers, so a screen reader announces 'button' while the Enter key does nothing. Another is overusing aria-label and accidentally overriding visible text, causing a mismatch between what a sighted user reads and what a screen reader speaks, a 2.5.3 Label in Name failure. The lesson: ARIA describes, it does not implement, and a wrong ARIA role is worse than none.

Screen Reader and Assistive Tech Questions

'Which screen readers do you test with, and how do they differ?' The practical trio: NVDA (free, Windows, pairs with Firefox or Chrome), JAWS (paid, Windows, common in enterprise and government), and VoiceOver (built into macOS and iOS). Say which you use and that you know results differ across screen-reader and browser combinations, so you test the pairings your users actually run. For mobile, VoiceOver on iOS and TalkBack on Android are the reference pair.

'Walk me through screen-reader testing a modal dialog.' Focus should move into the dialog when it opens and be trapped inside it (Tab cycles within, not back to the page behind), the dialog needs an accessible name via aria-labelledby pointing at its title, and it should use the dialog role with aria-modal so the screen reader treats the background as inert. On close, focus must return to the control that opened it. Then verify by ear: open it with NVDA running and confirm the title is announced and you cannot Tab into the hidden page.

Automation and Tooling Questions

'How much of accessibility can you automate?' Be honest: automated tools reliably catch only about 30 to 40 percent of WCAG issues, the machine-checkable ones like missing alt attributes, low contrast, missing form labels, and empty links or buttons. They cannot judge whether alt text is meaningful, whether focus order makes sense, or whether a custom widget is actually operable. So automation is a fast first pass that gates the obvious regressions, and manual plus assistive-tech testing covers the rest.

'Which accessibility tools have you used?' Name the axe-core family: the axe DevTools browser extension for manual audits and axe-core wired into Playwright, Cypress, or Jest for CI regression gating. Mention Lighthouse (which uses axe under the hood) for quick scores, WAVE for a visual overlay of issues, and the browser's own accessibility inspector for reading the computed accessibility tree. The strong answer ties a tool to a stage: axe in CI on every build, manual screen-reader passes on new components.

Scenario-Based Questions

'You are handed a data table component to accessibility-test. What do you check?' Structure first: real table, th, and td elements rather than divs, with header cells marked up and associated via scope so a screen reader can announce 'column Price, row 3' as the user navigates. Check that a caption or accessible name describes the table, that sort controls expose their state with aria-sort, and that the table reflows or scrolls without loss of content at 400 percent zoom (1.4.10 Reflow). Finally, navigate it with NVDA in table mode to confirm the header associations actually read out.

'A designer wants light gray placeholder text as the only label. How do you respond?' Explain the two problems concretely. Placeholder text usually fails 1.4.3 contrast, and using it as the label fails because it vanishes the moment the user types, stranding anyone who paused or uses a screen reader. Offer the fix rather than just a veto: a persistent visible label associated with the input, with the placeholder reserved for an optional example. Framing it as a small design change, not a blocker, keeps the collaboration healthy.

Standards, Law, and Process Questions

'What laws or standards drive accessibility requirements?' In the United States, the ADA is increasingly read to cover websites, and Section 508 requires federal agencies and their vendors to meet WCAG. In Europe, EN 301 549 and the European Accessibility Act reference WCAG for public-sector and many private services. The common thread is that they all point back to WCAG 2.1 or 2.2 Level AA, so meeting that standard is the practical way to satisfy most legal obligations at once.

'Where in the development process should accessibility testing happen?' Everywhere, shifted left. Accessibility acceptance criteria belong in the story, design reviews should check contrast and focus order before a line of code, automated axe checks run in CI, and manual assistive-tech testing happens on new or changed components. Retrofitting accessibility at the end is expensive and demoralizing. Baking it into the definition of done is how mature teams keep from accruing an inaccessible backlog.

Behavioral Questions

'Tell me about a time you advocated for accessibility.' Interviewers want to see influence, not just detection. Describe a specific issue (say, a checkout that keyboard users could not complete), how you quantified the impact and the legal exposure, who you persuaded, and the outcome. The best answers show you turned a vague 'we should be accessible' into a prioritized, testable fix, and that you did it without becoming the team's compliance scold.

'How do you keep up with accessibility standards?' Mention concrete sources: the W3C WAI documentation, the WebAIM articles and their annual screen-reader survey, and the axe or Deque communities. Note that you track WCAG version changes (2.2 became the reference not long ago) and that you learn from real assistive-tech users when you can, because lived experience beats any checklist for catching the issues automation misses.

Frequently Asked Questions

Related QAJobFit Guides

• Accessibility Testing Interview Questions for QA Engineers
• Agile and Scrum Testing Interview Questions
• AI in Software Testing Interview Questions and Answers
• API Testing Interview Questions and Answers (2026)
• API Testing Interview Questions for 2 Years Experience
• API Testing Interview Questions for 3 Years Experience