The accessibility questions I ask in a frontend interview

I ask accessibility questions in almost every frontend interview I run. Not as a trivia round, and not to catch you out on a WCAG clause number. I ask because the answers tell me quickly whether you have shipped UI that real people use with a keyboard, a screen reader, or a zoomed-in browser.

I am Harry Ashton. I built CodePrepped so engineers stop guessing what hiring managers look for, and I care enough about this topic that I built Lucid, a small accessibility checker, on the side. This post sits next to what I mark in a 45-minute screen and the trade-offs I want you to say out loud. Accessibility is one of the places where those trade-offs show up fastest.

Photo: cottonbro studio / Pexels.

Why I ask at all

Most frontend roles I hire for build forms, menus, dialogs, tables and checkout flows. Every one of those can lock someone out if it is built carelessly. When a candidate talks about accessibility as part of building the component, not as a pass at the end, I learn that they think about who is on the other side of the screen.

I am not looking for a specialist. I am looking for someone who reaches for the right element first, knows how to check their own work, and is honest about what they have not done yet.

"How would you build this button?"

This sounds too easy, which is why it works. I describe a clickable card or an icon that opens a menu and ask how you would build it.

The answer I hope for starts with a real <button>. It gets focus, Enter and Space for free, and it announces itself as a button. If you reach for a div with an onClick, I will ask what a keyboard user does with it. Candidates who have been bitten by this before usually laugh and say "I would not do that any more", and that is a good answer too.

For an icon-only button I want to hear about an accessible name: visible text if the design allows it, otherwise an aria-label that says what the button does, not what the icon looks like.

"Walk me through the keyboard path"

I give you a small flow, like a search box with suggestions or a settings page with a modal, and ask you to tab through it out loud. I am listening for three things:

• a sensible focus order that follows the visual order,
• a visible focus style, and what you would say if a designer asked to remove the outline,
• where focus goes when something opens or closes.

The modal is the classic. Focus should move into it when it opens, stay inside it while it is open, close on Escape, and return to the thing that opened it. If you mention the native <dialog> element and what it now handles for you, and where you would still test by hand, I know you have kept up.

"When would you reach for ARIA?"

The best answers start with "as late as I can". Native HTML gives you roles, states and keyboard behaviour that ARIA only describes. ARIA does not add behaviour; it changes what assistive tech is told. Telling a screen reader something is a tab while it behaves like a link is worse than no ARIA at all.

I do want you to know a few attributes well enough to use them correctly: aria-expanded on a disclosure toggle, aria-describedby to tie an error to its field, aria-live for a status message that appears without a page load. If you can explain one of those from something you shipped, that beats reciting a list.

"How do you know it works?"

This is the question that separates people who have done the work from people who have read about it. I want to hear about a mix of checks:

• putting the mouse away and using the page with a keyboard only,
• an automated scan in the browser or in CI to catch the easy misses like missing labels and low contrast,
• a quick pass with a screen reader on the one or two flows that matter most,
• zooming the page to 200 percent and checking nothing overlaps or disappears,
• queries in component tests that find elements by role and name, which fail when the accessible name breaks.

I will usually follow up with "what does the automated scan miss?" The honest answer is a lot: focus order, whether the label actually makes sense, whether the flow is usable at all. Saying that out loud tells me you do not treat a green report as the finish line.

"Here is a form. What would you fix?"

Sometimes I show a short form with a few deliberate problems. Placeholder text used instead of a label. Errors shown only in red. A submit button that does nothing visible when validation fails. A required field marked with an asterisk and no explanation.

I am not counting how many you spot. I am watching how you prioritise. "The missing labels first, because nobody using a screen reader can fill this in" is the kind of reasoning I want. Then error messages tied to their fields, focus moved to the first error or a summary at the top, and colour backed up by text.

Answers that worry me

A few patterns make me write a careful note:

• "We had a ticket for accessibility at the end of the project." It usually means it never happened.
• "We added an overlay widget." I will ask what it fixed, and it rarely fixed the underlying markup.
• "ARIA on everything." More attributes is not more accessible.
• Confident claims about compliance levels with no story about how anyone checked.

None of these are automatic fails. They are prompts for a follow-up, and a candidate who says "I see why that was a problem now" can still have a strong interview.

How to prepare without memorising the spec

Pick one component you have built and rebuild it with accessibility in mind. A disclosure, a modal or a combobox is ideal. Use it with a keyboard. Run a scan. Turn on the screen reader your operating system ships with and listen to it for five minutes. You will have more to say in the interview than someone who read a checklist the night before.

Then practise saying it out loud. CodePrepped's mock interviews and AI Trainer give you somewhere to rehearse answers to follow-ups like "what if the designer wants to remove the focus ring?" so the first time you answer that is not in front of me. If you are applying now, the shortlist scorecard is a quick way to see what to work on before your next screen.

Do I need to know WCAG by heart?

No. Knowing that WCAG exists, roughly what the AA level covers, and where to look things up is enough for most frontend roles. I care more that you can make a form usable with a keyboard than that you can quote a success criterion number.

What if my last job never prioritised accessibility?

Say so, then tell me what you would do differently and show me something you built on your own time. Honesty about the gap plus evidence you have started closing it reads far better than pretending.

Which screen reader should I practise with?

Whichever one your machine already has. VoiceOver on a Mac or NVDA on Windows is fine. The point is to hear your own UI once, not to become an expert user.

Will I be asked to fix code live?

Sometimes. If I do, I care about you talking through what you would change and why, more than typing every fix perfectly in the time we have.