Web Accessibility (A11y) for Juniors: What It Is and Why It Matters

#webdev #frontend #a11y #beginners

You probably saw the word a11y on Twitter, in a job post, or in a code review comment, and wondered what it actually means. So let me explain it the way I wish someone explained it to me when I started.

What is A11y?

A11y is a short way of writing accessibility. The number 11 is just the count of letters between the a and the y in the word accessibility. That is it. No hidden meaning.

Accessibility means building websites and apps that everyone can actually use, including people who:

can't see well or can't see at all and use a screen reader
can't use a mouse and only navigate with the keyboard
have low color vision and can't tell red from green
have motor issues and can't click tiny buttons
are on a slow phone, in bright sunlight, or in a noisy room

So a11y is not a "feature for blind users". It is just good engineering that respects how different humans interact with your UI.

Why should you care as a junior?

Three honest reasons:

1. It is the law in many places. In the EU, the European Accessibility Act started applying in 2025. In the US, the ADA Title II deadline hits in April 2026 for public sector sites. Big clients will not hire teams that ship inaccessible products.

2. Better a11y means better UX for everyone. Captions help deaf users, but they also help anyone watching a video on the bus without headphones. Keyboard support helps blind users, but it also helps power users who hate touching the mouse.

3. It makes you stand out. Most juniors do not know a11y. If you do, you are already different from 80% of the candidates applying to the same job.

The 4 principles (POUR)

WCAG (the official accessibility guidelines, currently version 2.2) groups everything under 4 ideas. The acronym is POUR:

Perceivable: users can sense the content (with eyes, ears, or fingers)
Operable: users can interact with it (mouse, keyboard, touch, voice)
Understandable: users can read it and predict what happens next
Robust: it keeps working in different browsers and assistive tech

Don't memorize this. Just remember: if a real human can't perceive, operate, understand, or rely on your UI, you have an a11y problem.

Real examples you can fix today

Let me show you the most common mistakes I see in junior code, and the fix.

1. Using `div` for buttons

This looks fine in the browser, but a screen reader will not announce it as a button, and you can't reach it with the Tab key.

<!-- bad -->
<div class="btn" onclick="submit()">Save</div>

<!-- good -->
<button type="button" onclick="submit()">Save</button>

The native <button> gives you keyboard focus, Enter and Space activation, and the right ARIA role for free. You get all that by typing 4 letters less. Use it.

2. Images with no alt text

<!-- bad -->
<img src="profile.jpg" />

<!-- good -->
<img src="profile.jpg" alt="Mohamed smiling at his graduation" />

<!-- also good if the image is just decoration -->
<img src="sparkle.svg" alt="" />

Empty alt="" is not lazy, it is correct for decorative images. It tells screen readers to skip them. Missing alt completely is the bug.

3. Form inputs with no label

<!-- bad -->
<input type="email" placeholder="Email" />

<!-- good -->
<label for="email">Email</label>
<input id="email" type="email" />

Placeholders disappear when the user types and they are usually low contrast. A real <label> stays, gets read by screen readers, and lets the user click the label to focus the input.

4. Color as the only signal

Look at this error message:

<p style="color: red">Email is invalid</p>

A user with color blindness might not see the red at all. Add an icon or text:

<p style="color: red">
  <span aria-hidden="true">✗</span> Email is invalid
</p>

5. Low contrast text

Light grey text on white looks "clean and minimal" but it is unreadable for many users. WCAG asks for a contrast ratio of at least 4.5:1 for normal text. Use a tool like WebAIM Contrast Checker or your browser DevTools to check.

6. Custom components without keyboard support

If you build a custom dropdown, modal, or tabs component, ask yourself:

Can I open and close it with only the keyboard?
Does Tab move focus in a logical order?
Does Esc close the modal?
Does focus return to the trigger button when the modal closes?

If the answer to any of these is no, your component has a bug. This is exactly why headless libraries like Radix and Base UI exist. They handle this for you (more on that in another post).

Tools that will save you

You don't have to memorize WCAG. Use tools.

axe DevTools browser extension: scans your page and lists violations with fixes
Lighthouse (built into Chrome): gives you an a11y score
VoiceOver (Mac, Cmd+F5) or NVDA (Windows, free): try using your own site with eyes closed for 60 seconds. Trust me, you will feel every bug
Tab key: just press Tab through your page. If focus disappears or jumps around weirdly, you have an issue

A simple checklist before you ship

[ ] Every image has alt (or alt="" if decorative)
[ ] Every form input has a real <label>
[ ] You can use the whole page with only the keyboard
[ ] Focus is always visible (don't kill the focus ring with outline: none and nothing else)
[ ] Color contrast is 4.5:1 or higher for text
[ ] Headings go in order (h1, then h2, then h3, no skipping)
[ ] Buttons are <button>, links are <a>. Don't mix them up

Final thought

A11y is not a separate phase you do at the end. It is part of writing good HTML. Most of the fixes above cost you nothing extra and take 10 seconds. Start with semantic HTML, test with your keyboard, and you are already ahead of most devs.

In the next post I will show how libraries like Radix, Base UI, and shadcn handle the harder a11y patterns for you, so you don't have to reinvent a focus trap every time you build a modal.