Web Accessibility: A Developer's Starting Guide

What Is Web Accessibility, Really?

Web accessibility means that every person can use your website, regardless of ability, disability, device, or situation. That includes someone using a screen reader, someone navigating with only a keyboard, someone with low vision, or someone in bright sunlight trying to read their phone.

It's not an extra feature you bolt on at the end. It's a fundamental part of how the web was designed to work in the first place. The inventor of the World Wide Web, Tim Berners-Lee, said it best:

The power of the Web is in its universality. Access by everyone, regardless of disability, is an essential aspect.

Who Needs Accessible Websites?

Most developers think of accessibility as helping "people with disabilities." But it's far broader than that.

• A person who is blind and uses a screen reader to navigate the web.
• A person with a motor impairment who cannot use a mouse and relies entirely on a keyboard.
• A person with low vision who needs to zoom in to 400% to read content.
• A person with a cognitive disability who needs clear, simple language and structure.
• An elderly person whose vision or motor control has declined with age.
• A person in a bright environment where low-contrast text becomes unreadable.
• A person on a slow mobile connection where heavy pages take forever to load.
• A person temporarily injured — a broken arm means no mouse for weeks.

Understanding WCAG

WCAG stands for Web Content Accessibility Guidelines. It's the international standard for web accessibility, maintained by the World Wide Web Consortium (W3C). When someone says "accessible website," they almost always mean WCAG compliant.

WCAG is organized into three levels of conformance:

• Level A: The minimum. Covers the most critical barriers that completely block access for some users.
• Level AA: The recommended standard. Most legal requirements around the world require at least AA compliance. This is your target.
• Level AAA: The gold standard. Nice to achieve where possible, but not required for most websites.

The Four Pillars of Accessibility

WCAG organizes all its guidelines around four core principles. Everything you'll ever do for accessibility traces back to one of these:

1. Perceivable: Users must be able to perceive all information. If something is only communicated through color, or only through sound, some users will miss it entirely.
2. Operable: Users must be able to operate the interface. If something can only be activated with a mouse click, keyboard users are locked out.
3. Understandable: The content and interface must be understandable. Confusing navigation, inconsistent behavior, or unclear language creates barriers.
4. Robust: The content must be robust enough to be reliably interpreted by a wide variety of assistive technologies, both current and future.

Semantic HTML: Your Foundation

This is the single most important thing you can do for accessibility. Semantic HTML means using the right HTML elements for their intended purpose, instead of using generic elements like divs for everything.

1<!-- Bad: No meaning, screen readers see nothing useful -->
2<div class="header">
3  <div class="nav">
4    <div class="nav-link">Home</div>
5    <div class="nav-link">About</div>
6  </div>
7</div>
8<div class="main">
9  <div class="title">Welcome</div>
10  <div class="content">This is my website.</div>
11</div>
12
13<!-- Good: Every element tells assistive tech what it is -->
14<header>
15  <nav>
16    <a href="/">Home</a>
17    <a href="/about">About</a>
18  </nav>
19</header>
20<main>
21  <h1>Welcome</h1>
22  <p>This is my website.</p>
23</main>

Here are the key semantic elements you should know:

• <header> The top section of a page or article, usually containing branding and navigation.
• <nav> A block of navigation links.
• <main> The main content of the page. Only one per page.
• <article> A self-contained piece of content, like a blog post.
• <section> A thematic grouping of content
• <aside> Content that is tangentially related to the main content, like a sidebar.
• <footer> The bottom section of a page or article.
• <h1> through <h6> Headings that create a hierarchy. Never skip levels.
• <button> For actions. Never use a div or span for a clickable action.
• <a> For navigation. Never use a button for navigating to a URL.

Keyboard Navigation

Every single interactive element on your website must be reachable and usable with only a keyboard. Many users; whether due to motor disabilities, power users, or assistive technology; rely entirely on the keyboard.

1<!-- Bad: Only works with a mouse click -->
2<div class="btn" onclick="submitForm()">Submit</div>
3
4<!-- Good: Keyboard accessible, correct semantics -->
5<button type="submit">Submit</button>

The key rules:

• All interactive elements must be focusable: buttons, links, inputs, and custom components.
• Focus must follow a logical order: top to bottom, left to right.
• Focus must always be visible: the user must see which element is currently focused.
• No keyboard traps: the user must never get stuck somewhere they can't escape with the keyboard.

1/* Bad: Removing focus styles entirely */
2button:focus {
3  outline: none;
4}
5
6/* Good: Custom but visible focus indicator */
7button:focus-visible {
8  outline: 2px solid #5de8e2;
9  outline-offset: 2px;
10}

Images and Alt Text

Every image on your website needs an alt attribute. This is one of the most basic and most commonly violated accessibility rules.

Alt text serves two purposes: it describes the image to screen readers, and it displays as fallback text if the image fails to load.

1<!-- Bad: No alt text at all -->
2<img src="chart.png">
3
4<!-- Bad: Meaningless alt text -->
5<img src="chart.png" alt="image">
6<img src="chart.png" alt="IMG_4732.png">
7
8<!-- Good: Descriptive alt text -->
9<img src="chart.png" alt="Bar chart showing website carbon emissions dropping 60% after optimization">
10
11<!-- Good: Decorative images use empty alt -->
12<img src="decorative-divider.png" alt="">

Color Contrast

Color contrast is the difference in brightness between text and its background. If the contrast is too low, text becomes hard or impossible to read, especially for people with low vision, color blindness, or anyone in a bright environment.

WCAG AA requires:

• Normal text (under 18px or 14px bold): A contrast ratio of at least 4.5:1.
• Large text (18px+ or 14px+ bold): A contrast ratio of at least 3:1.
• UI components and icons: A contrast ratio of at least 3:1 against adjacent colors

1/* Bad: Low contrast — fails WCAG AA */
2.text {
3  color: #777777; /* gray text */
4  background-color: #ffffff; /* white background */
5}
6/* Contrast ratio: 4.48:1 — just below the 4.5:1 requirement */
7
8/* Good: Sufficient contrast — passes WCAG AA */
9.text {
10  color: #595959;
11  background-color: #ffffff;
12}
13/* Contrast ratio: 7.0:1 — well above the requirement */

Forms and Inputs

Forms are one of the most common accessibility failure points on the web. A form that looks fine visually can be completely broken for assistive technology users.

Every input needs a proper label. Every error needs to be clearly communicated. Every required field needs to be marked.

1<!-- Bad: No label, no error handling -->
2<input type="email" placeholder="Enter your email">
3
4<!-- Good: Proper label, error handling, required marking -->
5<div>
6  <label for="email">
7    Email address
8    <span aria-label="required">*</span>
9  </label>
10  <input
11    type="email"
12    id="email"
13    name="email"
14    required
15    aria-required="true"
16    aria-describedby="email-error"
17  >
18  <p id="email-error" role="alert" aria-live="polite">
19    Please enter a valid email address.
20  </p>
21</div>

ARIA: When and Why

ARIA stands for Accessible Rich Internet Applications. It's a set of attributes you can add to HTML to give assistive technologies extra information about your content.

But here's the critical rule: use native HTML first. ARIA is a last resort.

1<!-- Bad: Using ARIA when native HTML already works -->
2<div role="button" tabindex="0" aria-pressed="false">
3  Submit
4</div>
5
6<!-- Good: Native HTML does this automatically -->
7<button type="submit">Submit</button>
8
9<!-- Good: ARIA used correctly — native HTML can't do this -->
10<div
11  role="dialog"
12  aria-modal="true"
13  aria-label="Confirm deletion"
14>
15  <p>Are you sure you want to delete this item?</p>
16  <button>Cancel</button>
17  <button>Delete</button>
18</div>

Testing Your Work

You cannot rely on visual inspection alone to find accessibility issues. You need a combination of automated tools and manual testing.

• Automated tools: They catch roughly 30-40% of issues. Use them as a starting point, not a guarantee.
• Keyboard testing: Unplug your mouse. Navigate your entire site using only Tab, Enter, Space, and arrow keys. Can you reach everything? Can you use everything?
• Screen reader testing: Install a free screen reader and try using your site. NVDA (Windows) and VoiceOver (Mac/iOS) are both free and widely used.
• Color contrast checkers: Tools like the WebAIM Contrast Checker let you input two colors and see if they meet WCAG ratios.
• Real user feedback: If possible, ask people who use assistive technologies to test your site. Their feedback is irreplaceable.

Resources to Keep Learning

• W3C WCAG 2.1 Guidelines: w3.org/WAI/WCAG21/Understanding The official standard. Read the "Understanding" version, it's much more approachable than the raw spec.
• WebAIM: webaim.org One of the best free resources. Guides, tools, and checklists all in one place.
• MDN Web Docs (Accessibility): developer.mozilla.org/en-US/docs/Web/Accessibility Solid technical reference for HTML, ARIA, and accessibility best practices.
• axe DevTools: axe devtools The most popular browser extension for automated accessibility testing.
• Google Lighthouse: developers.google.com/web/tools/lighthouse Built into Chrome DevTools. Gives you an accessibility score and actionable recommendations.
• WebAIM Contrast Checker: webaim.org/resources/contrastchecker Instantly check if two colors meet WCAG contrast requirements.