Accessibility basics: keyboard, contrast, announce

The same form can be flawless with a mouse and unusable with a keyboard, a screen reader, or in grayscale — so you check it through those lenses.

The idea

Most accessibility failures aren’t exotic. They’re a field with no label, a focus order that jumps around, an error shown only in red, text too faint to read, and a tap target too small for a thumb. None of these show up when you use the mouse — which is exactly why they ship.

The move interviewers look for is that you check your work through other people’s lenses: can you reach everything with the keyboard, does a screen reader announce something meaningful, and does meaning survive when you strip the color out?

How it works

Each lens answers one question, and each fix closes one gap. Notice how a positive tabindex is the sneaky one: it fixes nothing and quietly breaks the match between reading order and focus order.

Lens         What it checks              A failure looks like
-----------  -------------------------  ----------------------------------
keyboard     can I reach + operate      focus jumps to "Sign up" first
             everything, in order?      (a positive tabindex hoisted it)

screen       is every control           an input announced as
reader       announced with a name?     "edit text, blank" — no label

grayscale    does meaning survive       the only "error" signal was red;
             with no colour?            in grayscale it reads as a hint

The order rule:  a screen reader reads the DOM top-to-bottom, but
keyboard focus follows tabindex. Add tabindex="1" to one button and the
two orders desync — sighted keyboard users tab into chaos while the
screen-reader user hears a sensible sequence. Fix: let DOM order BE the
order (tabindex="0" or none), and reorder in the markup, not with numbers.

When to use it

Run the three-lens check when…	The limit
You built any interactive UI — a form, menu, modal, custom control.	These are the fast, high-value checks, not the whole of WCAG; they catch the common failures, not every one.
An interviewer asks you to critique a design or whiteboard a component.	Manual lenses find obvious breaks; automated tools plus real assistive-tech testing catch the rest.
You’re about to call something “done.”	Tab through it, turn on a screen reader, screenshot it in grayscale — a few minutes that catch most of the embarrassing misses.

Watch out for

• Placeholder as label. Grey text inside the box vanishes the moment someone types, and it isn’t a reliable accessible name. Use a real, associated <label>; keep the placeholder for an example.
• Positive tabindex. tabindex="1" feels like “make this first,” but it hijacks focus order for the whole page and desyncs it from reading order. Use 0 or none and fix order in the markup.
• Colour as the only signal. A red border or red text says “problem” only to people who see the red. Pair it with an icon and words (“Error: …”) so the meaning, not just the mood, comes through.
• Low-contrast “subtle” text. Faint grey help text and placeholders often miss contrast ratios. Aim for the WCAG AA guide of about 4.5:1 for normal text; “looks fine on my screen” isn’t the test.
• Thumb-sized targets. A 24px checkbox is a miss on a phone. Give interactive targets a comfortable hit area (roughly 44px) with enough spacing so a thumb can’t catch the wrong one.

Worked example

In a design-critique round you’re shown a signup form and asked, “What would you fix for accessibility?” Rather than eyeballing it, narrate the lenses. Keyboard: “Let me tab — focus lands on Sign up first, so someone has a positive tabindex on it; I’d remove that and let DOM order lead.” Screen reader: “The email input has only a placeholder, so it announces as an unnamed edit field — add a real label, and wire the error with aria-describedby and role="alert".” Colour: “The error is red-only; in grayscale it reads like a hint, so I’d add an icon and the word ‘Error.’ And the help text looks under-contrast — I’d check it against AA.” Touch: “The checkbox is tiny; I’d grow the target to ~44px.” That answer shows method, not luck.