Question 1

Do you have accessibility testing experience? How do you approach it?

Accepted Answer

I structure the answer in three layers, because a11y's resistance to full automation is the essence of the topic. Layer 1 — what comes free: I already use getByRole/getByLabel locators. That turns every test into an element-level accessibility check: if the locator works, the element has a correct role and accessible name. A button built as

breaks my test immediately — and that is a genuine a11y bug. Layer 2 — automated scanning: WCAG AA scans on critical pages with @axe-core/playwright, in CI under an @a11y tag. Known debt is excluded explicitly (with a ticket number) so the list stays green and any new violation stands out. Layer 3 — the non-automatable part: the keyboard flow (Tab order, focus trap, Esc) — which I do write as a Playwright test; a periodic manual screen-reader pass over a critical flow; judging the meaning of alt texts during review. I always close with the limitation: automated tools catch about one third of the problems, so a green axe scan does not mean "the product is accessible". If your experience is thin, don't hide it — "I don't have deep experience, but I know the principles and tools, and my getByRole approach already covers part of it" is an honest and strong answer.

Question 2

The team doesn't treat a11y as a priority. How do you build the argument?

Accepted Answer

The "it's the right thing to do" argument rarely works alone — so I speak three different languages and pick the one that fits the audience. Legal/risk language (for management): in many jurisdictions, especially government and finance, a11y is a requirement and shows up in tender and audit conditions. The risk must be made concrete — an abstract "it's important" moves nobody. Business language: it's a real share of the user base — customers turned away. Semantic HTML also helps SEO. Engineering language (usually the most effective): most a11y fixes are cheap —

Question 3

The axe scan is green. Can you say the product is accessible?

Accepted Answer

No, and this is the most important nuance in the topic. A green axe scan only means the machine-checkable rules aren't violated — roughly one third of WCAG problems. Real problems that can coexist with a green scan: (1) every image has alt, but it says alt="image" — useless to a screen reader; (2) every button has a name, but it's "Click here" — no context; (3) the tab order technically works but jumps around the page chaotically; (4) the modal opens but focus never moves into it, so a screen-reader user never finds it; (5) a form error is displayed but never announced. So my position: axe is a regression guard — it keeps the current state from getting worse; it is not a certificate of accessibility. The full picture needs a keyboard-flow test, a periodic screen-reader pass and, ideally, testing with a real user. The question itself is a trap: answering "yes" shows you don't understand the tool. Seeing the nuance and offering a concrete counter-example is a senior signal.

Problem	Caught automatically?	How to check
Image missing an alt attribute	Yes	An axe scan
alt exists but is meaningless (alt="img1")	No	Human review — the meaning of the content is judged
Insufficient colour contrast	Yes	An axe scan (WCAG AA ratios)
A button built as a `<div onclick>`	Yes	axe — and the `getByRole` locator failing
Tab order doesn't match visual order	No	Manual keyboard pass / a targeted test
Focus not trapped in a modal (escapes behind it)	Partially	A Playwright test: verifying the Tab cycle
Error message not announced to screen readers	Partially	Checking role="alert"/aria-live + a screen reader

Accessibility (a11y) testing basics

📚 Sources and documentation