Accessibility Fundamentals

Accessibility is building software that works for everyone. Someone who's blind. Someone who can't use a mouse. Someone with dyslexia. Someone using voice control. Someone on a slow connection. Someone using an old browser. Not as an afterthought. As a first-class concern.

The misconception is that accessibility is a feature. It's not. It's a requirement. Legal requirement (ADA, GDPR), ethical requirement, and business requirement (your audience includes people with disabilities).

The good news: accessible software is usually better for everyone. Clear text helps people with dyslexia and non-native speakers. Keyboard navigation helps people without a mouse and people who prefer keyboards. Good color contrast helps people with low vision and people in bright sunlight.

Why This Matters

Legal compliance is important. In many countries, inaccessible websites and software violate disability rights laws. The ADA (Americans with Disabilities Act) applies to digital products. GDPR has accessibility requirements. Violations mean lawsuits.

Your audience is larger than you think. About 1 in 4 adults in the US have some kind of disability. Some are permanent (blindness, deafness, mobility issues). Some are temporary (broken arm, temporary hearing loss). Some are situational (trying to use your app on a noisy train, in bright sunlight, while holding a baby).

Accessibility is business. People with disabilities have money and preferences. If your software works for them and competitors don't, they choose you.

Accessibility improves overall user experience. Clear labels help everyone. Keyboard navigation helps people who prefer keyboards. Good color contrast helps everyone in varied lighting conditions.

WCAG: The Standard

WCAG (Web Content Accessibility Guidelines) is the standard for accessible web content. It has three levels: A (minimum), AA (good), and AAA (excellent). Most organizations aim for AA.

WCAG is built on four principles: POUR

Perceivable: Users must perceive the content. Text must be readable. Images need descriptions. Videos need captions. Color shouldn't be the only way to convey information.

Operable: Users must be able to operate the interface. Everything accessible via keyboard (not just mouse). Forms clearly labeled. Enough time to complete actions. No seizure-inducing flashing.

Understandable: Content must be clear and understandable. Language is simple. Instructions are clear. Errors have helpful messages.

Robust: Content must work with various technologies. Works with screen readers. Works with voice control. Works with keyboard-only. Works with older browsers.

Practical Implementation

Semantic HTML is the foundation. Use proper HTML elements. A button is <button>, not <div onClick>. A heading is <h1>, not <div style="font-size: 2em">. A list is <ul>, not a series of <div>.

Semantic HTML gives screen readers the information they need:

<!-- Bad -->
<div class="button" onclick="submit()">Submit</div>

<!-- Good -->
<button onclick="submit()">Submit</button>

A screen reader announces the bad version as text. It announces the good version as a button, so users know it's interactive.

ARIA (Accessible Rich Internet Applications) attributes add meaning when semantic HTML isn't enough. Use ARIA when you can't use semantic HTML.

<!-- If you must use a div as a button -->
<div
  role="button"
  tabindex="0"
  aria-label="Submit form"
  onclick="submit()"
  onkeydown="handleKeydown(event)"
>
  Submit
</div>

But prefer semantic HTML when possible. ARIA is a patch. HTML is the solution.

Common ARIA attributes:

• role: what is this element? (button, dialog, navigation)
• aria-label: descriptive label for elements without visible text
• aria-labelledby: connects element to its label
• aria-describedby: connects element to its description
• aria-live: announces dynamic content updates
• aria-hidden: hides elements from screen readers

Keyboard navigation ensures everything works without a mouse. Tab moves to the next interactive element. Shift+Tab moves to the previous. Enter activates buttons. Space checks checkboxes.

Test this: can you navigate your entire site with only Tab, Shift+Tab, Enter, and Space? If not, it's not accessible.

<button>Click me</button>        <!-- Tab order: 1 -->
<input type="text">               <!-- Tab order: 2 -->
<a href="/">Home</a>              <!-- Tab order: 3 -->

For custom interactive elements, set tabindex:

<div role="button" tabindex="0">Custom button</div>

Use tabindex="0" (natural tab order) or remove tabindex entirely if you're using semantic HTML. Never use tabindex greater than 0.

Color contrast ensures text is readable. WCAG AA requires at least 4.5:1 contrast for normal text. Use tools like WebAIM Color Contrast Checker to verify.

/* Good: dark text on light background */
color: #000;
background: #fff;
/* 21:1 contrast ratio */

/* Bad: light gray on white */
color: #ddd;
background: #fff;
/* 1.8:1 contrast ratio, fails WCAG AA */

Images and alt text help people who can't see images. Every image needs alt text. Make it descriptive but concise.

<!-- Bad -->
<img src="chart.png" alt="chart">

<!-- Good -->
<img src="chart.png" alt="Sales by region in Q1 2026. West: 40%, East: 35%, Central: 25%">

If an image is purely decorative, use empty alt:

<img src="decorative-line.png" alt="">

Form labels associate text with form inputs. Use <label> with for attribute:

<label for="email">Email:</label>
<input id="email" type="email">

Or nest the input inside the label:

<label>
  Email:
  <input type="email">
</label>

Screen readers now announce "Email" when the input is focused.

Videos need captions. Not just for deaf users. Captions help everyone in noisy environments, when sound is off, when not speaking the language natively.

Links need descriptive text. Not "click here," but "read our accessibility guide."

<!-- Bad -->
For more info, <a href="/guide">click here</a>

<!-- Good -->
<a href="/guide">Read our accessibility guide</a>

Testing for Accessibility

Automated tools catch obvious issues. Tools like axe, Lighthouse, and WebAIM check color contrast, missing alt text, ARIA errors.

npx axe-core @mysite.com

These catch maybe 30% of issues. They're not enough by themselves.

Keyboard testing is manual and essential. Use only Tab, Shift+Tab, Enter, Space. Can you complete every task?

Screen reader testing requires using an actual screen reader. NVDA is free. JAWS is industry standard. Learn how your site sounds to someone not seeing the visual design.

Testing with real people with disabilities is invaluable. User research sessions with disabled participants reveal issues automated tools miss. Consider hiring accessibility consultants to audit your product.

Common Mistakes

Missing alt text. Every image needs it. "image123.png" is not alt text.

Color-only indicators. Red for error, green for success is not enough. Use text, icons, or color + symbol.

Auto-playing content. Video or audio that starts automatically is jarring and inaccessible. Let users choose.

Time limits. If users have limited time to complete an action, some can't. Remove artificial time limits when possible.

Flashing content. More than 3 flashes per second can cause seizures. Avoid entirely.

Missing form labels. Input fields without labels confuse screen reader users.

Poor heading structure. Headings should go H1 → H2 → H3, not H1 → H3 → H2. Screen reader users navigate by heading.

Integrating Accessibility into Development

Accessibility isn't a separate phase. It's integrated into design and development.

Design for accessibility. Consider keyboard navigation, screen reader experience, color contrast in design phase.

Code accessibly. Use semantic HTML, proper ARIA, semantic heading structure.

Test during development. Use automated tools in CI/CD. Include keyboard testing in code review. Test with screen readers.

Test before release. Run full accessibility audit before shipping.

Maintain accessibility. Monitor for regressions. Automated tools in CI/CD catch many. Include accessibility testing in your test suite.

FAQ

Primary Sources

• W3C's authoritative Web Content Accessibility Guidelines for WCAG 2.0 compliance. WCAG 2.0
• Google's engineering practices documentation covering accessibility and code quality. Google Eng Practices
• The Pragmatic Programmer's practical approach to writing sustainable, maintainable code. The Pragmatic Programmer
• Steve McConnell's comprehensive guide to writing effective and maintainable software. Code Complete
• Robert Martin's handbook on writing clean code and accessibility best practices. Clean Code
• John Ousterhout's philosophy on designing simple, modular, and accessible software. Philosophy of Design