Accessibility Testing Interview Questions — What SDET Panels Ask About WCAG, Axe-Core, Screen Readers, and A11y Automation in 2026
Real accessibility testing interview questions from SDET panels. Covers WCAG 2.2 levels A/AA/AAA, axe-core and Lighthouse CI integration, screen reader testing with NVDA and VoiceOver, semantic HTML and ARIA roles, automated vs manual a11y testing strategies, and the accessibility questions that separate candidates who've run an accessibility audit from those who understand inclusive testing. Built from panels at HMRC, MoD, Nationwide, and Accenture.
Published 14 May 2026 • By Mitchell Agoma
It's 11pm. Your SDET interview is in 10 hours. You've rehearsed your framework design answer until you could deliver it in your sleep. You can discuss CI/CD pipelines with the confidence of someone who's broken and fixed a dozen of them. Your API testing methodology is watertight. Then you re-read the job description one last time and your stomach drops: "Experience with accessibility testing — WCAG compliance, screen reader testing, and a11y automation."
You know accessibility matters. You've heard of WCAG. You've maybe run Lighthouse once and nodded at the score. But now you're picturing the panel asking you to explain the difference between WCAG Level A and Level AA, or describe how you'd test a modal dialog with a screen reader, or — worst of all — defend why an SDET should care about accessibility testing when there's a dedicated UX team. And you realise you've never had to articulate accessibility testing. You've only ever acknowledged it matters.
This guide is for that moment. Built from 20 years of sitting on both sides of the SDET interview table — at HMRC, the Ministry of Defence, Nationwide, and Accenture — it covers exactly what interviewers ask about accessibility testing, how they separate candidates who've integrated a11y into their testing practice from those who've only run an automated audit, and how SDET Interview Coach prepares you for accessibility-specific questions so you walk into that room with answers that demonstrate inclusive testing thinking, not accessibility buzzwords.
Why Accessibility Testing Questions Are Separating SDET Candidates in 2026
Two years ago, accessibility testing in an SDET interview was a bonus question — mention WCAG and you'd get a nod. In 2026, accessibility testing has become a compliance requirement, a legal risk differentiator, and a core quality attribute that panels specifically probe. Here's what's changed:
- The European Accessibility Act (EAA) comes into force in June 2025 — and 2026 interviews reflect it. The EAA requires products and services sold in the EU to meet WCAG 2.1 Level AA standards. For UK-based companies — even post-Brexit — the commercial reality is that products sold into European markets must comply. The US has seen a 300% increase in ADA website lawsuits over the past five years. Interviewers at Nationwide and Accenture have told Mitchell they now probe accessibility testing competence because non-compliance isn't just bad UX — it's a legal liability that can cost millions in fines and settlements. A candidate who can discuss accessibility testing as a compliance automation practice demonstrates business-aware quality engineering that pure functional testers lack.
- Accessibility has shifted from "nice-to-have" to a core quality attribute — and SDETs are expected to own it. Just as performance testing and security testing have shifted left into the SDET's territory, accessibility testing is following. Organisations that once outsourced accessibility audits to specialist consultancies are now building a11y into their CI/CD pipelines — automated checks on every PR, full audits on merge to main, and manual screen reader testing on a scheduled cadence. SDETs are being asked to own the automated accessibility testing gates: integrating axe-core into Playwright tests, configuring Lighthouse CI with accessibility budgets, and surfacing a11y regressions alongside functional test failures. The candidate who can discuss how they'd integrate accessibility testing into a CI/CD pipeline — not just run Lighthouse manually — demonstrates the operational thinking that senior SDET roles demand.
- AI-powered assistive technologies are raising the bar for accessibility testing. Screen readers are becoming more intelligent. Voice navigation and eye-tracking interfaces are entering mainstream use. The accessibility testing landscape in 2026 isn't just about checking colour contrast and alt text — it's about verifying that applications work with an increasingly diverse set of assistive technologies, many of which are AI-driven. Interviewers who've hired accessibility specialists know the difference between a tester who's ticked the WCAG checklist and a tester who understands how people with disabilities actually use software — and they're probing for that distinction in every round.
Accessibility testing isn't a separate discipline from quality assurance. It's quality assurance applied to the experience of every user — including the 15% of the global population with some form of disability. Interviewers who've been through an accessibility lawsuit or a public WCAG compliance failure know the difference between a tester who's run an automated audit and a tester who understands what the findings mean — and they're probing for that distinction in every round.
WCAG 2.2 Essentials — The Framework Every Accessibility Testing Interview References
Every accessibility testing interview starts with WCAG. It's the shared vocabulary of web accessibility, and interviewers expect you to know it — not just the acronym, but what the levels mean, how the principles map to testing, and what the most common violations look like in practice. Here's what a strong answer covers for the most commonly probed WCAG concepts in SDET interviews:
The Four WCAG Principles — POUR
Every accessibility testing interview expects you to know the POUR framework: Perceivable — information and UI components must be presentable to users in ways they can perceive (not invisible to all senses). This covers text alternatives for non-text content (alt text for images), captions for multimedia, and content that can be presented in different ways without losing meaning. Operable — UI components and navigation must be operable (not requiring interactions a user cannot perform). This covers keyboard accessibility (all functionality available from a keyboard), sufficient time to read and use content, and content that doesn't cause seizures (no flashing content above 3 flashes per second). Understandable — information and the operation of the UI must be understandable (not beyond the user's comprehension). This covers readable text, predictable web pages (consistent navigation), and input assistance (error identification and suggestions). Robust — content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This covers compatibility with current and future user tools — using valid, semantic HTML and proper ARIA when HTML semantics aren't sufficient. The candidate who can map test scenarios to POUR principles — "I'm testing keyboard navigation because it falls under Operable; I'm testing alt text because it falls under Perceivable" — demonstrates structured accessibility thinking, not just checklist memorisation.
WCAG Conformance Levels — A, AA, and AAA
"What's the difference between WCAG Level A, AA, and AAA?" This question appears in nearly every accessibility testing interview. Level A is the minimum — the most basic web accessibility features. Without Level A, the site is effectively impossible for some groups to use. Examples: all non-text content must have a text alternative (1.1.1), all functionality must be operable through a keyboard interface (2.1.1), and content must not be designed in a way that is known to cause seizures (2.3.1). Level A is non-negotiable — these are barriers, not inconveniences. Level AA deals with the biggest and most common barriers for disabled users. This is the standard that most accessibility regulations target — including the European Accessibility Act, Section 508, and the UK's Public Sector Bodies Accessibility Regulations. Examples: colour contrast ratio of at least 4.5:1 for normal text (1.4.3), consistent navigation across pages (3.2.3), and labels or instructions for input fields (3.3.2). Level AAA is the highest and hardest to achieve — it's aspirational and not required for full sites. Examples: contrast ratio of at least 7:1 (1.4.6), sign language interpretation for all prerecorded audio (1.2.6), and context-sensitive help (3.3.5). The strong interview answer: "For most organisations, WCAG 2.2 Level AA is the compliance target. I'd configure automated testing to catch Level A and most Level AA violations automatically. Level AAA requires manual testing and is typically reserved for specific user needs — a banking app for elderly users might target AAA, a startup's MVP might target AA. The key is knowing which level your product needs and building testing that verifies it."
WCAG 2.2 New Success Criteria for 2026
"What's new in WCAG 2.2, and how do you test for it?" This is the question that separates candidates who've kept up with accessibility standards from those who memorised WCAG 2.0 five years ago and stopped. WCAG 2.2 (published October 2023) added nine new success criteria. The ones SDET interviewers specifically probe: (1) Focus Not Obscured (2.4.11, Level AA) — when a UI component receives keyboard focus, it must not be entirely hidden by other content like sticky headers or cookie banners. Test by tabbing through every interactive element and verifying each is at least partially visible. (2) Focus Appearance (2.4.13, Level AAA) — the focus indicator must have sufficient contrast and size. Many sites use thin, low-contrast focus outlines that fail Level AA. (3) Dragging Movements (2.5.7, Level AA) — any action that uses dragging must also be achievable by a single pointer without dragging. If a Kanban board requires drag-and-drop to move cards, there must be a keyboard or click-based alternative. (4) Target Size (2.5.8, Level AA) — interactive elements must be at least 24x24 CSS pixels in size (with some exceptions). Tiny touch targets fail this. (5) Consistent Help (3.2.6, Level A) — help mechanisms like contact forms, chat, or FAQs must be consistently positioned across pages. (6) Accessible Authentication (3.3.7, Level AA) — cognitive function tests like CAPTCHAs must not be required for authentication unless alternatives exist. (7) Redundant Entry (3.3.8, Level A) — previously entered information must be auto-populated or available to select. The candidate who can discuss WCAG 2.2 criteria — and how they'd test for them — demonstrates that accessibility testing is an active part of their practice, not a CV keyword.
The WCAG question that catches most candidates: "What's the difference between automated and manual accessibility testing — and what can each catch?" The strong answer: "Automated testing catches roughly 30-40% of WCAG violations — things machines can verify: colour contrast ratios, missing alt text, missing form labels, valid ARIA attributes, heading hierarchy, and HTML validation. The tools are fast, repeatable, and belong in CI/CD — axe-core in Playwright tests, Lighthouse CI in build pipelines. Manual testing catches the remaining 60-70%: keyboard navigation (can you reach every interactive element in a logical order?), screen reader experience (does the page read naturally, or is it confusing?), focus management (is focus sent to the right place after a modal opens?), meaningful alt text (the machine can detect missing alt text, but only a human can judge if it's good alt text), and complex interactive patterns — drag-and-drop, carousels, multi-step forms. The SDET's role: automate what can be automated, and build a manual testing checklist for what can't." This distinction — and knowing where the SDET's accessibility responsibility ends — demonstrates judgement that interviewers at government, financial services, and enterprise specifically look for.
Accessibility Testing Tools — Axe-Core, Lighthouse, WAVE, NVDA, and What Interviewers Expect You to Know
Interviewers don't expect you to be an accessibility specialist. But they do expect you to know the tools in the a11y testing ecosystem — which tool does what, when you'd use each, and how to integrate them into an automated testing pipeline. Here's what they ask about each tool:
Axe-Core — The Automated Accessibility Engine
Axe-core is the open-source accessibility testing engine developed by Deque Systems — and it's the foundation that powers most automated a11y tools (Lighthouse, jest-axe, cypress-axe, and the browser extensions). The interview question: "How would you integrate axe-core into your automated test suite?" The strong answer: "Axe-core has native integrations for every major testing framework. With Playwright, I'd use @axe-core/playwright: import it, inject it into each page, run await new AxeBuilder({ page }).analyze(), and assert that results.violations is empty. I'd configure axe to run on every page navigation and every significant UI state — modals, dropdowns, expanded sections, error states, and loading states. I'd set the axe run options to target WCAG Level AA by default and tag critical pages with Level AAA checks. Crucially, I'd run axe on component-level tests (Storybook or isolated components) — this catches violations at the source before they reach integration tests. For CI/CD: axe results in JSON format, with violation nodes and remediation guidance. I'd fail the build on any 'critical' or 'serious' violations and publish the report as a pipeline artifact. The key: axe-core is fast (sub-second for most pages) and has near-zero false positives — that's why it's the industry standard and why Deque publish that axe catches ~57% of WCAG issues automatically, more than any other tool." Bonus: mentioning that axe-core supports custom rules via axe.configure() — for organisation-specific accessibility patterns that aren't covered by the default rule set — demonstrates genuine integration experience.
Lighthouse and Lighthouse CI — Accessibility Scoring in the Pipeline
"How do you use Lighthouse for accessibility testing in your pipeline?" Lighthouse is Google's automated auditing tool — it runs in Chrome DevTools, as a CLI, as a Node module, and as a CI action. It's the most widely used accessibility auditing tool. The interview answer: "Lighthouse produces an accessibility score (0-100) based on a subset of axe-core rules plus additional manual-auditable checks. For CI/CD: I use Lighthouse CI — it runs Lighthouse against key pages in the pipeline, compares scores against defined budgets, and fails the build if the accessibility score drops below the threshold (typically 90+ for accessibility). The key features: (1) lighthouserc.json defines which URLs to test and the score budgets — {"accessibility": 0.9} means the build fails if the score drops below 90. (2) Lighthouse CI Assertions compare current results against the baseline — you can assert specific categories haven't regressed. (3) The Lighthouse report includes specific violations with element selectors and remediation guidance. The distinction interviewers probe: 'What does a Lighthouse accessibility score of 100 actually mean?' The strong answer: 'It means Lighthouse's automated checks passed — it doesn't mean the site is fully accessible. Lighthouse can't test keyboard navigation completeness, screen reader UX quality, or whether alt text is meaningful. A score of 100 is a green flag that automated structural checks pass — it is not a certification of full WCAG compliance. Manual testing is still required.' The candidate who qualifies the Lighthouse score — rather than treating it as a source of truth — demonstrates maturity in accessibility testing."
WAVE and Browser Extensions — Rapid Manual Auditing
"When would you use WAVE over axe-core or Lighthouse?" WAVE (Web Accessibility Evaluation Tool) is a browser extension and online service that visualises accessibility issues directly on the page — it overlays icons and indicators on the rendered page to show where violations exist. The answer: "WAVE is my go-to for rapid exploratory accessibility testing. It's not a CI/CD tool — it's a manual auditing assistant. I use WAVE when: (1) I'm doing a first-pass accessibility review of a new feature — it gives me immediate visual feedback on contrast issues, missing labels, and structural problems. (2) I need to explain accessibility issues to developers or product owners — the visual overlay makes it obvious what's wrong and where. (3) I'm verifying heading structure, landmark regions, and ARIA usage — WAVE makes these visible in a way that code-level tools don't. (4) I'm checking a page's accessibility in context — WAVE overlays the information on the rendered page, so I can see issues in their visual context. WAVE is complementary to axe-core and Lighthouse — I use axe in CI/CD for automated gatekeeping, and WAVE during manual review for contextual evaluation." The tool-awareness-with-context demonstrates you understand the accessibility testing ecosystem as a system, not just individual tools.
Screen Readers — NVDA, VoiceOver, and JAWS
"How do you test with a screen reader — and which one do you use?" This is the question that separates candidates who've done manual accessibility testing from those who've only run automated tools. The answer: "Screen reader testing is manual by nature — it requires a human to operate the screen reader and evaluate the experience. I test with NVDA (NonVisual Desktop Access) on Windows — it's the most popular free screen reader, with broad browser support in Firefox and Chrome. On macOS, I use VoiceOver (built-in, Cmd+F5 to toggle) with Safari. For enterprise clients who require JAWS (commercial, Windows-only), I test on JAWS when the budget supports it. My testing process: (1) Turn on the screen reader, close my eyes or turn off my monitor, and navigate the application using only the keyboard. (2) Verify that every interactive element is reachable and announces its role, name, and state correctly ('Submit button, collapsed,' 'Open menu button, expanded'). (3) Test dynamic content changes — when a form validation error appears, does the screen reader announce it? When a modal opens, does focus move to the modal? (4) Test complex widgets — does the autocomplete announce suggestions? Does the date picker announce selected dates? (5) Verify the reading order — the screen reader should read content in a logical order that matches the visual layout. (6) Verify ARIA live regions — do status messages, loading indicators, and notifications get announced to screen reader users? The critical interview insight: automated tools can verify that ARIA attributes exist and are syntactically valid, but they cannot verify that a screen reader user can actually complete a task. That requires manual testing. The candidate who can describe a manual screen reader testing process — not just name the tools — demonstrates genuine a11y testing experience."
Colour Contrast Analysers and Simulators
"How do you test for colour-related accessibility issues?" Colour accessibility covers more than contrast — it covers colour-blindness, colour-as-the-only-meaning-indicator, and high-contrast mode compatibility. The tooling: (1) Colour Contrast Analyser (CCA) by TPGi — the definitive desktop tool for measuring contrast ratios. It samples foreground and background colours and reports the ratio against WCAG thresholds (4.5:1 for AA, 7:1 for AAA, 3:1 for large text). (2) Chrome DevTools — the CSS Overview panel and the accessibility pane in Elements show contrast information inline. (3) Colour blindness simulators — Chrome's Rendering tab includes built-in colour vision deficiency simulation (protanopia, deuteranopia, tritanopia, achromatopsia). I use these to verify that colour is never the sole means of conveying information — error states should use icons alongside red, charts should use patterns alongside colours, links should be underlined or have a non-colour differentiator. (4) axe-core automatically detects contrast violations based on the computed styles, with element-level detail. The key testing insight: I test in high-contrast mode (Windows High Contrast Mode) and with forced-colors CSS media query to verify the application remains usable when users override colours. A site that looks great in normal contrast but becomes unusable in high-contrast mode fails accessibility testing. The candidate who discusses colour blindness testing — not just contrast ratios — demonstrates a user-centred approach to accessibility.
The accessibility tool question that separates seniors: "How do you avoid a false sense of security from automated accessibility testing?" This demonstrates you understand the limits of automation. The answer: "Automated accessibility testing is a floor, not a ceiling. I set the expectation with stakeholders early: axe-core and Lighthouse catch structural violations — missing alt text, insufficient contrast, invalid ARIA, missing form labels. They don't catch: meaningful alt text quality, logical focus order, screen reader UX, keyboard navigation completeness, or whether a user can actually complete a task. My strategy: automated testing as a CI/CD gate — it catches regressions before they reach production. Manual testing as a scheduled activity — screen reader walkthroughs, keyboard-only navigation tests, and WCAG checklist reviews on a quarterly cadence or before major releases. The automated tests prevent known violations from recurring. The manual tests verify that the experience is usable — not just technically compliant. Both are necessary; neither is sufficient alone."
ARIA, Semantic HTML, and Keyboard Navigation — The Technical Trio Every Interview Probes
These three topics form the technical backbone of accessibility testing. Every panel will touch at least one, and senior-level interviews will dig deep into all three. Here's what they ask and how to answer:
ARIA — When to Use It and When Not To
"Explain ARIA — and when you shouldn't use it." This question tests whether you understand ARIA as a supplement to HTML, not a replacement for it. The interview answer: "ARIA (Accessible Rich Internet Applications) is a set of attributes that supplement HTML to improve accessibility for assistive technologies. It provides roles (what is this element? — role="tab", role="alert"), properties (what are its characteristics? — aria-required="true", aria-expanded="false"), and states (what's its current condition? — aria-selected="true", aria-disabled="true"). The critical rule: No ARIA is better than bad ARIA. ARIA overrides native HTML semantics. If you add role="button" to a <div> but don't handle keyboard events, you've made the element less accessible than if you'd left it as a generic div. The First Rule of ARIA Use: if you can use a native HTML element or attribute with the semantics and behaviour you require, do that instead of repurposing an element with ARIA. Use <button> instead of <div role="button">. Use <nav> instead of <div role="navigation">. In testing, I verify that: (1) ARIA attributes are used on elements where they're allowed (some roles only support specific properties), (2) ARIA attributes have valid values (aria-expanded must be true/false, not 'yes'), (3) the ARIA role matches the element's behaviour (a role="tab" element must actually function as a tab), and (4) required relationships exist (aria-controls references an element that exists, aria-labelledby references an element with text content). Tools like axe-core catch invalid ARIA usage automatically."
Semantic HTML — The Foundation of Accessibility
"Why does semantic HTML matter for accessibility — and how do you test for it?" The answer: "Semantic HTML is the single most impactful accessibility practice because it provides built-in keyboard interaction, focus management, and screen reader announcements without any additional code. A <button> is focusable by default, activates on Enter and Space, and announces its role and label to screen readers — all without ARIA or JavaScript. A <div onclick="..."> is none of those things. My testing approach: (1) Verify landmark regions — the page should use <header>, <nav>, <main>, <footer>, <aside>, and <section> appropriately. Screen reader users navigate between landmarks to skim pages. (2) Verify heading hierarchy — there should be one <h1>, and headings should nest logically (h1 → h2 → h3, not h1 → h3 → h2). Screen reader users navigate by heading. (3) Verify form semantics — every <input> should have an associated <label> (either wrapping the input or using for/id association). Form controls should use native elements (<select>, <textarea>, <fieldset> with <legend> for groups) rather than custom implementations that break accessibility. (4) Verify table semantics — data tables should use <thead>, <tbody>, <th> with scope attributes, and <caption>. Layout tables should not use table markup at all. Automated tools detect many semantic HTML issues — missing labels, heading skips, and missing landmarks — but the logical structure (does the heading hierarchy make sense for the content?) requires manual review."
Keyboard Navigation Testing — The Acid Test
"How do you test that a web application is fully keyboard-accessible?" Keyboard accessibility is the foundation of accessibility — if it doesn't work with a keyboard, it doesn't work with a screen reader, a switch device, or voice navigation. The testing approach: (1) Tab order — tab through every interactive element. The focus order should follow the visual layout (left to right, top to bottom). Tab should not skip elements or jump unexpectedly. (2) Focus visibility — every focused element should have a visible focus indicator (outline, highlight, border change). WCAG 2.2 requires the focus indicator to have a minimum contrast ratio and size. (3) All functionality — every action that can be performed with a mouse must also be performable with a keyboard. Open menus, select options, activate buttons, submit forms, navigate between pages — all accessible via keyboard alone. (4) No keyboard traps — focus must be able to leave every component using standard keyboard commands. A modal that captures focus is acceptable, but the user must be able to close it via keyboard (Escape key) and return to the previous focus point. (5) Skip links — the first focusable element on the page should be a 'Skip to main content' link that's visible on focus. This allows keyboard users to bypass repetitive navigation. (6) Focus management — after dynamic content changes, focus should move to the new content. After opening a modal, focus should move inside the modal. After closing a modal, focus should return to the element that triggered it. After submitting a form with errors, focus should move to the first error. (7) Keyboard shortcuts — verify that custom keyboard shortcuts don't conflict with screen reader or browser shortcuts. The test: unplug the mouse and navigate the entire application — can you complete every user journey? If not, the application fails keyboard accessibility testing."
Real Accessibility Testing Interview Scenarios — What Panels Actually Ask
Drawing from panels Mitchell has conducted at HMRC, MoD, Nationwide, and consulting for Accenture, here are the accessibility testing scenarios that appear in SDET interviews — and what a strong answer looks like for each.
"Integrate axe-core accessibility checks into this Playwright test suite."
This is the practical exercise that appears in accessibility-aware SDET interviews. A complete answer covers: (1) Install @axe-core/playwright as a dev dependency. (2) Import AxeBuilder in the test file. (3) After navigating to each page, run: const accessibilityScanResults = await new AxeBuilder({ page }).analyze();. (4) Assert that violations are empty: expect(accessibilityScanResults.violations).toEqual([]);. (5) For better debugging, log violations before asserting: if (results.violations.length > 0) { console.log(JSON.stringify(results.violations, null, 2)); } — this prints the violations, the affected elements, and remediation guidance. (6) Configure axe options for the appropriate WCAG level: .withTags(['wcag2a', 'wcag2aa']) to target Level AA. (7) Exclude known third-party content: .exclude('.third-party-widget') for content you don't control. (8) Run accessibility checks on states not just pages — after opening a modal, after expanding an accordion, after form submission with errors, after loading dynamic content. (9) Consider performance: axe runs are fast (typically 50-200ms per page), but running them on every test can add up. Run axe on key pages and critical user journeys, and consider a separate accessibility test suite that runs nightly with full coverage. The interviewer evaluates: correct axe-core API usage, understanding of WCAG tags, handling of violations (logging before asserting), and state-aware testing (not just page-load testing).
"Lighthouse reports an accessibility score of 95. Is the site accessible?"
This tests whether you understand the gap between automated scores and real accessibility. The weak answer: "Yes, 95 is above the 90 threshold — it passes." The strong answer: "A Lighthouse score of 95 is a positive signal, but it's not a guarantee of accessibility. Here's what I'd do: (1) Check the specific violations that cost 5 points — Lighthouse lists them with element selectors. Address those immediately. (2) Recognise what Lighthouse can't test: keyboard navigation completeness, screen reader UX quality, meaningful alt text, logical focus order, focus management for dynamic content, and colour-as-meaning-indicator. (3) Perform manual keyboard-only testing — navigate the entire application without a mouse and verify every user journey is completable. (4) Perform screen reader testing — use NVDA (Windows) or VoiceOver (macOS) and verify the experience is coherent and navigable. (5) Test with colour blindness simulation — verify that colour is never the sole means of conveying information. (6) Test at different zoom levels — 200% and 400% — to verify content doesn't overflow or get cut off. (7) Review the 'additional items to manually check' section of the Lighthouse report — these are potential issues Lighthouse identified but couldn't confirm. A Lighthouse score of 95 with a broken keyboard navigation flow is an inaccessible site with a misleading score. The score is a starting point, not a certification."
"Your automated accessibility tests pass, but a screen reader user reports they can't complete checkout. What went wrong?"
This tests your accessibility debugging methodology and your understanding of the gap between automated and manual testing. The strong answer walks through a structured investigation: (1) First, reproduce the issue — get the screen reader and browser version the user reported, navigate to the checkout flow, and attempt to complete it with the screen reader running. Can you reproduce the blocker? (2) Examine the automated test coverage — are we testing the checkout flow with axe-core, or only static pages? Axe on the page-load state won't catch issues in multi-step checkout flows where focus management, dynamic form validation, and payment widget accessibility matter. (3) Check each checkout step manually: (a) Cart review — are product details, quantities, and prices announced correctly? (b) Shipping form — are all form fields labelled? Are validation errors announced to screen readers (aria-live region or focus management)? (c) Payment step — is the payment widget keyboard-accessible? If it's an iframe, does it have a title? (d) Order confirmation — is the confirmation announced to the screen reader? (4) Check focus management — after each step transition (cart → shipping → payment → confirmation), is focus moved to the new content, or does it stay on the previous step's submit button? (5) Check for timeouts — does the checkout session timeout while the screen reader user is navigating, because screen reader navigation takes longer than visual scanning? (6) Check ARIA live regions — are status messages, loading indicators, and error notifications using aria-live so they're announced without moving focus? The key insight: automated tests verify WCAG conformance at the page level; manual screen reader testing verifies the user journey is completable. If the automated tests pass but a screen reader user can't complete checkout, our manual testing coverage — specifically, user-journey-level screen reader testing — has a gap."
"How do you prioritise accessibility violations when there are hundreds?"
This tests your accessibility triage methodology — the practical reality that most applications have more violations than can be fixed in a single sprint. The answer: "I use an impact-and-frequency matrix. Impact: does this violation block a user from completing a task, or is it cosmetic? A missing form label on a checkout field is critical — the user can't complete the purchase. A missing alt text on a decorative image is low-priority — it doesn't block functionality. Frequency: is this violation on every page or one rarely-visited admin page? A missing 'Skip to main content' link affects every keyboard user on every page visit — high frequency. A colour contrast issue on a tertiary page deep in the navigation — lower frequency. My prioritisation tiers: (1) Critical — fix immediately: anything that blocks users from completing core tasks — missing form labels on critical flows, keyboard traps, missing alt text on functional images (buttons, links), broken focus order on checkout/login. (2) High — fix this sprint: violations on high-traffic pages that degrade experience but don't block functionality — insufficient colour contrast on primary CTAs, missing landmarks on main pages, heading structure issues on landing pages. (3) Medium — backlog: violations on lower-traffic pages, or violations that have workarounds — missing labels on search filters (if the placeholder text serves as a label), ARIA landmarks missing on secondary pages. (4) Low — monitor: cosmetic or best-practice issues that don't affect usability — redundant ARIA attributes, deprecated ARIA roles that still work, minor contrast issues on non-essential decorative elements. I communicate prioritisation through impact scoring — each violation is tagged with the WCAG success criterion it violates and the user impact ('blocks screen reader users from submitting forms' vs 'insufficient contrast on a decorative border'). This makes the business case for fixing accessibility issues legible to product owners who may not understand WCAG but understand blocked users."
5 Common Accessibility Testing Mistakes That Cost SDET Candidates Offers
After watching hundreds of candidates navigate accessibility testing questions, Mitchell has identified the specific mistakes that cause interviewers to lean back and wait for the next candidate. These aren't gaps in accessibility knowledge — they're gaps in how you present that knowledge.
Mistake #1: Treating Accessibility Testing as a Specialist's Job
The single most common mistake SDET candidates make: saying "accessibility testing is for the UX team" or "we have accessibility specialists for that." In 2026, this answer signals you haven't kept up with the shift-left movement in accessibility. Accessibility testing — like security testing and performance testing — has moved into the SDET's territory. The strong answer: "As an SDET, I own the automated accessibility testing gates — axe-core integration in Playwright, Lighthouse CI with accessibility budgets, and automated violation detection in the CI/CD pipeline. I work with accessibility specialists on manual testing — screen reader walkthroughs, usability testing with disabled users, and complex interactive pattern evaluation. But the automated gates that prevent an accessibility regression from reaching production are my responsibility. My role is to catch the 30-40% of WCAG violations that can be automated so the accessibility specialists can focus on the 60-70% that need human judgement." This demonstrates you understand the modern SDET-accessibility boundary, not an outdated siloed model.
Mistake #2: Equating Automated Testing with Full Accessibility Coverage
"I run axe-core — the site passes, so it's accessible." This answer tells the interviewer you've never done manual accessibility testing. Automated tools catch 30-57% of WCAG violations (depending on the tool and configuration). They cannot test: whether keyboard navigation is logical and complete, whether screen reader output is coherent and useful, whether alt text is meaningful ('Photo of a cat' is technically compliant but useless on an e-commerce product page), whether focus management works across dynamic content changes, whether colour is the sole indicator of meaning, and whether a user can actually complete tasks. The strong answer: "Automated accessibility testing is my CI/CD gate — it catches regressions and enforces a baseline. Manual accessibility testing — keyboard-only navigation, screen reader walkthroughs, colour blindness testing, and task-completion testing — is my scheduled quality activity. Together they provide coverage. Separately, they provide a false sense of security." The candidate who can articulate this gap demonstrates genuine accessibility testing maturity.
Mistake #3: Focusing on Compliance Over User Experience
"The page meets WCAG 2.2 Level AA — our accessibility work is done." This tells the interviewer you're doing compliance-driven accessibility, not user-centred accessibility. WCAG compliance is a floor — it's the minimum legal standard. It doesn't guarantee a good experience. A page can meet every WCAG Level AA success criterion and still be frustrating to use with a screen reader: alt text that's technically present but meaningless, a keyboard navigation order that's logical to the algorithm but confusing to a user, focus indicators that are visible but distractingly styled. The strong answer: "I target WCAG compliance as my automated testing baseline — if it doesn't meet Level AA, it fails the pipeline. But beyond compliance, I test for usability: can a screen reader user complete core tasks in a reasonable time? Is the reading order intuitive? Are dynamic changes announced in a helpful way? I advocate for usability testing with disabled users — it reveals friction that automated compliance testing can't detect. The goal is an accessible experience, not just a compliant page." This mindset — compliance is the starting point, usability is the goal — separates accessibility-competent SDETs from checkbox-testers.
Mistake #4: Not Testing with Actual Assistive Technologies
"I use the Chrome DevTools accessibility panel — that's my screen reader testing." This answer signals you've never experienced what a screen reader user actually hears. The Chrome DevTools accessibility tree shows the computed accessible name, role, and properties — it's useful for debugging why a screen reader announces something incorrectly. But it's not a substitute for using a screen reader. The experience of hearing a page read aloud — the pacing, the context switching, the navigation between landmarks — cannot be simulated by reading the accessibility tree. The strong answer: "I use the accessibility tree for rapid debugging — it shows me what the browser is exposing to assistive technologies. But I also test with NVDA on Windows and VoiceOver on macOS. I navigate the application with the screen reader running and evaluate the experience. I verify that: all interactive elements announce correctly, dynamic content changes are communicated, form errors are clear and actionable, and the reading order makes sense. The accessibility tree tells me what's possible for assistive technologies. The screen reader tells me what's actual for users." This demonstrates you've moved beyond theoretical accessibility into practical, user-experience-focused testing.
Mistake #5: Memorising WCAG Numbers Without Understanding the User Impact
Every candidate who's read an accessibility blog can recite "1.1.1 Non-text Content" and "1.4.3 Contrast (Minimum)." Interviewers are testing whether you've gone beyond memorisation. When you mention Success Criterion 1.1.1, follow it with what that means for users: "A blind user interacting with a product page needs to know the product image exists and understand what it depicts, even if they can't see it — that's what alt text provides." When you mention 2.1.1 Keyboard, follow it with: "A user with motor disabilities who can't use a mouse must be able to complete every action using only the keyboard — including navigating complex widgets like date pickers and drag-and-drop interfaces." The candidates who win interviews don't list WCAG numbers — they describe the user experience those numbers protect. If you can't describe which users benefit from a WCAG criterion and how, don't cite the number. The interviewer who's hired an accessibility specialist will probe your understanding by asking "who does this criterion help, and how?" — and a number alone won't answer the question.
What a Real Accessibility SDET Interview Looks Like — Timed Breakdown
Drawing from panels Mitchell has conducted across government, defence, and enterprise, here's how accessibility testing questions typically appear in a 60-minute SDET interview:
Experience Probe
"What accessibility testing experience do you have?" This opener tests whether you've genuinely practised accessibility testing or just added WCAG to your CV. Be honest about your level. If you've primarily integrated axe-core and run audits: "I've integrated axe-core accessibility checks into our Playwright test suite — running automated WCAG Level AA checks on key pages and user journeys. I've configured Lighthouse CI with accessibility budgets that fail the pipeline on score drops. I've done manual keyboard navigation testing and basic screen reader testing with NVDA. I haven't conducted formal accessibility audits or usability testing with disabled users — I've worked alongside accessibility specialists who handle that. My strength is automating accessibility testing as a CI/CD gate and catching accessibility regressions before they reach production." This answer demonstrates accessibility testing competence while being honest about its scope.
Technical A11y Testing & Tool Integration
"Walk me through how you'd integrate accessibility testing into a Playwright test suite" or "Explain WCAG conformance levels." You may be asked to write axe-core integration code or discuss WCAG principles. Focus on: correct tooling choices (axe-core for automated, manual for keyboard/screen reader), WCAG level targeting (AA is the compliance standard), testing states not just pages (modals, expanded sections, error states), and CI/CD integration (accessibility budgets, pipeline gating). Interviewers evaluate your ability to turn accessibility requirements into working test automation — and they'll ask follow-ups on why you chose specific approaches.
Accessibility Strategy & Problem-Solving
"How would you introduce accessibility testing to a team that's never done it?" This probes your change management and advocacy skills — because accessibility testing often means convincing teams to adopt new practices. Discuss: (1) Start with automated tools — axe-core integration is low-friction and provides immediate, visible value. (2) Build a baseline — run a full accessibility audit and document the current state. (3) Set achievable targets — "we'll fix all critical and high-severity violations this quarter, medium next quarter." (4) Integrate into the definition of done — new features must pass automated accessibility checks before they're considered complete. (5) Educate through the build pipeline — developers see accessibility violations the same way they see failing tests: as build failures that need fixing. (6) Celebrate wins — when a screen reader user reports a positive experience, share it with the team. Accessibility testing adoption is as much about culture as it is about tools.
Accessibility & Business Impact
"An accessibility violation is found in production. What's your response?" This tests whether you treat accessibility failures as operational incidents. Discuss: (1) Assess the impact — does this violation block users from completing core tasks? If yes, treat it as an incident. (2) Determine the scope — is this a regression (a new feature broke accessibility) or a pre-existing issue? (3) If a regression: revert or hotfix, investigate why the automated accessibility tests didn't catch it (wrong test scope? wrong WCAG level? test not running?), and add a regression test. (4) If pre-existing: log in the accessibility backlog with severity and user impact, and advocate for fixing it based on legal risk and user exclusion. (5) Communicate to stakeholders — accessibility failures are compliance risks and should be reported to the accessibility champion, product owner, and legal where relevant. The candidate who treats an accessibility production issue with the same seriousness as a security vulnerability or data loss demonstrates operational maturity.
Your Questions
Ask about their accessibility testing maturity: "What's your current accessibility testing setup — do you run automated accessibility checks in CI/CD, or is accessibility testing mostly manual? What WCAG level do you target, and how do you verify conformance? Do SDETs here own the automated accessibility testing, or is that a separate accessibility team activity? Have there been any accessibility-related incidents or legal challenges, and how did they change your testing approach? Do you conduct usability testing with disabled users, and how are those findings fed back into the automated test suite?" Questions that probe their accessibility posture demonstrate you're thinking about how you'd contribute to their specific environment.
Why Accessibility Testing Competence Is Becoming a Career Accelerator for SDETs
After 20 years watching the UK testing market evolve — from HMRC to the MoD, from Nationwide to Accenture — Mitchell has observed a consistent pattern: SDETs who add accessibility testing to their skill set advance faster and stand out more than pure functional automation engineers. Here's why:
- Accessibility-competent SDETs are rare and the demand is growing fast. The pool of testers who can discuss Playwright locator strategies is deep. The pool who can also discuss WCAG 2.2 conformance levels, axe-core integration, screen reader testing, and the European Accessibility Act's legal implications is remarkably shallow. In every panel Mitchell has conducted where a candidate demonstrated genuine accessibility testing competence, the post-interview debrief included the phrase "they understand accessibility — that's valuable." That value translates to offers and differentiation — the same way security testing competence has become a premium differentiator. The European Accessibility Act, ADA lawsuits, and the UK's Public Sector Bodies Accessibility Regulations have created compliance obligations that organisations need accessibility testing to address — and the supply of SDETs who can deliver that testing hasn't caught up.
- Accessibility testing positions you as a quality advocate, not just a test automator. When you argue that a missing accessible name on a form field blocks real users from completing a purchase — not just that it fails a WCAG criterion — you're talking the language of product quality, not test compliance. When you demonstrate that automated accessibility testing prevented a production regression that would have exposed the company to ADA litigation risk, the General Counsel hears about it, not just the QA manager. Accessibility testing — more than any other testing domain — connects the SDET's work to legal compliance, user inclusion, and social responsibility. SDETs who frame accessibility testing as risk management and user advocacy get invited to conversations where careers advance.
- The regulatory landscape is expanding, not contracting. The European Accessibility Act (June 2025), the Americans with Disabilities Act (ADA) with its rapidly increasing website litigation, Section 508 in the US, the UK's Equality Act 2010 and Public Sector Bodies Accessibility Regulations, and the Accessible Canada Act — the global regulatory trend is unidirectional: more accessibility requirements, more enforcement, more liability. Organisations are scrambling to build accessibility testing capability, and the SDETs who can deliver it are in short supply. The SDETs building accessibility testing skills now — not just running axe-core, but understanding WCAG, screen reader testing, and accessibility-first automation — are positioning themselves for compliance-driven roles that command premium compensation.
The candidates adding accessibility testing to their repertoire now — not just running audits, but understanding WCAG conformance, screen reader testing, and the automated-to-manual testing spectrum — are the ones who'll walk into 2027 interviews as compliance-aware SDETs while their purely functional peers are still competing for the same roles.
How to Prepare for Your Accessibility Testing Interview — Starting Tonight
You don't need to be an accessibility specialist. You need to understand WCAG principles and conformance levels, be able to discuss accessibility testing tools and their integration into CI/CD pipelines, articulate the difference between automated and manual accessibility testing, and — most importantly — demonstrate that you think about accessibility as a core quality attribute that can be tested, automated, and gated in CI/CD, just like functional correctness. Here's the 3-step plan:
- Download SDET Interview Coach from the iOS App Store and complete the 2-minute onboarding assessment. Select your target stack and seniority level. The app's 800+ question bank includes accessibility testing topics — WCAG 2.2 principles and conformance levels, axe-core integration with Playwright and Cypress, Lighthouse CI accessibility budgets, ARIA roles and properties, keyboard navigation testing, screen reader testing with NVDA and VoiceOver, and accessibility testing strategy — calibrated to all five seniority levels. Even if accessibility testing is a gap in your current role, the app surfaces questions at your level so you can build confidence before the interview exposes the gap.
- Run an accessibility testing mock interview today. Pick Accessibility Testing as your topic, set a 30-minute timer, and answer the questions out loud. The AI feedback scores you on technical accuracy, completeness, communication, and code quality — showing you exactly where your a11y knowledge gaps are before the real panel finds them. The AI mock interviewer asks adaptive follow-ups on WCAG conformance, tooling integration, and real-world accessibility scenarios, just like a real panel.
- Use Job Match for your target role. If the job description mentions "accessibility," "WCAG," "a11y," "ADA compliance," "screen reader," "axe-core," or "Lighthouse accessibility," paste it into Job Match. You'll get 50 questions tailored to that exact role's accessibility testing expectations — no guessing whether they'll ask about WCAG 2.2 new success criteria, ARIA best practices, or CI/CD integration patterns.
The candidates who prepare for accessibility testing questions now — who can articulate WCAG's POUR principles, who understand the difference between automated and manual accessibility testing, and who can discuss integrating axe-core into a CI/CD pipeline with the same fluency they discuss Playwright — are the ones who'll walk into panels and surprise interviewers with a competency they weren't necessarily expecting to find. Accessibility testing isn't a specialist silo any more. It's a core SDET competency, and with SDET Interview Coach, available on the iOS App Store, you can build that accessibility testing confidence before you ever sit down with an interviewer.
If you're building your accessibility testing skills from a test automation background, start with our guide on Test Automation Framework Design — accessibility testing should be a first-class concern in your framework architecture, not an afterthought. For the CI/CD pipeline integration where accessibility gates live, see our guide on CI/CD Pipeline Testing Interview Questions. For mobile accessibility testing where WCAG overlaps with platform-specific guidelines, see Mobile Test Automation Interview Questions 2026. And for the API testing that powers accessible applications, see API Testing Interview Questions 2026.
Ready to Transform Your Testing?
The AI Test Automation Playbook gives you everything you need: Playwright setup, Claude AI integration, MCP deep dive, 10+ ready-to-use prompts, CI/CD pipeline setup, and a 30-day implementation roadmap.
By Mitchell Agoma, Senior SDET & AI Testing Specialist with 8+ years of experience