Stop 23 · Interview PreparationTechnical · 5/8

Accessibility

Part of the Frontend Developer Roadmap

In short

'Add alt text' is where most candidates stop. Talk about keyboard use, focus and real semantic HTML, and you sound like someone who has actually shipped to real users.

Being able to discuss accessibility beyond 'add alt text' — keyboard navigation, ARIA, screen reader behavior, and how you'd audit a page.

The jaadu pushes a friend in a wheelchair up a station ramp as a traveller wheels a suitcase.

Think of it like this

Ramps at the railway station

A ramp helps wheelchair users, but also people with suitcases, prams and bad knees. Accessible websites work the same way: semantic HTML and keyboard support help screen reader users, power users and everyone on a flaky trackpad.

Watch it happen

Auditing a sign-up form

Auto check
Keyboard
Reader
Fix

1/4Lighthouse flags an input with no label and some low-contrast grey text.

The big ideas

What you need to know

Semantic HTML first

button, a, label, nav, main and headings in order. They come with keyboard and screen reader support for free.

Everything works with a keyboard

Tab to reach it, Enter or Space to use it, Escape to close it, and a visible focus ring.

ARIA is a last resort

Use ARIA only when no native element fits. Wrong ARIA is worse than none.

Know how to audit

Lighthouse or axe for quick checks, then try the page with only a keyboard and a screen reader.

See it in code

Walk through the code

jsx
1// Bad: looks like a button, but keyboards and screen readers can't tell2<div className="btn" onClick={save}>Save</div>3 4// Good: focusable, works with Enter and Space, announced as a button5<button type="button" onClick={save}>Save</button>6 7// Bad: placeholder is not a label8<input placeholder="Email" />9 10// Good: label linked to the input11<label htmlFor="email">Email</label>12<input id="email" type="email" />

1/4A div with onClick can't get keyboard focus and has no button role.

Native elements give you focus, keyboard handling and the right role for free. Rebuilding that on a div needs tabIndex, key handlers and a role, and is easy to get wrong.

Save yourself the pain

Common mistakes

Oops

Adding outline: none to remove the 'ugly' focus ring.

Do this instead

Restyle it with :focus-visible instead. Keyboard users need to see where they are.

Oops

Using alt="image" or the file name for every image.

Do this instead

Describe what the image tells the user. Use alt="" for purely decorative images.

Your mission

Keyboard-only challenge

~25 min

Quick check

You need a clickable 'Save' control. What's the best choice?

Go deeper

  1. 1Prepare to explain how you'd test a page for accessibility (keyboard-only, screen reader).
  2. 2Have an example ready where you fixed or considered an accessibility issue.
  3. 3Know the acronym WCAG and roughly what it covers.

More technical at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge