Accessibility — table stakes, not nice-to-have

Frontend interviewers increasingly ding candidates who build inaccessible UIs. The bar isn't "be a specialist" — it's "use the right element, give it a name, make it work with a keyboard."

A vocabulary you can rely on

Accessibility has a lot of jargon, but almost all of it boils down to a handful of plain ideas. Here is the whole vocabulary in one place so nothing below is a mystery:

• a11y — shorthand for "accessibility" (a + 11 letters + y). Designing so people with disabilities can use your site.
• Semantic HTML — choosing tags by meaning: <button> for an action, <nav> for navigation, <h1> for the page's main heading. The opposite is wrapping everything in meaningless <div> and <span> boxes.
• Screen reader — software (VoiceOver, NVDA, JAWS) that speaks the page aloud and lets a non-sighted user move through it by keyboard. It builds its narration from your HTML, so good HTML = a usable page.
• ARIA role — an attribute (role="...") that tells assistive tech what a thing is when the tag itself doesn't say it: e.g. role="button" makes a <div> announce as a button. Native elements already carry an implicit role, which is why you rarely need this.
• ARIA label — an attribute (aria-label="Close" or aria-labelledby="id") that supplies the spoken name of a control when there is no visible text — for example an icon-only "X" button.
• Alt text — the alt attribute on an <img>; the text a screen reader reads instead of the picture.
• Keyboard navigation / focus order — using the page with Tab/Shift+Tab/Enter/Space/arrows. "Focus order" is the sequence Tab visits controls in; by default it follows the order of the HTML source.
• Focus — which single element is currently "active" and receiving keystrokes. The visible ring around it is the focus indicator.
• Focus trap — deliberately keeping focus inside a region so Tab can't escape it. Correct and necessary inside an open modal dialog (so you can't tab into the hidden page behind it); a bug everywhere else (if Tab gets stuck in a widget, a keyboard user is locked out).
• Contrast ratio — a 1:1-to-21:1 measure of how distinguishable two colors are. WCAG AA wants 4.5:1 for body text.
• WCAG — Web Content Accessibility Guidelines, the international standard, organized into levels A, AA (the common legal target), and AAA (strictest).
• Landmark — a big structural region a screen reader can jump between: <header>, <nav>, <main>, <aside>, <footer>. They give the page a table-of-contents so users don't have to wade through everything linearly.
• tabindex — attribute that adjusts focusability: tabindex="0" adds an element to the normal Tab order; tabindex="-1" makes it focusable only by script (not by Tab); a positive number jumps it ahead of others (almost always a mistake — avoid).

Before / after: the div-button vs the real button

This is the single most common a11y mistake, so let's see it concretely. A styled <div> can look identical to a button, but to a keyboard or screen-reader user it is invisible and dead — it isn't in the focus order, Enter and Space do nothing, and it announces as nothing:

<!-- BEFORE: looks like a button, isn't one -->
<div class="btn" onclick="save()">Save</div>
<!-- no Tab stop, no Enter/Space, screen reader hears plain "Save" text -->

The fix is not more code — it is less. Use the element built for the job. The browser hands you focusability, Enter/Space activation, and the spoken role "button" for free:

<!-- AFTER: the real element does everything for you -->
<button type="button" onclick="save()">Save</button>
<!-- in Tab order, fires on Enter/Space, announced as "Save, button" -->

If — and only if — you are forced to keep the <div> (say a design system that can't change yet), you must rebuild by hand everything the real button gave you: a role, a Tab stop, and key handlers.

<!-- LAST RESORT: a div pretending to be a button -->
<div class="btn" role="button" tabindex="0"
     onclick="save()" onkeydown="if(event.key==='Enter'||event.key===' ')save()">Save</div>

Three attributes and a handler to reproduce what one tag did. That is why the next rule exists.

The first rule of ARIA

Before / after: an image without alt text

A screen reader cannot see pixels. With no alt, many readers fall back to announcing the file name — useless noise like "chart underscore 4 final dot p-n-g":

<!-- BEFORE: no alt -->
<img src="chart_4_final.png">

<!-- AFTER: alt describes the meaning, not the pixels -->
<img src="chart_4_final.png" alt="Q3 revenue up 12% over Q2">

<!-- DECORATIVE: empty alt tells the reader to skip it entirely -->
<img src="swirl-divider.png" alt="">

Note the difference between missing alt and alt="". Missing means "I forgot" (reader guesses, badly). Empty means "I decided this is decoration" (reader stays silent). Both are valid HTML; only one is intentional.

Common pitfalls

• Removing the focus outline globally (*:focus { outline: none }). Now nobody can tell where the keyboard is. Restyle with :focus-visible instead — never delete.
• Treating placeholder as a label. It disappears the instant the user types and is announced unreliably. Always pair an input with a real <label for="..."> or an aria-label.
• Positive tabindex values (tabindex="3"). They override the natural focus order and quickly become an unmaintainable mess. Stick to 0 and -1 and let the DOM order do the work.
• Icon-only buttons with no name. A bare "🗑" or "✕" button announces as nothing. Add aria-label="Delete" so it has a spoken name.
• An accidental focus trap. A widget that swallows Tab and never lets it out locks keyboard users in. The only place a trap is correct is inside an open modal — and even then you must release it (return focus to the trigger) when the modal closes.
• Heading levels used for size. Don't pick <h3> because it "looks right"; screen-reader users navigate by heading level, so skipping from <h1> to <h4> breaks the outline. Choose the level by structure, style with CSS.
• Color as the only signal. "Required fields are red" excludes color-blind users. Add text or an icon too.