Web Accessibility and WCAG Compliance: Building Software Everyone Can Use

Over one billion people worldwide live with some form of disability. That’s roughly 15% of the global population — and every one of them is a potential user of your software. Yet most web applications fail basic accessibility checks. WebAIM’s annual analysis of the top one million homepages found an average of 56.8 accessibility errors per page in 2024. That’s not a minor gap. It’s a systemic failure.

Web accessibility isn’t a checkbox exercise or a “nice-to-have” feature. It’s a legal requirement in most major markets, a direct contributor to better UX for all users, and an increasingly enforced compliance standard. This guide covers what you need to know to build accessible software — from the legal landscape to practical implementation.

The Legal Landscape: Why Compliance Is Non-Negotiable

Accessibility legislation has accelerated rapidly. If your software serves users in the US, EU, or most developed markets, you’re likely already subject to legal requirements.

Americans with Disabilities Act (ADA)

The ADA doesn’t explicitly mention websites, but US courts have consistently interpreted it to cover digital properties. Since the landmark Domino’s v. Robles ruling in 2019, the legal precedent is clear: websites and mobile apps of businesses that serve the public must be accessible. ADA-related web accessibility lawsuits exceeded 4,600 in 2023 — a number that has grown every year since tracking began.

European Accessibility Act (EAA) — June 2025

The European Accessibility Act is the most significant accessibility legislation in a decade. Effective June 28, 2025, it requires that digital products and services sold in the EU meet accessibility standards. This applies to e-commerce, banking, transport, and most consumer-facing digital services. The EAA doesn’t just apply to EU-based companies — it applies to any company selling digital products or services to EU consumers.

Non-compliance can result in fines, product bans from the EU market, and civil liability.

Section 508 (US Federal)

Section 508 of the Rehabilitation Act requires all federal agencies and contractors to make their electronic and information technology accessible. If you build software for the US government or receive federal funding, Section 508 compliance is mandatory.

EN 301 549 (European Standard)

The European standard EN 301 549 provides the technical specification for ICT accessibility in the EU. It maps closely to WCAG 2.1 AA and is the benchmark the EAA references.

The Takeaway

The direction is clear: accessibility requirements are expanding, not contracting. Building accessible software today is cheaper than retrofitting it tomorrow and getting sued in between.

WCAG 2.2 AA: The Standard Explained

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the globally recognized standard for web accessibility. WCAG 2.2, released in October 2023, is the current version. Most legal frameworks reference WCAG 2.1 AA as the minimum, with 2.2 AA becoming the target standard.

WCAG is organized around four principles, remembered by the acronym POUR:

Perceivable

Users must be able to perceive the information being presented. This means:

• Text alternatives for non-text content (images, icons, charts).
• Captions and transcripts for audio and video content.
• Sufficient color contrast between text and background (minimum 4.5:1 for normal text, 3:1 for large text).
• Content that doesn’t rely solely on color to convey meaning (e.g., error states indicated only by red text).
• Responsive layouts that work when users zoom to 200% or use text-only zoom.

Operable

Users must be able to operate the interface. This means:

• Full keyboard accessibility. Every interactive element must be reachable and usable with a keyboard alone. No mouse required.
• Visible focus indicators. Users navigating by keyboard need to see where they are on the page.
• No time traps. If content has a time limit, users must be able to extend or disable it.
• No seizure-inducing content. Nothing that flashes more than three times per second.
• Skip navigation links to bypass repetitive content blocks.
• Consistent navigation across pages.

Understandable

The content and interface must be understandable. This means:

• Readable text. Language is identified programmatically. Text is written at an appropriate reading level.
• Predictable behavior. Navigation is consistent. Interactive elements behave as expected. No unexpected context changes.
• Input assistance. Form errors are clearly identified and described. Labels and instructions are provided. Suggestions for correction are offered.

Robust

Content must be robust enough to work with current and future assistive technologies. This means:

• Valid, well-structured HTML. Semantic elements used appropriately.
• ARIA attributes applied correctly (or not at all — incorrect ARIA is worse than no ARIA).
• Compatibility with assistive technologies like screen readers, screen magnifiers, and voice control.

WCAG 2.2 New Success Criteria

WCAG 2.2 added several criteria worth noting:

• Focus Not Obscured (Minimum). When an element receives keyboard focus, it can’t be entirely hidden by author-created content (sticky headers, modal overlays).
• Dragging Movements. Any functionality that uses dragging must have a single-pointer alternative (e.g., drag-to-reorder must also allow button-based reordering).
• Target Size (Minimum). Interactive targets must be at least 24x24 CSS pixels, with some exceptions.
• Consistent Help. Help mechanisms (chat, contact info, FAQ links) must appear in the same relative location across pages.

Common Accessibility Violations and How to Fix Them

These are the violations we encounter most frequently in production applications, along with concrete fixes.

1. Missing or Poor Color Contrast

The problem: Text that doesn’t meet minimum contrast ratios. Light gray on white is the most common offender.

The fix: Use a contrast checker (the Chrome DevTools built-in checker works well) and ensure 4.5:1 for normal text, 3:1 for large text (18px+ bold or 24px+ regular). Don’t rely on color alone for conveying information — pair it with icons, text labels, or patterns.

2. Missing Alt Text on Images

The problem: Screen readers announce images without alt text as “image” or read the file name. Decorative images that aren’t marked as decorative add noise.

The fix: Add descriptive alt attributes to informational images. Use alt="" (empty alt) for decorative images. For complex images like charts, provide a longer description via aria-describedby or a visible caption.

3. Missing or Incorrect Form Labels

The problem: Form inputs without programmatically associated labels. Placeholder text alone is not a label — it disappears on input and isn’t reliably announced by screen readers.

The fix: Every form control needs a <label> element with a matching for attribute. For visually hidden labels, use a CSS class that hides the label visually but keeps it available to assistive technology. Never use display: none or visibility: hidden on labels you want screen readers to find.

4. Broken Keyboard Navigation

The problem: Custom components (dropdowns, modals, tabs, carousels) that only work with a mouse. Focus gets trapped in modals without an escape. Tab order doesn’t match visual order.

The fix: Test every interactive element with keyboard alone. Use native HTML elements where possible (<button>, <select>, <input>) — they come with keyboard support built in. For custom components, implement proper focus management: tab order, arrow key navigation within composite widgets, and Escape to close overlays.

5. Missing Skip Navigation

The problem: Keyboard users must tab through the entire navigation menu on every page before reaching the main content.

The fix: Add a “Skip to main content” link as the first focusable element on the page. It can be visually hidden until it receives focus.

6. Poor Focus Management in Single-Page Applications

The problem: When a route changes in a SPA, focus stays where it was (often on the navigation link). Screen reader users don’t know the page content has changed.

The fix: On route change, move focus to the main content area or an appropriate heading. Announce the page change via a live region or document title update.

7. Inaccessible Dynamic Content

The problem: Content that updates dynamically (notifications, live search results, error messages) without informing assistive technology.

The fix: Use ARIA live regions. aria-live="polite" for non-urgent updates (search results filtering). aria-live="assertive" for critical updates (error messages, alerts). Keep live region announcements concise.

ARIA: The Rules of Engagement

ARIA (Accessible Rich Internet Applications) attributes add semantic meaning that HTML alone can’t express. But ARIA is frequently misused, and incorrect ARIA causes more problems than it solves.

The Five Rules of ARIA

1. Don’t use ARIA if you can use a native HTML element. A <button> is always better than <div role="button">. Native elements come with keyboard handling, focus management, and screen reader support built in.
2. Don’t change native semantics. Don’t add role="heading" to a <button>.
3. All interactive ARIA controls must be keyboard operable. If you add role="tab", you must implement arrow key navigation.
4. Don’t use role="presentation" or aria-hidden="true" on focusable elements. This hides the element from assistive technology while leaving it in the tab order — confusing at best, unusable at worst.
5. All interactive elements must have an accessible name. Use aria-label, aria-labelledby, or visible text content.

Common ARIA Patterns

• aria-expanded on buttons that toggle content visibility (accordions, dropdown menus).
• aria-current="page" on navigation links to indicate the current page.
• aria-describedby to associate help text or error messages with form inputs.
• role="alert" for important, time-sensitive messages.
• aria-live regions for content that updates dynamically.

Accessible Component Patterns

Building accessible components doesn’t mean reinventing the wheel. The W3C’s ARIA Authoring Practices Guide (APG) provides tested patterns for common widgets.

Modals / Dialogs

• Focus moves to the modal when it opens.
• Focus is trapped inside the modal (Tab and Shift+Tab cycle through modal content only).
• Escape closes the modal.
• Focus returns to the triggering element when the modal closes.
• Background content is hidden from assistive technology with aria-hidden="true" or the inert attribute.

Tabs

• Tab key moves focus to the active tab. Arrow keys move between tabs.
• Each tab has role="tab", the tab list has role="tablist", and each panel has role="tabpanel".
• aria-selected="true" marks the active tab.
• Each tab panel is associated with its tab via aria-labelledby.

Dropdown Menus

• Button uses aria-expanded and aria-haspopup.
• Menu items are navigated with arrow keys.
• Escape closes the menu and returns focus to the button.
• Type-ahead allows jumping to items by typing the first letter.

Custom Select / Combobox

This is one of the hardest components to build accessibly. If possible, use a native <select> or a well-tested library like Downshift or Headless UI. If building custom, follow the APG combobox pattern exactly.

Mobile Accessibility

Mobile accessibility extends beyond responsive design. Screen reader usage on mobile is significant — VoiceOver on iOS and TalkBack on Android are used by millions.

Key mobile considerations:

• Touch target size. WCAG 2.2 requires 24x24 CSS pixels minimum. Apple’s HIG recommends 44x44 points. Err on the side of larger.
• Gesture alternatives. Any swipe, pinch, or complex gesture must have a single-tap alternative.
• Screen reader testing. Test with VoiceOver (iOS) and TalkBack (Android). The experience often differs significantly from desktop screen readers.
• Orientation support. Don’t lock orientation unless absolutely necessary. Some users mount their devices in a fixed orientation.
• Dynamic type / font scaling. Respect the user’s system font size preferences. Test with large text settings.

Testing Tools and Methodology

No single tool catches all accessibility issues. Effective testing combines automated scanning, manual testing, and assistive technology testing.

Automated Testing Tools

• axe DevTools (browser extension and CI integration). The most comprehensive automated scanner. Catches roughly 30-40% of WCAG issues.
• Lighthouse (built into Chrome DevTools). Good for a quick audit. Runs a subset of axe rules.
• eslint-plugin-jsx-a11y (or framework equivalents). Catches accessibility issues at build time in React, Vue, and Svelte projects.
• Pa11y or axe-core in CI pipelines. Automate accessibility regression testing on every commit.

Manual Testing

• Keyboard-only navigation. Unplug your mouse and try to complete every user flow. This catches more issues than any automated tool.
• Zoom to 200%. Check that no content is lost or overlapping at 200% browser zoom.
• Check focus order. Tab through the page and verify the order is logical.
• Disable CSS. The page should still be readable and navigable without styles.

Assistive Technology Testing

• NVDA (Windows, free). The most widely used screen reader globally.
• VoiceOver (macOS/iOS, built-in). Essential for testing Apple platform accessibility.
• JAWS (Windows, commercial). Dominant in enterprise and government environments.
• TalkBack (Android, built-in). Required for Android app testing.

Test with at least two screen readers. What works in VoiceOver may behave differently in NVDA.

Testing Frequency

Don’t save accessibility testing for the end. Build it into your development workflow:

1. During development: Linting rules and axe in the browser.
2. In CI/CD: Automated scans on every pull request.
3. Before release: Manual keyboard and screen reader testing.
4. Quarterly: Full WCAG audit against the target conformance level.

The Cost of Retrofitting vs. Building Accessible from the Start

This is where the business argument becomes undeniable. Studies consistently show that addressing accessibility during initial development costs 1-5% of total project budget. Retrofitting an inaccessible application costs 10-30x more.

The reasons are structural:

• Inaccessible patterns propagate. A custom dropdown component used in 40 places means fixing it once isn’t enough — you need to update every instance, regression test every page, and verify with assistive technology across the board.
• Architecture constraints. Some accessibility failures require structural changes. If your SPA doesn’t manage focus on route changes, that’s not a CSS fix — it’s a fundamental change to your routing layer.
• Retrofitting delays feature work. The team that could be building revenue-generating features is instead reworking existing functionality.

At Notix, we build accessibility into our development process from the start. Our component libraries include keyboard navigation, ARIA attributes, and screen reader testing as standard — not afterthoughts. This approach costs marginally more upfront but saves significant expense and legal risk down the road.

The Business Case for Accessibility

Beyond legal compliance, accessibility delivers measurable business value.

Market Size

The World Health Organization reports that 1.3 billion people — 16% of the global population — experience significant disability. In the US alone, adults with disabilities control over $490 billion in disposable income. The UK’s “purple pound” (spending power of disabled people and their households) exceeds 274 billion pounds annually.

Inaccessible software doesn’t just exclude people with permanent disabilities. It also excludes users with temporary impairments (broken arm, eye surgery) and situational limitations (bright sunlight, noisy environment, one-handed while holding a child).

SEO Benefits

Accessible websites consistently rank better. The overlap between good accessibility and good SEO is substantial:

• Proper heading hierarchy helps search engines understand content structure.
• Alt text on images provides content that search engines can index.
• Semantic HTML makes crawling more efficient.
• Transcripts and captions for video add indexable text content.
• Descriptive link text improves both screen reader experience and link value.

Reduced Legal Risk

ADA-related web accessibility lawsuits cost defendants an average of $50,000-$100,000 in settlements, plus legal fees. For serial plaintiffs targeting multiple companies, the cost to the business ecosystem runs into billions annually. Proactive compliance is an order of magnitude cheaper than reactive litigation.

Improved Usability for Everyone

Curb cuts were designed for wheelchair users but are used by everyone — cyclists, parents with strollers, delivery workers with hand trucks. The same principle applies to software. Keyboard navigation helps power users. Captions help everyone in a noisy office. Clear focus indicators help users on any device. Good contrast helps users on old monitors or in bright light.

Accessibility improvements make software better for all users, not just the subset who need them most.

Getting Started: A Practical Roadmap

If your existing application has accessibility gaps, here’s a pragmatic approach to closing them:

1. Audit first. Run an automated scan with axe and perform a manual keyboard test on your highest-traffic pages. This gives you a baseline and a prioritized list.
2. Fix the high-impact items. Color contrast, missing alt text, form labels, and keyboard navigation cover the majority of user-facing issues.
3. Update your component library. Fix accessibility at the component level and it propagates everywhere the component is used.
4. Add automated testing to CI. Prevent regression. Every new feature should pass accessibility checks before merge.
5. Train your team. Developers, designers, and QA all need baseline accessibility knowledge. A one-day workshop pays dividends for years.
6. Test with real users. No amount of automated testing replaces feedback from people who use assistive technology daily.

Accessibility is not a project with a finish line. It’s a practice — like security or performance — that requires ongoing attention. The organizations that build it into their culture ship better software for everyone.