Accessibility for Developers: The Essential Guide

Author: Level Access

Accessibility is the practice of building digital experiences that people with disabilities—and everyone else—can use equally. This guide for developers covers the Web Content Accessibility Guidelines (WCAG) standards, semantic HTML, keyboard navigation, ARIA, forms, testing tools, and how to embed accessibility into your development workflow.

For developers, accessibility is a code quality issue, not a compliance afterthought. Yet many teams still treat it as something outside their scope of work, handled by a specialist or addressed only after a lawsuit. The problem? The longer developers defer accessibility issues, the more technical debt they need to pay down when legal issues do arise or a deal is on the line.

If you’re ready to get ahead of a future backlog, this guide is your starting point. We’ll cover what accessibility means in development, related laws and standards, and the practical habits and tools that make inclusive front-end development a sustainable default.

Key insights

• Accessible development helps make websites, apps, and other experiences usable by the 1.3 billion people worldwide living with a disability, contributing to a better experience for everyone.
• WCAG is the global technical standard for digital accessibility. Conforming to WCAG 2.1 or 2.2 Level AA is recommended for compliance with many U.S. and international laws.
• According to the latest WebAIM Million report, six error categories account for 96% of all detected WCAG failures—and they’ve been the same for seven years running.
• Automated tools cannot catch all WCAG issues; manual accessibility testing with a keyboard and screen reader is essential to close the gap.
• It’s estimated that fixing accessibility issues in production costs 10–30x more than catching them during design and build.

What is digital accessibility?

Digital accessibility is the practice of creating websites, mobile apps, and other digital experiences that are usable by as many people as possible. For developers, that means writing code—including HTML, CSS, and JavaScript—so that someone using assistive technology (like a screen reader, keyboard navigation, voice control, switch device, or magnifier) can complete tasks as easily as anyone else. The goal is not a separate experience for people with disabilities. It is the same experience, built to work for everyone.

Put simply, accessibility is not a special case. It is the baseline. The same code decisions that benefit a user who is blind and navigating by screen reader also help a mobile user on a slow connection, someone in bright sunlight squinting at low contrast, or a person with a broken arm who cannot grip a mouse.

According to the World Health Organization, approximately 1.3 billion people worldwide live with a disability. That is 16% of the global population—a user base no product team can afford to ignore.

Who are you building for? Users and assistive technologies

Many types of disabilities can impact how users engage with the digital world. To build accessible experiences, it can be helpful to understand how users with different kinds of disabilities may interact with digital experiences, including the types of assistive technologies they may use and their specific access needs.

The Web Content Accessibility Guidelines (WCAG): POUR, and AA

The Web Content Accessibility Guidelines (WCAG) are the global technical standard maintained by the Worldwide Web Consortium (W3C). Many major accessibility regulations—including Title II of the Americans with Disabilities Act (ADA), the European Accessibility Act (EAA), Section 508 of the Rehabilitation Act of 1973, and the Accessible Canada Act (ACA)—either reference WCAG directly or use a standard derived from it. WCAG is organized around four principles, known as POUR:

• Perceivable: People must be able to perceive all information and interface components—nothing should be invisible to all their senses.
• Operable: People must be able to operate the interface using whatever input method they have, including non-mouse input.
• Understandable: Information and interface operation must be understandable, with clear language, predictable behavior, and helpful error messages.
• Robust: Content must be robust enough to be reliably interpreted by current and future assistive technologies.

WCAG has three conformance levels. Level A is the minimum. Level AA is the practical legal target referenced in most laws and settlement agreements. It offers broader access than Level A, especially for users of assistive technologies. Level AAA is the highest achievable level of conformance.

New WCAG success criteria in 2.2

WCAG 2.2, published in October 2023, added six new Level AA success criteria. Here are some of the most relevant ones for developers:

• 2.4.11 Focus Not Obscured: A component that receives focus must not be entirely hidden by sticky headers, cookie banners, or other persistent UI.
• 2.5.7 Dragging Movements: Any action that requires dragging must have a single-pointer alternative (for example, a button to move a slider).
• 2.5.8 Target Size: Interactive targets must be at least 24x 24 CSS pixels, with exceptions for inline links and targets whose size is set by the browser.
• 3.3.7 Accessible Authentication: Authentication must not require users to solve cognitive puzzles (like CAPTCHAs) as the only option.
• 3.3.9 Redundant Entry: Information already entered by a person must not be requested again in the same session unless re-entry is essential.

While WCAG 2.1 AA is the standard most commonly targeted by organizations, conforming to WCAG 2.2 can help you future-proof your products and services.

Accessibility standards and legal requirements

For most developers, accessibility starts as a technical discipline—but it carries real legal weight. Across the U.S., EU, U.K., and Canada, laws require that digital products meet defined accessibility standards, and the consequences of non-compliance range from ADA demand letters to hefty financial penalties in some EU countries.

The regulatory picture has solidified significantly since 2024, with new regulations taking effect on both sides of the Atlantic. Let’s explore key laws and regulations across markets.

United States

Title III of the ADA prohibits disability discrimination in places of public accommodation—a category courts have consistently applied to commercial websites. More than 3,000 accessibility lawsuits were filed in federal court in 2025 alone, according to Seyfarth Shaw. Other laws to be aware of include:

• ADA Title II: The U.S. Department of Justice’s (DOJ) April 2024 rule under Title II explicitly pegs WCAG 2.1 AA as the standard for state and local government websites.
• Section 504: A rule from the Department of Health and Human Services (HHS) under Section 504 of the Rehabilitation Act of 1973 extends the same requirement to healthcare organizations receiving federal funding.
• Section 508: Section 508 of the Rehabilitation Act requires WCAG 2.0 Level AA conformance for federal agencies.

European Union

The EAA became enforceable on June 28, 2025. It covers e-commerce platforms, banking apps, transport services, and most consumer-facing digital products sold in the EU. The presumptive standard is EN 301 549, which incorporates WCAG 2.1 AA success criteria.

United Kingdom

The Equality Act 2010 creates a legal duty to make reasonable adjustments for people with disabilities. The Public Sector Bodies Accessibility Regulations 2018 requires all U.K. public sector websites to conform with WCAG 2.1 AA and publish an accessibility statement.

Canada

The Accessibility for Ontarians with Disabilities Act (AODA) applies to organizations operating in Ontario. At the federal level, The Accessible Canada Act (ACA), enacted in 2019, is designed to identify, eliminate, and prevent barriers to accessibility throughout Canada. Its long-term objective is to create a barrier-free Canada by January 1, 2040. The Act applies to all federally regulated entities, including federal government departments and agencies, Crown corporations, banks, telecommunications and broadcasting organizations, as well as interprovincial transportation providers.

Common accessibility failures—and how to avoid them

According to WebAIM’s annual Million report, six error categories account for 96% of all detected WCAG failures—and they’ve been the same for seven years running. Those categories are low contrast text, missing alt text, missing form labels, empty links, empty buttons, and missing document language.

Beyond this basic list, many of the same failure patterns appear over and over across codebases. The table below maps some of the most common mistakes that developers make directly to their fixes.

Of course, building for accessibility from the start is much easier than fixing issues after the fact. The five habits below can help you steer clear of these failure patterns before issues pile up in your backlog.

1. Use semantic HTML before ARIA. Native HTML tags carry built-in accessibility semantics. A <button> is focusable, activatable by Enter / Space, and announced correctly by screen readers. A <div onClick> does none of those things without extra work.
2. Make every interactive control operable without a mouse. Every interactive control must be reachable by Tab, operable by Enter or Space (or arrow keys for composite widgets), and must show a visible focus indicator.
3. Label everything. Every input needs a <label>, every image needs alt text, every icon-only button needs an accessible name. No control that communicates information should be hidden from screen readers.
4. Contrast ≥4.5:1. Body text must have a contrast ratio of at least 4.5:1 against its background (WCAG 1.4.3). Large text and UI components need 3:1 (WCAG 1.4.11). Error states must use icon and text, not color alone.
5. Test in CI. Issues caught before merge cost a fraction of what they cost in production. Use accessibility CI/CD integrations to test every pull request (PR).

We’ll explore each of these best practices in more depth in the sections that follow.

Semantic HTML: Structuring web content accessibly

The most powerful accessibility tool available to a developer isn’t a library or a testing framework—it’s the HTML you’re already writing. Native HTML elements carry built-in accessibility semantics that browsers and assistive technologies already understand. A <button> is focusable, activatable, and announced correctly by screen readers out of the box. A <nav> tells assistive technology it’s a navigation region without a single extra attribute.

The more you lean on semantic HTML, the less remediation work you create for yourself—and the less your user interface (UI) depends on patches to fix what the wrong element broke.

Buttons vs. div handlers

When a <div> or <span> is wired up with an onClick handler, mouse users may not notice the difference—but users navigating by keyboard and screen readers lose all interactivity. A native <button> gives you tab focus, Enter / Space activation, and a correct screen reader announcement for free. The cost of <div onClick> is never worth paying.

Use the right HTML element. If it does something, it’s a <button>. If it goes somewhere, it’s an <a>.

Landmark regions

Landmarks let assistive technology help people jump to sections of a page without tabbing through every item. Use <header>, <nav>, <main>, <aside>, and <footer> rather than generic <div> wrappers.

Headings and page structure

While technically optional, using one <h1> per page is considered a best practice. Subsequent headings must follow sequential order (h1 → h2 → h3)—never skip a level. Assistive technology like screen readers exposes a rotor or landmarks list that lets people navigate by heading; a broken heading outline is as disorienting as a document with scrambled sections.

Keyboard operability and focus indicators for interactive elements

Always ensure that digital experiences are usable for people who navigate with the keyboard, rather than a mouse or pointer. That means every interactive control must be reachable by Tab, operable by Enter or Space (or arrow keys for composite widgets), and must display a visible focus indicator.

To build for keyboard accessibility, account for:

• tabindex rules: Use tabindex=”0″ to add a non-interactive element to the tab order. Use tabindex=”-1″ to make an element programmatically focusable but invisible to Tab. Never use a positive tabindex—it overrides the natural order in ways that almost always cause errors.
• Cursor management: When a modal opens, move the cursor to the first interactive control inside it. When it closes, return it to the trigger that opened it. On route changes in single-page apps, move the cursor to the heading or a skip-link target so the browser can signal the page has changed.
• Skip links: Add a visible-on-tab skip link as the first focusable control on every page: <a href=”#main” class=”skip-link”>Skip to main content</a>. This lets people bypass repeated navigation without tabbing through every menu item.
• Focus traps: Modal dialogs must trap navigation inside them while open. Custom dropdowns and date pickers are common offenders—test them with tab navigation only.

If you’re unsure whether an experience is accessible to keyboard users, try this quick test. Unplug your mouse, press Tab, and navigate your current PR from the top of the page to the end of the critical user flow. If you get lost at any point, users relying on tab navigation will too.

When and how to use ARIA

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that add semantic meaning to tags that lack it. Importantly, it is a supplement to semantic HTML, not a replacement. Before applying ARIA, ask whether a native HTML tag would do the job.

Where ARIA is especially helpful is labeling. Every interactive control must have an accessible name that screen readers can announce, and when no visible label exists, ARIA attributes provide one. An unlabeled button, icon, or custom widget is effectively hidden from assistive technology, which is why labeling is one of the five habits that address most common accessibility failures.

• aria-label. Provides an accessible name when there is no visible label. For example, use it for icon-only buttons: <button aria-label=”Close”><svg …/></button>.
• aria-labelledby. Points to an existing tag that serves as the accessible name. Prefer this over aria-label when a visible label already exists.
• aria-describedby. Points to a tag that provides supplementary description—use for error messages, hint text, or character counts on inputs.
• aria-live. Marks a region for dynamic updates. Use aria-live=”polite” for toasts and notifications so screen readers announce them without interrupting the person’s current task.

Forms and errors

Forms are the single most common source of accessibility failures—and these issues can be especially high-stakes. A checkout flow, a login screen, or a contact form that a screen reader user cannot complete doesn’t just create a poor experience; it can lock them out of the product entirely. The most frequent culprits for form issues are missing labels, error messages that aren’t programmatically associated with their inputs, and required fields that are only marked visually.

The following tips for form accessibility align with WCAG requirements, and most take only a few lines of code.

• Label every input: Use <label for=”inputId”> on every form control. Placeholder text is not a label—it disappears on focus and fails WCAG 1.3.1 (Info and Relationships) and 3.3.2 (Labels or Instructions).
• Mark required fields: Add both a visual indicator (asterisk) and a programmatic one (required attribute or aria-required=”true”) so screen readers can tell users which fields cannot be left blank.
• Identify errors and describe how to fix them: Use aria-describedby to associate each error message directly with its input field, and move the focus indicator to the error summary on form submission so screen reader users land in the right place. Where possible, suggest the correction—not just that an error occurred.
• Add autocomplete attributes to every relevant field. This reduces cognitive load for all users. Commonly forgotten tokens include: email, tel, current-password, new-password, one-time-code.
• Make authentication accessible without cognitive puzzles. Provide at least one authentication option that doesn’t require solving a CAPTCHA or similar cognitive test.

Images, icons, and media

Inaccessible images and videos can be highly disruptive to users’ experience. For example, missing or poorly written alt text can leave users who are blind or have low vision without context for images, and uncaptioned video may make it difficult, or even impossible for users who are deaf and hard-of-hearing to understand content. In some cases, inaccessible media can be actively harmful: animations that play without warning can trigger vestibular disorders.

The tips below cover the decisions developers and content authors face most often.

• Write alt text that describes information, not appearance: For informative images, describe what the image communicates. For decorative images, use alt=”” (empty string, not absent) so screen readers skip them. For functional images—linked images or icon buttons—describe the action, not the image itself. Never write “Image of…”; screen readers already announce that it’s an image.
• Mark SVG icons as either meaningful or decorative: Inline SVGs used as graphics need <svg role=”img” aria-label=”Search”> so assistive technology can announce them. Decorative SVGs need aria-hidden=”true” so assistive technology skips them entirely.
• Caption every video accurately: Add a <track kind=”captions”> tag to every <video> element. Auto-generated captions frequently fail WCAG 1.2.2 (Captions, Prerecorded)—review and correct them to ensure they are accurate and synchronized with the audio.
• Provide transcripts for audio-only content: A text transcript is required for any audio-only content and benefits a wider audience than just deaf or hard-of-hearing users—including users without disabilities who cannot play audio in their current environment.
• Disable animations for users who have opted out: Wrap animations in @media (prefers-reduced-motion: no-preference) so they are automatically disabled for users with vestibular disabilities or motion sensitivity who have set their OS preference accordingly.

Color and contrast

Color is one of the first things designers use to communicate meaning—and one of the most common practices that inadvertently exclude users. Approximately 1 in 12 men and 1 in 200 women have some form of color blindness, and many more users encounter low-contrast text in bright sunlight or on low-quality displays. WCAG defines minimum contrast ratios for text and UI components, and requires that color never be the sole means of conveying information.

For contrast ratios, body text must meet ≥4.5:1 against its background (WCAG 1.4.3), while large text (18pt or 14pt bold) and UI components such as input borders and focus rings need ≥3:1 (WCAG 1.4.11). Use our free Color Contrast Checker or the Chrome DevTools color picker—hover any color in the Styles panel—to verify your values before shipping.

Never use color as the only way to communicate state or meaning. Error states must combine color with an icon or text label: a red border alone on an invalid input fails users with color blindness and fails WCAG 1.4.1 (Use of Color). Finally, test with Windows High Contrast mode—or the CSS forced-colors media query—to verify that your UI components remain distinguishable when the OS overrides your color scheme entirely.

How to test with screen readers and automated tools

Writing accessible code is only half the work—you also need to verify it. Accessibility testing is the process of checking that what you’ve built actually works for people using assistive technologies. A comprehensive approach combines automated scanning with manual testing by experts, including people with disabilities.

Automated testing

Automated tools can rapidly identify many common issues. There are several free automated tools that can help test code accessibility, such as Google Lighthouse Accessibility and WAVE from WebAIM. Paid tools like those offered by Level Access have even more powerful capabilities.

Manual testing

While automated tools are valuable for surfacing quick insight, they cannot detect all issues. For this reason, manual evaluation using assistive technologies is essential. To get the most reliable results, engage a team of professionals—including native users of assistive technologies—to perform an audit of key user flows, pages, and components.

While formal testing should be done by experts, you can spot-check your own work for more obvious keyboard and screen reader accessibility issues using the following steps.

Keyboard accessibility testing: Quick spot-check

Check for these behaviors with your mouse unplugged:

1. Every interactive control is reachable by Tab.
2. Tab order is logical.
3. Indicators are always visible.
4. All interactive controls activate with Enter or Space.
5. Modals trap the focus indicator and return it on close.
6. Skip links work and appear on Tab.

Screen reader testing: Quick spot-check

Test the navigation journey first, then redo it with screen readers running—the two passes surface different issues. For example, assistive technology may announce a control differently than you expect even when keyboard navigation works correctly.

• MacOS: Press Cmd + F5 to enable VoiceOver, then use Ctrl + Option + arrow keys to navigate.
• Windows: Activate Narrator by pressing the Windows logo key + Ctrl + Enter simultaneously. You may also install NVDA (free).
• Mobile: Use TalkBack (Android) or VoiceOver (iOS).

Beyond code: Meeting accessibility requirements as a team

Developers cannot address accessibility alone. Design decisions—color palettes, font sizes, interaction patterns—arrive in a PR already committed. Content decisions—heading structure, link text, alt text on images—are often made by writers and editors. Quality assurance (QA), leadership, and procurement all play a role. Accessibility is a program, not a ticket.

Start building accessibility into your dev workflow today

Accessibility is not a feature you add at the end. It is a quality baseline you maintain from ideation to release. The case for proactive accessibility is economic as well as ethical: fixing issues during design and build is more cost-effective than fixing them post-release. Every sprint that ships inaccessible code adds to a remediation backlog that compounds over time.

The developers who find accessibility sustainable are the ones who embed it into their tools and habits—using semantic HTML as the default and catching issues in PRs instead of production.

Knowing what to fix is the first step toward this steady state. Fixing it efficiently—and preventing it from coming back—is the harder part. Explore the Accessibility Resolution Playbook for a step-by-step roadmap to making accessibility a seamless part of development. You’ll learn how to prioritize the right issues, integrate fixes into existing workflows, and build the processes that prevent regressions.