What they're testing
Whether you treat accessibility as part of the job or as somebody else's.
The short answer~30 seconds
Use the right element first: a <button> already has focus, Enter/Space handling and the correct role — a <div onClick> has none of it. If you must build your own, you owe four things: a tabindex to receive focus, the matching key handling, a role plus aria-* to announce state, and a visible focus ring. The fastest check is putting the mouse away and using the page with Tab.
The long answer
The most common mistake isn't missing ARIA but excess and incorrect ARIA. role="button" on a <div> makes a screen reader announce "button", while Space still scrolls the page instead of activating it — so the user hears a button that doesn't work, which is worse than nothing. ARIA describes; it adds no behaviour.
For overlay components — modals, dropdowns — the hard part is focus management: focus must move in when it opens, stay trapped while open, and return to the element that triggered it on close. Missing that last step dumps keyboard users at the top of the page every time a dialog closes, and it's the most-skipped accessibility defect in the projects I've reviewed.
One more worth knowing: display: none and visibility: hidden also hide from screen readers, but opacity: 0 or off-screen positioning does NOT — the content is still announced and still receives Tab. Which is why a menu "closed" with opacity still makes keyboard users tab through ten invisible links.
What they'll ask next
?Which tools do you check with?
axe DevTools or Lighthouse catch roughly a third — mostly contrast and missing attributes. The rest needs manual checks: tab through it, and turn on a built-in screen reader (VoiceOver, NVDA) and listen to one flow.
These lose points
- Removing the focus ring with
outline: noneand replacing it with nothing. One line of CSS that makes a page unusable by keyboard.