Fundamentals of Accessibility

Introduction

Why do some websites work for everyone while others exclude users with disabilities? The difference is understanding accessibility fundamentals.

Accessibility means building interfaces that everyone can use, regardless of ability. Sound accessibility practices create inclusive experiences. Poor accessibility creates barriers that exclude users and can lead to legal issues.

Most developers know accessibility matters, but many lack fundamentals. Building without this creates interfaces that work for some users but not all. Understanding accessibility ensures interfaces work for everyone.

What this is (and isn’t): This article explains accessibility principles and trade-offs, focusing on why accessibility works and how core pieces fit together. It doesn’t cover every legal requirement or provide a compliance checklist.

Why accessibility fundamentals matter:

• Inclusive experiences - Understanding accessibility helps you build interfaces that work for all users.
• Better code - Accessible code, like semantic HTML and proper form labels, enhances quality and maintainability.
• Broader user base - Millions of users have disabilities affecting how they use interfaces.
• Business value - Accessible interfaces serve more users and improve business outcomes.

Mastering accessibility fundamentals moves you from building for some users to building for everyone.

This article outlines a basic workflow for every project:

1. Semantic HTML – give the page a meaningful structure.
2. Keyboard navigation – make that structure operable without a mouse.
3. ARIA – fill in the gaps when HTML alone isn’t enough.
4. Testing – verify that real users and assistive tech can actually use what you built.

Prerequisites & Audience

Prerequisites: You should be familiar with basic HTML, CSS, and JavaScript. No prior accessibility experience is needed.

Primary audience: Beginner to intermediate developers, including full-stack engineers, seeking a stronger foundation in accessibility.

Jump to:

• What is Accessibility?
• Semantic HTML
• Keyboard Navigation
• ARIA and Assistive Technologies
• Testing and Validation
• Common Mistakes
• Misconceptions
• Future Trends
• Limitations & Specialists
• Glossary

If you’re new to accessibility, start with semantic HTML and keyboard navigation. Experienced developers can focus on ARIA and advanced testing techniques.

Escape routes: If you need a refresher on semantic HTML and keyboard navigation, read Sections 2 and 3, then skip to “Common Accessibility Mistakes”.

TL;DR – Accessibility Fundamentals in One Pass

If you only remember one workflow, make it this:

• Use semantic HTML so assistive technologies can understand your page.
• Guarantee keyboard navigation so nobody is blocked by mouse-only interactions.
• Add ARIA only when HTML can’t express your intent.
• Test with tools and humans (keyboard + screen reader) so you know it actually works.

The Accessibility Workflow:

The following diagram shows the four-step accessibility workflow: Semantic HTML provides the foundation, Keyboard Navigation ensures operability, ARIA Enhancements fill gaps when needed, and Testing validates with both automated tools and manual testing.

┌────────────────────────────┐
│ Semantic HTML (meaning)    │
└─────────────┬──────────────┘
              ↓
┌────────────────────────────┐
│ Keyboard Navigation         │
│ (operability for everyone)  │
└─────────────┬──────────────┘
              ↓
┌────────────────────────────┐
│ ARIA Enhancements           │
│ (only when needed)          │
└─────────────┬──────────────┘
              ↓
┌────────────────────────────┐
│ Testing (automated + manual)│
└────────────────────────────┘

Learning Outcomes

By the end of this article, you will be able to:

• Explain why semantic HTML enhances accessibility and when to use various HTML elements.
• Describe why keyboard navigation is critical (beyond screen readers) and how it shapes interface design.
• Explain why ARIA attributes enhance HTML and when to use them versus semantic HTML.
• Learn how screen readers work and how to structure content for assistive technology.
• Describe how color contrast affects readability and when contrast ratios meet Web Content Accessibility Guidelines (WCAG) standards.
• Explain how accessibility testing tools work and when to use automated versus manual testing.

Section 1: What is Accessibility? – Building for Everyone

Accessibility means building interfaces that everyone can use, regardless of ability. This includes users with visual, auditory, motor, and cognitive disabilities.

Understanding Disability Types

Different disabilities affect how users interact with interfaces:

Visual disabilities: Users who are blind, have low vision, or are color blind need interfaces that work without visual cues. Screen readers, high contrast modes, and keyboard navigation help these users.

Auditory disabilities: Users who are deaf or hard of hearing need captions, transcripts, and visual indicators for audio content.

Motor disabilities: Users with limited dexterity or mobility need keyboard navigation, voice control, and interfaces that don’t require precise mouse movements.

Cognitive disabilities: Users with attention, memory, or processing differences need clear navigation, consistent patterns, and simplified interfaces.

Why Accessibility Matters

Accessibility is ethical, inclusive, and legally mandated by laws such as the ADA (US), AODA (Canada), Section 508 (US Federal), and EAA (EU). Following WCAG AA reduces risk and broadens access.

Ethical responsibility: Building inaccessible interfaces excludes users. Everyone deserves access to online information and services.

Business value: Accessible interfaces serve more users, boost Search Engine Optimization (SEO), and enhance user experiences.

Better code: Accessible coding practices, such as semantic HTML and proper form labels, enhance maintainability and robustness.

The Web Content Accessibility Guidelines (WCAG)

The Web Content Accessibility Guidelines (WCAG) are international standards for web accessibility, organized by four principles:

Perceivable: Information should be perceptible through text alternatives for images, video captions, and adequate color contrast.

Operable: Interface components must be accessible to all users, including keyboard access, seizure-safe content, and sufficient time for tasks.

Understandable: Information and interface operation must be understandable, including readable text, predictable functionality, and input assistance.

Robust: Content must be robust for current and future assistive technologies, using valid HTML and proper ARIA attributes.

WCAG has three conformance levels: A (minimum), AA (standard), and AAA (enhanced). Most organizations aim for AA compliance.

The Accessibility Workflow

Building accessible interfaces is a logical process, like building a house: start with a solid foundation, add structural elements, then enhance with details.

Foundation: Semantic HTML - Start with semantic HTML that conveys meaning, like using proper building materials instead of cardboard. A house needs a solid foundation, and your interface needs semantic HTML as its base.

Structure: Keyboard Navigation - Ensure all interactive elements work with keyboards. Keyboard navigation is like installing doors and hallways accessible for everyone, not just those who can climb walls. It creates pathways through your interface.

Enhancement: ARIA Attributes - Add ARIA when semantic HTML isn’t enough, like signage for unclear layouts. ARIA offers extra cues when structure needs clarification.

Validation: Testing - Test with automated tools and assistive technologies. Automated tools verify code compliance, while manual testing with assistive technologies confirms usability.

This workflow integrates accessibility from the start, not retroactively. Each step builds on the last: semantic HTML ensures understandability, keyboard navigation ensures operability, ARIA addresses gaps, and testing confirms usability.

Section 2: Semantic HTML – The Foundation of Accessibility

Semantic HTML employs elements that convey meaning, aiding screen readers and assistive tech in understanding and navigating content.

Think of semantic HTML like a book’s table of contents. Just as chapter titles help readers understand a book’s structure, semantic HTML elements help assistive technologies understand a webpage’s structure. A <button> element tells screen readers “this is a button”, the same way a chapter title tells readers “this is a new section.”

What Makes HTML Semantic

Semantic HTML uses descriptive elements; a <button> indicates a button to assistive tech, unlike a <div> with a click handler.

Semantic elements: HTML5 introduced semantic elements like <header>, <nav>, <main>, <article>, <section>, <aside>, and <footer>, aiding screen readers and search engines in understanding content structure.

Form elements: Use proper form elements like <label>, <input>, <select>, and <textarea>. Connect labels to inputs using the for attribute, or wrap inputs in labels.

Heading hierarchy: Use heading elements (<h1> through <h6>) to create a logical document outline. Don’t skip heading levels, and use headings to organize content, not for styling.

Semantic HTML Examples

Here’s an example of semantic HTML structure:

<header>
  <nav aria-label="Main navigation">
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
      <li><a href="/contact">Contact</a></li>
    </ul>
  </nav>
</header>

<main>
  <article>
    <h1>Article Title</h1>
    <p>Article content goes here.</p>
  </article>
</main>

<footer>
  <p>&copy; 2025 Company Name</p>
</footer>

This structure helps screen readers understand the page layout and navigate efficiently.

Why Semantic HTML Works

Semantic HTML helps browsers and assistive tech create an accessibility tree that shows your content’s structure and meaning. Using semantic elements clarifies each part’s function.

Browsers add default behaviors to semantic elements. For example, a <button> gets keyboard focus, responds to Enter and Space, and announces itself as a button for screen readers. In contrast, a <div> with a click handler lacks these behaviors, making semantic HTML more accessible.

Semantic HTML enhances SEO by using semantic structure, helping search engines better understand and index content, just as it improves screen reader accessibility.

Trade-offs and Limitations of Semantic HTML

Semantic HTML has limitations, and sometimes you need custom components without semantic equivalents. For example, complex date pickers or custom dropdowns require ARIA attributes to convey their purpose.

Semantic HTML is a foundation, but it’s not a complete fix for accessibility; it also requires proper contrast, keyboard navigation, and testing. It’s like a house that needs doors, windows, and an inspection to be livable.

When Semantic HTML Isn’t Enough

Sometimes, semantic HTML lacks enough info for assistive tech. Use semantic HTML first, then add ARIA only if needed.

Quick Check: Semantic HTML

Before moving on, test your understanding:

• Can you identify which HTML elements in your project are semantic versus presentational?
• Do your forms use proper <label> elements connected to inputs?
• Is your heading hierarchy logical without skipping levels?

If unsure, audit one page of your project to identify where semantic HTML could replace <div> or <span> elements.

Answer guidance: Ideal result: You can identify semantic elements (like <button>, <nav>, <article>) and distinguish them from presentational elements (like <div> or <span>). Your forms use proper <label> elements, each connected to an input via the for attribute. Your heading hierarchy follows a logical order (h1 → h2 → h3) without skipping levels.

If you found mostly presentational elements, review Section 2’s semantic HTML examples. Replace <div> elements used for buttons with <button>, navigation containers with <nav>, and content sections with semantic elements like <article> or <section>. Use the W3C HTML Validator to check your HTML structure.

Section 3: Keyboard Navigation – Ensuring Keyboard Accessibility

Keyboard navigation ensures that all interactive elements work without a mouse, supporting users with motor disabilities, keyboard users, and screen reader users.

Think of keyboard navigation as a guided tour. The Tab key advances through interactive elements, focus indicators show your location, and skip links let you jump to specific sections.

How Keyboard Navigation Works

Keyboard users navigate using the Tab key to move forward, Shift+Tab to move backward, Enter or Space to activate buttons, and arrow keys to navigate within components.

Tab order: Elements receive focus in the order they appear in the HTML. The browser follows the document order, creating a predictable navigation path. Use tabindex to control focus order, but avoid tabindex values greater than 0 unless necessary.

Why this matters: When you use tabindex="0", you add an element to the natural tab order. When you use tabindex="1" or higher, you create a custom order that can confuse users. Screen reader users expect focus to follow document order, and breaking that expectation creates navigation problems.

Focus indicators: Visible focus indicators show users where they are. Browsers provide default focus styles, but you can customize them. Never remove focus indicators.

Why this matters: Without focus indicators, keyboard users can’t tell what has focus, like being in a dark room without a flashlight.

Focus indicators are essential for keyboard navigation and should never be removed.

Skip links: Skip links let keyboard users skip navigation to the main content, saving time and improving the experience.

Why this matters: Keyboard users shouldn’t tab through many links to reach content. Skip links offer direct access to the main content, enhancing efficiency.

Keyboard Navigation Examples

Here’s an example of a keyboard-accessible navigation menu:

<nav aria-label="Main navigation">
  <a href="#main-content" class="skip-link">Skip to main content</a>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

<main id="main-content">
  <!-- Main content here -->
</main>

The skip link lets keyboard users jump to the main content, and all navigation links are accessible via keyboard.

Focus Management

Focus management guides the logical focus flow in interfaces, including dynamic content such as modals and dropdowns.

Trapping focus: In modals, trap focus within the modal so users can’t tab to content behind it. Return focus to the triggering element when the modal closes.

Why this matters: Without focus trapping, keyboard users can tab into content behind a modal, which is confusing and breaks the modal’s purpose. Focus trapping keeps users within the modal until they close it.

Moving focus: When content changes, move focus appropriately. For example, when opening a modal, move focus to the modal’s first focusable element.

Why this matters: When you open a modal, keyboard focus should move to the modal so users can interact with it immediately. If focus stays on the button that opened the modal, users might not realize the modal opened.

Announcing changes: Use ARIA live regions to announce dynamic content changes to screen reader users.

Why this matters: Screen reader users must be notified of content changes; without announcements, they might miss vital updates, such as errors and success messages.

Trade-offs and Limitations of Keyboard Navigation

Keyboard navigation has limitations, especially for drag-and-drop or complex gestures. Provide alternative keyboard-accessible methods.

Keyboard navigation needs careful planning because dynamic content can confuse users by changing focus order. Test thoroughly, especially in single-page apps that update content without reloading.

Quick Check: Keyboard Navigation

Test your understanding:

• Can you navigate your interface using only the keyboard?
• Do all interactive elements receive focus in a logical order?
• Are focus indicators visible on all focusable elements?
• Do modals trap focus and return it when closed?

Try navigating your latest project with only the keyboard. Note where you get stuck or confused, then fix those issues.

Answer guidance: Ideal result: You can navigate your interface seamlessly, with focus moving logically through all elements and clearly visible indicators. Modals trap focus and return it to the trigger when closed.

If you couldn’t navigate your entire interface, review Section 3’s focus management and keyboard navigation patterns. Check that all interactive elements are focusable and that focus order follows document order. If modals don’t trap focus, implement focus trapping as described in Section 3.

Review Section 3’s focus management and keyboard navigation if you can’t navigate your interface. Ensure all interactive elements are focusable, with focus order in document order. If modals don’t trap focus, implement focus trapping as outlined.

Reuse these questions as interview prompts or discussion starters to spread the fundamentals of accessibility across your team.

Section 4: ARIA and Assistive Technologies – Enhancing HTML

ARIA (Accessible Rich Internet Applications) attributes enhance HTML when semantic elements fall short, providing extra information to assistive technologies.

Think of ARIA like movie subtitles: they provide extra information for assistive tech, just as subtitles aid viewers. But don’t add ARIA to semantic HTML that already communicates meaning, just as you wouldn’t add subtitles to a silent film that shows everything visually.

Semantic HTML vs ARIA at a Glance

Knowing when to use semantic HTML or ARIA is crucial for accessibility. This comparison clarifies the trade-offs.

Semantic HTML:

• When to use it: Default for all standard UI elements.
• Strengths: Built-in keyboard and assistive technology support, simpler code, better performance.
• Limitations: May not cover highly custom interactions.

ARIA:

• When to use it: Custom widgets or complex, dynamic interactions.
• Strengths: Can describe rich behavior to assistive technologies.
• Limitations: Easy to misuse, must stay in sync with JavaScript.

Knowing when to use semantic HTML or ARIA is crucial for accessibility. This comparison clarifies the trade-offs.

Three quick rules of thumb:

1. If a native HTML element exists (e.g., button, link, or input), use it instead of ARIA.
2. If you build a custom widget, prove it works with keyboard-only and a screen reader before layering on extra ARIA.
3. If ARIA and native semantics disagree, the browser wins and users lose—fix the HTML first.

Quick Reference: Accessibility Patterns at a Glance

A clickable control:

• Use: <button>
• Avoid: <div role="button">

Navigation areas:

• Use: <nav>
• Avoid: Generic containers

Hidden live updates:

• Use: aria-live="polite"
• Avoid: Silent DOM text changes

Menus/dialogs:

• Use: roles + labels + keyboard trapping
• Avoid: mouse-only click toggles

This quick reference guides your choices; when unsure, use semantic HTML.

What ARIA Does

ARIA doesn’t alter appearance or behavior; it provides information to assistive technologies by communicating roles, properties, and states.

ARIA roles: Roles clarify element purpose; use roles like button, dialog, navigation, and region when HTML lacks semantic meaning.

ARIA labels: Labels provide text alternatives. Use aria-label for elements without visible text, and aria-labelledby to reference existing labels.

ARIA states: States indicate element conditions. Use aria-expanded, aria-hidden, aria-disabled, and aria-checked to convey dynamic states.

ARIA properties: Properties provide additional information. Use aria-describedby to reference descriptive text, and aria-required to indicate required form fields.

When to Use ARIA

Use ARIA when semantic HTML isn’t sufficient:

Custom components: Use ARIA to communicate purpose when building custom interactive components without semantic HTML.

Dynamic content: Use ARIA live regions to announce dynamic content changes to screen reader users.

Complex widgets: Use ARIA to communicate structure and behavior when building complex widgets, such as date pickers or autocomplete fields.

When NOT to Use ARIA

ARIA isn’t always necessary. Avoid using ARIA when:

• Semantic HTML elements already provide the needed meaning (<button> instead of <div role="button">).
• You’re using ARIA to fix problems that semantic HTML would solve better.
• ARIA attributes conflict with native element semantics.
• You’re adding ARIA without understanding how assistive technologies use it.

Use semantic HTML first, then add ARIA if needed.

Trade-offs and Limitations of ARIA

ARIA has trade-offs that add complexity and require maintenance. ARIA attributes must stay synced with element behavior; if JavaScript changes but ARIA doesn’t update, it can break.

ARIA has compatibility issues because screen readers interpret ARIA attributes differently, and some attribute combinations conflict. Testing with assistive tech is essential.

Performance matters. While ARIA attributes don’t affect performance, complex ARIA-dependent components can slow down. Custom widgets with extensive ARIA may be slower than native elements.

ARIA Examples

Here’s an example of ARIA used appropriately:

<button aria-expanded="false" aria-controls="menu" id="menu-button">
  Menu
</button>

<ul id="menu" aria-labelledby="menu-button" hidden>
  <li><a href="/">Home</a></li>
  <li><a href="/about">About</a></li>
  <li><a href="/contact">Contact</a></li>
</ul>

The aria-expanded attribute indicates whether the menu is open, aria-controls links the button to the menu, and aria-labelledby associates the menu with its label.

Screen Readers and Assistive Technologies

Screen readers are software that read content aloud for users who are blind or have low vision. Knowing how they work helps create accessible interfaces.

How screen readers work: Screen readers navigate the accessibility tree from HTML and ARIA, announcing elements, roles, states, and content.

Navigation patterns: Screen reader users navigate with keyboard shortcuts, jumping by headings, landmarks, links, and form controls.

Content structure: Screen readers depend on the heading hierarchy, semantic HTML, and ARIA attributes for navigating content.

Why Screen Readers Work This Way

Screen readers use the same accessibility tree from semantic HTML and ARIA. A clear structure ensures straightforward navigation; a messy one confuses.

Screen reader users use keyboard shortcuts to navigate because they cannot see the visual layout. They jump by headings for structure, landmarks for sections, and links for pages. Semantic structure is crucial as it shapes the navigation model.

Quick Check: ARIA and Screen Readers

Test your understanding:

• Do you understand when to use ARIA versus semantic HTML?
• Can you identify ARIA attributes that might conflict with native element semantics?
• Have you tested your ARIA implementations with actual screen readers?

Review your project for ARIA usage, identify where semantic HTML could replace ARIA, and ensure ARIA attributes align with element behavior.

Answer guidance: Ideal result: You understand that semantic HTML should be your default choice, and ARIA is only for cases where semantic HTML isn’t sufficient (custom widgets, complex interactions). You can identify when ARIA attributes might conflict with native element semantics. You’ve tested your ARIA implementations with a screen reader to verify announcements make sense.

If you’re unsure about when to use ARIA, review Section 4’s “When to Use ARIA” and “When NOT to Use ARIA” subsections. Test with NVDA (free) or VoiceOver (macOS) to see how your ARIA attributes are announced.

Semantic HTML forms the foundation, keyboard navigation is the doorway, and ARIA is the signage added when needed. More signs don’t improve a building—just the right signs do. Use ARIA sparingly, test thoroughly, and prioritize semantic HTML when adequate.

Section 5: Testing and Validation – Ensuring Accessibility

Testing ensures interfaces meet accessibility standards by using automated tools to catch issues and manual testing with assistive technologies.

Accessibility testing is like quality assurance: automated tools catch obvious defects quickly, like machines checking for manufacturing flaws, while manual testing detects subtle issues needing human judgment, like inspectors spotting design problems.

Automated Testing Tools

Automated tools quickly identify many accessibility issues, such as missing alt text, low contrast, and absent form labels. However, they can’t assess if alt text is meaningful, keyboard navigation is logical, or ARIA attributes are correct.

Understanding why they miss specific problems helps avoid relying solely on automated accessibility scores.

axe DevTools: Browser extension that tests pages for WCAG violations and offers guidance on fixing issues.

WAVE: Web accessibility tool visualizes issues on pages, showing errors, warnings, and features.

Lighthouse: Google’s tool offers accessibility audits, scores, and improvement suggestions.

HTML validators: Valid HTML tends to be more accessible. Use the W3C HTML Validator to check for errors.

CI/CD integration: Integrate automated accessibility testing into your workflow using tools like axe-core in pipelines and Storybook’s add-on to catch issues during development, preventing problems before code reaches production.

Why Automated Testing Has Limits

Automated tools detect code patterns, missing alt text, and color contrast, but can’t judge if alt text is meaningful or if color alone conveys information.

Automated tools can’t test user experience, like keyboard navigation or screen reader announcements. Manual testing with assistive technologies is essential.

Manual Testing

Manual testing catches issues automated tools miss:

Keyboard testing: Navigate the interface using only the keyboard, ensuring all elements are reachable and usable.

Screen reader testing: Test with screen readers like NVDA (Windows), JAWS (Windows), or VoiceOver (macOS). Experience how screen reader users interact with your interface.

Quick start: Try VoiceOver right now: press Command + F5 → Tab around → use Control + Option + Arrow keys to move through the accessibility tree. This single line turns theory into action.

Color contrast testing: Check color contrast ratios using tools like WebAIM’s Contrast Checker. Ensure text meets WCAG contrast requirements.

Zoom testing: Test interfaces at 200% zoom to ensure content remains usable. Many users with low vision rely on browser zoom.

Reduced motion testing: Test with prefers-reduced-motion enabled. Many users with vestibular disorders need animations slowed or disabled. Respect the system preference by using CSS media queries like @media (prefers-reduced-motion: reduce) to disable or slow animations.

System preference check: Enable prefers-reduced-motion in your operating system settings, then test your interface. Animations should slow or disable automatically when this preference is enabled.

Testing Checklist

Use this checklist when testing for accessibility:

• All images have appropriate alt text.
• All form inputs have associated labels.
• All interactive elements are keyboard accessible.
• Focus indicators are visible on all focusable elements.
• Color contrast meets WCAG AA standards (4.5:1 for normal text, 3:1 for large text).
• Heading hierarchy is logical and doesn’t skip levels.
• ARIA attributes are used correctly and only when necessary.
• Dynamic content changes are announced to screen reader users.
• Content is readable and functional at 200% zoom.
• No content relies solely on color to convey information.
• Animations respect prefers-reduced-motion system preference.

Trade-offs in Testing Approaches

Understanding why different testing approaches have different strengths helps you build a testing strategy that catches both obvious and subtle accessibility issues. Automated testing is fast but limited. Manual testing is thorough but time-consuming. The best approach combines both: use automated tools to catch common issues quickly, then perform manual testing for complex interactions and user experience.

Example: Automated vs Manual Testing

Consider a modal dialog that opens when users click a button. Automated testing with axe DevTools might report a perfect score: the button has proper ARIA attributes, the modal has correct roles, and all elements are keyboard accessible. However, manual testing with a screen reader reveals the modal announcement happens twice—once from the ARIA live region and once from the modal’s role announcement. This redundant announcement confuses screen reader users, but automated tools can’t detect it because the code technically follows ARIA patterns correctly.

This example illustrates why both approaches matter: automated tools catch structural issues (missing labels, low contrast), while manual testing catches user experience problems (confusing announcements, illogical focus order).

Testing with assistive technologies requires learning how they work. This takes time but provides insights that automated tools can’t. Budget time for learning screen readers and keyboard navigation patterns.

Quick Check: Testing

Test your understanding:

• Have you run automated accessibility tests on your project?
• Can you navigate your interface using only a keyboard?
• Have you tested with a screen reader?
• Do you know how to check color contrast ratios?

Set up automated testing in your development workflow, then schedule time for manual testing with assistive technologies.

Answer guidance: Ideal result: You’ve run automated tests (axe or Lighthouse), fixed the issues they found, can navigate your entire interface with only the keyboard, and have verified screen reader announcements on your main flows. You know how to check color contrast ratios using tools like WebAIM’s Contrast Checker.

If you haven’t run automated tests, start with axe DevTools or Lighthouse. If you haven’t tested with assistive technologies, begin with keyboard navigation testing, then add screen reader testing. Review Section 5’s testing checklist to ensure comprehensive coverage.

Section 6: Common Accessibility Mistakes – What to Avoid

Common mistakes create barriers for users. Understanding these mistakes helps you avoid them.

Missing Alt Text

Images without alt text are inaccessible to screen reader users. Provide descriptive alt text for informative images, or empty alt attributes for decorative images.

Incorrect:

<img src="chart.png">

Correct:

<img src="chart.png" alt="Sales increased 25% from Q1 to Q2">

Poor Keyboard Navigation

Interfaces that rely solely on mouse interactions exclude keyboard users. Make all interactive elements keyboard accessible.

Incorrect:

<div onclick="submitForm()">Submit</div>

Correct:

<button type="submit">Submit</button>

Low Color Contrast

Text with low contrast is difficult to read for many users. Check contrast ratios to meet WCAG standards.

Incorrect: Light gray text on a white background (contrast ratio 2:1).

Correct: Dark text on a white background (contrast ratio 4.5:1 or higher).

Missing Form Labels

Form inputs without labels confuse screen reader users. Always associate labels with inputs.

Incorrect:

<input type="text" placeholder="Enter your name">

Correct:

<label for="name">Enter your name</label>
<input type="text" id="name" name="name">

Inaccessible Dynamic Content

Content that changes without announcements confuses screen reader users. Use ARIA live regions to announce dynamic updates.

Incorrect:

<div id="status"></div>
<script>
  document.getElementById('status').textContent = 'Form submitted successfully';
</script>

Correct:

<div id="status" aria-live="polite" aria-atomic="true"></div>
<script>
  document.getElementById('status').textContent = 'Form submitted successfully';
</script>

Overusing ARIA

Using ARIA when semantic HTML would work creates unnecessary complexity. Use semantic HTML first, then add ARIA only when needed.

Incorrect:

<div role="button" tabindex="0" onclick="handleClick()">Click me</div>

Correct:

<button onclick="handleClick()">Click me</button>

Quick Check: Common Mistakes

Test your understanding:

• Can you identify images in your project that lack alt text?
• Do all your form inputs have associated labels?
• Are there any interactive elements that only work with mouse clicks?
• Does your interface rely solely on color to convey information?

Answer guidance: Ideal result: All images have appropriate alt text (descriptive for informative images, empty for decorative). All form inputs have associated labels connected via the for attribute. All interactive elements work with keyboards, not just mouse clicks. Information is never conveyed solely through color—text labels or icons accompany color coding.

If you found any issues, review the corresponding sections above. For images, add descriptive alt text or empty alt attributes for decorative images. For forms, connect labels using the for attribute. For mouse-only interactions, replace them with semantic HTML elements that work with keyboards. For color-only information, add text labels or icons.

Common Component Audit Examples

Here are specific examples of how to audit common interface components:

Modal dialogs:

• Good implementation: Focus trap + return focus to trigger + ARIA labelling (role="dialog", aria-labelledby, aria-describedby).
• Common failure: Opens visually but no focus shift, focus escapes to background content, no keyboard close option.

Tab interfaces:

• Good implementation: <button role="tab"> with arrow key navigation, proper aria-selected states, aria-controls linking to panels.
• Common failure: List of clickable <div> elements, no keyboard navigation, no ARIA roles or states.

Form error messages:

• Good implementation: Announced via aria-live="polite" or aria-live="assertive", associated with inputs via aria-describedby.
• Common failure: Only visible text, no announcement to screen readers, errors appear but aren’t discoverable.

These examples show how the fundamentals apply to real components. Audit your components against these patterns.

Section 7: Misconceptions and When Not to Use

Common misconceptions about accessibility create barriers. Understanding these misconceptions helps you avoid them.

Misconception: ARIA Fixes Everything

ARIA doesn’t fix accessibility problems. It only provides information to assistive technologies. If your interface isn’t keyboard accessible, ARIA won’t make it keyboard accessible. If your color contrast is too low, ARIA won’t fix it.

What to do instead: Start with semantic HTML elements that provide built-in accessibility. Use <button> instead of <div role="button">. Use <nav> instead of <div role="navigation">. Only add ARIA when semantic HTML isn’t sufficient, such as for custom widgets or dynamic content announcements. Test keyboard navigation before adding ARIA attributes.

Example: Instead of using <div role="button" tabindex="0">, use <button>. The button element provides keyboard support, focus management, and screen reader announcements automatically.

Misconception: Automated Testing Is Enough

Automated testing catches many issues, but it can’t catch everything. Manual testing with assistive technologies is essential. Automated tools can’t tell if keyboard navigation is logical or if screen reader announcements make sense.

What to do instead: Set up automated testing in your continuous integration pipeline to catch common issues. Then schedule weekly manual testing sessions where you navigate your interface using only the keyboard and test with a screen reader. Document keyboard navigation patterns and screen reader announcements for complex components.

Example: Run axe DevTools on every pull request to catch missing alt text and low contrast. Then, during code review, manually test new interactive components with keyboard navigation and screen reader announcements.

Misconception: Accessibility Is Only for Screen Reader Users

Accessibility benefits all users, not just screen reader users. Keyboard navigation helps users with motor disabilities, users who prefer keyboards, and users in situations where mice aren’t available. Color contrast helps users with low vision and users viewing screens in bright sunlight.

What to do instead: Test your interface from multiple perspectives. Use keyboard navigation to experience motor disability constraints. Test at 200% zoom to experience low vision. Test in bright sunlight to experience contrast issues. Build accessibility into your design system so all components work for diverse users.

Example: When designing a new component, test it with keyboard navigation, screen reader, and browser zoom before considering it complete. Document accessibility requirements in your component library so all team members understand the standards.

Misconception: Accessibility Is a One-Time Checklist

Accessibility is an ongoing practice, not a one-time checklist. New features need accessibility testing. Content updates need accessibility review. Design changes need accessibility validation.

What to do instead: Integrate accessibility checks into your development workflow. Add accessibility testing to your definition of done. Include accessibility review in design critiques. Set up automated accessibility testing in your CI/CD pipeline. Schedule regular accessibility audits, not just one-time checks.

Example: Create a pre-commit hook that runs automated accessibility tests. Include accessibility requirements in your pull request template. Review accessibility during design handoffs and code reviews.

When NOT to Reach for…

Custom widgets + ARIA:

• When to avoid it: When a native HTML control exists.
• What to do instead: Use <button>, <a>, <input> first.

Visual-only indicators:

• When to avoid it: When color is the only signal.
• What to do instead: Add text, icons, or patterns as backups.

One-off audits:

• When to avoid it: When your product changes frequently.
• What to do instead: Build checks into CI, design reviews, and code reviews.

When Fundamentals Don’t Apply

Accessibility fundamentals apply to most web interfaces, but some situations require specialist expertise. Complex applications with extensive custom widgets may need accessibility audits from specialists. Legal compliance requirements may need expert review.

When in doubt, test with actual assistive technologies and involve users with disabilities in your design and development process.

Limitations of Accessibility Fundamentals

Accessibility fundamentals provide a foundation, but they don’t cover every situation. Some disabilities require specialized solutions. Some interfaces need custom approaches that go beyond standard practices.

The fundamentals covered in this article provide a starting point. Continue learning, testing with assistive technologies, and involving users with disabilities in your process.

Quick Check: Misconceptions

Test your understanding:

• Have you tested your interface with keyboard navigation and screen readers?
• Is accessibility integrated into your development workflow, not just a one-time check?
• Do you understand that accessibility benefits all users, not just screen reader users?

Answer guidance: Ideal result: You’ve tested your interface with keyboard navigation and screen readers. Accessibility is integrated into your development workflow (automated tests in CI, manual testing during development, accessibility review in code reviews). You understand that accessibility benefits all users, including those with motor disabilities, low vision, and situational limitations.

If you answered no to any question, review the misconceptions above and implement the “What to do instead” actions. Start with weekly keyboard testing sessions and monthly screen reader testing. Add accessibility requirements to your definition of done and pull request templates.

Building Accessible Interfaces

Building accessible interfaces requires understanding fundamentals and applying them consistently. The workflow we covered—semantic HTML foundation, keyboard navigation structure, ARIA enhancement, and testing validation—creates interfaces that work for everyone.

Evaluation & Next Steps at a Glance

Key Takeaways

• Semantic HTML is the foundation - Start with semantic elements that convey meaning. This creates the structure that assistive technologies use to understand and navigate content.

• Keyboard navigation is essential - All interactive elements must work with keyboards. This includes proper focus management, visible focus indicators, and logical tab order.

• ARIA enhances, doesn’t replace - Use ARIA when semantic HTML isn’t sufficient. ARIA adds complexity and requires maintenance, so use it only when necessary.

• Testing combines automated and manual - Automated tools catch common issues quickly, but manual testing with assistive technologies catches user experience problems.

• Accessibility is ongoing - Build accessibility into your process from the start. Test as you build, not after everything is complete.

How These Concepts Connect

Semantic HTML creates the foundation that keyboard navigation and ARIA build upon. Without semantic HTML, keyboard navigation becomes difficult and ARIA becomes necessary but fragile. Without keyboard navigation, ARIA can’t help users who rely on keyboards. Without testing, you can’t know if your accessibility efforts are working.

These concepts work together: semantic HTML provides structure, keyboard navigation ensures operability, ARIA enhances when needed, and testing validates the result.

Getting Started with Accessibility

If you’re new to accessibility, start with a narrow, repeatable workflow instead of trying to fix everything at once:

1. Pick one page in your product as your “accessibility lab”.

2. Audit semantic HTML on that page: replace <div>-based buttons, fix headings, and add proper labels.

3. Test keyboard-only navigation on that page until you can complete key tasks without a mouse.

4. Run an automated accessibility tool (like axe or Lighthouse) and fix the highest-impact issues it finds.

5. Do a short screen reader test on your main flows to hear how your structure reads aloud.

Once this feels routine on one page, expand the same workflow to the rest of your product.

Next Steps

Immediate actions:

• Audit one page of your current project for semantic HTML usage.
• Test keyboard navigation on your latest interface.
• Run automated accessibility tests and fix the issues they find.

Learning path:

• Practice building a simple interface using only semantic HTML and keyboard navigation.
• Learn to use a screen reader (NVDA, JAWS, or VoiceOver) to experience how assistive technologies work.
• Study the WAI-ARIA Authoring Practices Guide for complex widget patterns.

Practice exercises:

• Build a form with proper labels and keyboard navigation.
• Create a modal dialog with focus trapping and keyboard closing.
• Add ARIA attributes to a custom component and test with a screen reader.

Questions for reflection:

• Where does your product rely solely on color to convey information?
• Can you navigate your entire interface using only the keyboard?
• What accessibility issues would users with disabilities encounter in your current project?

Accessibility isn’t a checklist to complete once. It’s an ongoing practice that improves interfaces for all users. Building accessibility into your process from the start is easier than retrofitting it later. The fundamentals covered in this article provide a foundation, but continue learning, testing with assistive technologies, and involving users with disabilities in your design and development process.

The Accessibility Workflow: A Quick Reminder

Before we conclude, here’s the core workflow one more time:

SEMANTIC HTML → KEYBOARD → ARIA (sparingly) → TESTING (real users + tools)

This four-step process applies to every interface you build. Start with semantic HTML for meaning, ensure keyboard navigation for operability, add ARIA only when needed, and test with both automated tools and real assistive technologies.

Final Quick Check

Before you move on, see if you can answer these out loud:

1. Why is semantic HTML the foundation of accessibility?

2. What are two concrete reasons keyboard navigation matters, even for sighted users?

3. When would you choose ARIA over native HTML elements?

4. Why can’t automated accessibility tests replace manual testing?

5. In your current product, where would involving an accessibility specialist make the most sense?

If any answer feels fuzzy, revisit the matching section and skim the examples again.

Self-Assessment – Can You Explain These in Your Own Words?

Before moving on, see if you can explain these concepts in your own words:

• How semantic HTML, keyboard navigation, ARIA, and testing fit into a single workflow.

• Two examples of when semantic HTML is enough, and one when ARIA is needed.

• One concrete way you’ll change your current project to improve accessibility this week.

If you can explain these clearly, you’ve internalized the fundamentals. If not, revisit the relevant sections and practice explaining them to someone else.

Future Trends & Evolving Standards

Accessibility standards and practices continue to evolve. Understanding upcoming changes helps you prepare for the future and build interfaces that remain accessible as standards update—without throwing away the semantic HTML, keyboard navigation, ARIA, and testing fundamentals you learned earlier in this article.

WCAG 2.2 to 3.0 Transition

The Web Content Accessibility Guidelines (WCAG) 2.2, published in 2023, added new success criteria for focus visibility, dragging movements, and target size. WCAG 3.0, currently in development, shifts from strict pass/fail rules to a more flexible scoring system.

Understanding why standards evolve helps you build interfaces that adapt to changes rather than breaking when new guidelines emerge.

What this means: WCAG 3.0 will use a points-based system instead of binary pass/fail criteria. This allows for partial credit and recognizes that accessibility exists on a spectrum. The new guidelines will also better address mobile accessibility and cognitive disabilities.

How to prepare: Stay informed about WCAG 3.0 development through the W3C WAI website. Continue following WCAG 2.2 AA standards while monitoring 3.0 progress. Build interfaces with flexibility in mind, focusing on user experience rather than just checklist compliance.

WCAG 3.0 won’t invalidate WCAG 2.2—conformance will remain relevant for years. You’re building future-proof fundamentals, not throwaway knowledge. The semantic HTML, keyboard navigation, ARIA patterns, and testing approaches you learn here will serve you regardless of which WCAG version becomes dominant.

Native Browser Improvements

Browsers continue to improve native accessibility features. Modern browsers provide better default focus indicators, improved screen reader support, and enhanced keyboard navigation.

What this means: Native HTML elements receive better accessibility support over time. Semantic HTML becomes more powerful as browsers improve. Custom components may need updates to match native improvements.

Recent examples: Chrome 123 (2024) introduced improved default focus ring styles that are more visible and consistent across platforms. Safari’s VoiceOver rotor enhancements in iOS 17 allow users to navigate by form controls more efficiently. Firefox 120 (2023) improved screen reader announcements for dynamic content updates.

How to prepare: Prefer native semantic elements over custom components when possible. Test with the latest browser versions to take advantage of improvements. Monitor browser release notes for accessibility enhancements, such as Chrome developer blog and MDN’s accessibility documentation.

Evolving Assistive Technologies

Screen readers and other assistive technologies continue to evolve. New features, improved navigation patterns, and better integration with web standards emerge regularly.

What this means: Screen reader users develop new navigation patterns as tools improve. Your interfaces should work with both current and emerging assistive technology features. Testing with multiple assistive technologies becomes more important.

Recent examples: NVDA 2024.1 added improved support for ARIA 1.2 properties, making complex widgets more navigable. JAWS 2024 introduced enhanced virtual cursor navigation for single-page applications. VoiceOver in macOS Sonoma (2023) improved navigation by landmarks and added better support for ARIA live regions.

How to prepare: Test with multiple screen readers (NVDA, JAWS, VoiceOver) to ensure compatibility. Stay informed about assistive technology updates through NVDA downloads and changelog, JAWS product information, and Apple accessibility updates. Involve users with disabilities in testing to understand real-world usage patterns.

Quick start: To try VoiceOver today: press Command + F5 → Tab around → use Control+Option+Arrow keys to move through the accessibility tree. This lowers the barrier from “I should test someday” to “I can test in 10 seconds.”

Emerging Standards and Patterns

New accessibility patterns emerge as web technologies evolve. ARIA patterns improve, new semantic elements are proposed, and best practices refine over time.

What this means: Accessibility practices aren’t static. What works today may be superseded by better approaches tomorrow. Staying current with best practices ensures your interfaces remain accessible.

How to prepare: Follow accessibility communities and resources like The A11y Project and WebAIM. Participate in accessibility discussions. Review and update your accessibility practices regularly.

Looking ahead: Role-based ARIA will matter less over the next decade as browsers ship more native semantics—custom widgets will shrink in relevance. The fundamentals of semantic HTML and keyboard navigation will remain constant, but the need for complex ARIA patterns will decrease as native browser support improves.

Limitations & When to Involve Specialists

Accessibility fundamentals provide a strong foundation, but some situations require specialist expertise. Understanding when to escalate ensures you get the right help at the right time.

When Fundamentals Aren’t Enough

Some accessibility challenges go beyond the fundamentals covered in this article. A good rule of thumb: if a pattern can’t be expressed with standard HTML, basic ARIA, and straightforward keyboard flows, you may be entering specialist territory.

Complex data visualizations: Charts, graphs, and interactive data visualizations require specialized accessibility approaches. Simple alt text isn’t sufficient for complex data relationships.

Legal compliance requirements: Organizations subject to specific accessibility laws may need legal review to ensure compliance. Accessibility audits from certified professionals may be required.

Specialized assistive technologies: Some users rely on assistive technologies beyond screen readers, such as eye-tracking systems, switch controls, or voice recognition software. These require specialized testing and implementation.

Complex custom widgets: Highly customized interface components may need accessibility audits from specialists who understand advanced ARIA patterns and assistive technology interactions.

When Not to DIY Accessibility

There are situations where fundamentals alone aren’t enough and “DIY accessibility” becomes risky:

• Complex, interactive data visualizations that represent critical information.

• Highly customized widgets that don’t match any standard HTML/ARIA pattern.

• Products that must meet strict legal or contractual accessibility requirements.

• Large legacy codebases with known accessibility issues and tight timelines.

In these cases, specialists can help you apply the fundamentals correctly and design patterns that work reliably with assistive technologies.

When to Involve Accessibility Specialists

Consider involving accessibility specialists when:

• Your organization requires legal compliance certification or audits.
• You’re building complex data visualizations that need alternative representations.
• You’re creating highly customized widgets that go beyond standard patterns.
• You need accessibility training for your entire team.
• You’re retrofitting a large existing application with accessibility issues.
• You need expert review of your accessibility implementation.

How to find specialists: Look for certified accessibility professionals through organizations like the International Association of Accessibility Professionals (IAAP). Many accessibility consultancies offer audits, training, and implementation support.

Working with Specialists

When working with accessibility specialists:

• Share your accessibility fundamentals knowledge so specialists can build on your foundation.
• Provide access to your codebase, design system, and user research.
• Involve specialists early in the design and development process, not just for audits.
• Ask questions to understand their recommendations and learn from their expertise.
• Implement their recommendations and follow up with testing to ensure improvements work.

Accessibility fundamentals provide the foundation, but specialists help with complex challenges and ensure compliance. Build your fundamentals knowledge, then involve specialists when you encounter situations beyond your expertise.

Glossary

Accessibility: The practice of building interfaces that everyone can use, regardless of ability.

ARIA: Accessible Rich Internet Applications attributes that enhance HTML when semantic elements aren’t sufficient.

ARIA live regions: ARIA attributes (aria-live, aria-atomic, aria-relevant) that announce dynamic content changes to screen reader users without requiring them to navigate to that content.

Assistive technology: Software or hardware that helps users with disabilities interact with interfaces, such as screen readers or voice control.

Focus indicator: Visual indication of which element currently has keyboard focus.

Semantic HTML: HTML elements that convey meaning about content structure and purpose.

Screen reader: Software that reads content aloud to users who are blind or have low vision.

WCAG: Web Content Accessibility Guidelines, international standards for web accessibility.

References

Industry Standards

• Web Content Accessibility Guidelines (WCAG) 2.2: International standards for web accessibility published by the World Wide Web Consortium (W3C).
• WAI-ARIA Authoring Practices Guide: Comprehensive guide to using ARIA attributes effectively from the W3C.
• MDN Web Docs - Accessibility: Comprehensive documentation on web accessibility from Mozilla.

Testing Tools

• axe DevTools: Browser extension for automated accessibility testing with detailed guidance on fixing issues.
• WAVE Web Accessibility Evaluation Tool: Free tool that visualizes accessibility issues on web pages.
• WebAIM Contrast Checker: Tool for checking color contrast ratios against WCAG standards.
• Lighthouse: Google’s tool that includes accessibility audits along with performance and other metrics.

Community Resources

• The A11y Project: Community-driven effort to make web accessibility easier with checklists, resources, and patterns.
• WebAIM: Comprehensive resource for web accessibility information, training, and tools.
• Inclusive Components: Blog and pattern library focused on building accessible interface components.

Legal Requirements

• Americans with Disabilities Act (ADA): United States law requiring accessibility in public accommodations, including websites.
• Section 508: United States federal law requiring accessibility in information and communication technology.
• European Accessibility Act (EAA): European Union legislation requiring accessibility in products and services.

Screen Readers

• NVDA (NonVisual Desktop Access): Free, open-source screen reader for Windows.
• JAWS (Job Access With Speech): Popular commercial screen reader for Windows.
• VoiceOver: Built-in screen reader for macOS and iOS devices.

Color and Contrast

• WebAIM Contrast Checker: Tool for checking color contrast ratios.
• Color Contrast Analyzer: Application for checking color contrast in desktop applications and web pages.

Note on Verification

Accessibility standards and best practices evolve. The Web Content Accessibility Guidelines are updated periodically, and new assistive technologies emerge. Verify current information and test with actual assistive technologies to ensure your interfaces work for users with disabilities.