Website accessibility standards: Build a program that sticks

Enterprise websites win when web accessibility is a product requirement, not a retrofit. Treat accessibility backed by WCAG as a growth, risk, and UX engine across the stack.

That means weaving regulatory context, such as the Americans with Disabilities Act (ADA) and Section 508, WCAG 2.1/2.2 success criteria, testing protocols, mobile patterns, and implementation workflows, into a program your team can run without the usual scramble when Legal forwards another accessibility email.

Here’s what you’ll learn to do in this article:

• Map legal requirements and standards to business outcomes (e.g., revenue reach, reduced rework, and faster delivery).
• Translate WCAG 2.1 priorities into design and dev decisions that ship on time.
• Build testing, triage, and maintenance systems that scale with your release cadence.
• Guide mobile experiences to match desktop accessibility across touch, gestures, and screen readers.

First, let’s define WCAG and its role.

The WCAG standards

WCAG 2.1 sets the baseline for accessible UX, aligning design with legal expectations and measurable, testable success criteria.

Here’s what that looks like in practice: When your team builds to WCAG 2.1 Level AA — a common, testable benchmark used in many policies, procurement standards, and accessibility programs — you’re doing two things at once. You’re aligning with widely used accessibility criteria and creating experiences that work for people using screen readers, keyboard navigation, voice control, and other assistive technologies. The success criteria are specific enough to test (e.g., does this component meet non-text contrast for key boundaries and indicators? Does button text meet text-contrast requirements? Can someone tab through this form without a mouse?) and flexible enough to work across platforms.

The WCAG guidelines originated from the Web Accessibility Initiative, a W3C effort to make the web work for everyone regardless of disability. Understanding this foundation helps teams grasp why each accessibility standard exists and how they connect to real user needs.

Conformance levels decoded

WCAG organizes its success criteria into three tiers, and each one builds on the previous tier:

• Level A covers the baseline. Skip these, and chunks of your site become completely unusable for people with disabilities. We’re talking basics: alt text for images (with decorative images handled appropriately), captions for videos, and keyboard access to interactive elements. Miss Level A and you’re not even in the game.
  
  
• Level AA is where most organizations land. It’s a common benchmark used in many audits, internal policies, and procurement requirements, and it often appears in remediation targets. AA adds stronger color contrast (4.5:1 for normal-size text), visible focus indicators, and a requirement that text can be resized up to 200 percent without loss of content or functionality.
  
  
• Level AAA takes things further with 7:1 contrast, sign language interpretation for video, and enhanced readability standards. But here’s the thing: almost nobody aims for AAA site-wide because some criteria genuinely don’t fit every context. Instead, smart teams apply AAA selectively to high-stakes moments, such as checkout or account creation.

These levels aren’t abstract. They translate directly into what designers and developers do every day. Is your designer picking the brand colors? They need to know that AA requires a contrast ratio of 4.5:1 for body text. Is your front-end dev building a custom dropdown? Keyboard users need to open it, navigate options, and select without ever touching a mouse.

What changed in WCAG 2.1 (and why mobile teams should care)

WCAG 2.0 launched in 2008, when the mobile web was barely a consideration. By 2018, WCAG 2.1 added 17 new success criteria focused squarely on mobile, low vision, and cognitive accessibility.

The following additions change how you build:

• Orientation (1.3.4) means your content works in both portrait and landscape modes. No forcing users to rotate their phones unless the orientation is genuinely essential (think of a mobile banking check deposit feature that needs landscape to capture the full check).
• Reflow (1.4.10) requires content to adapt to narrow viewports without horizontal scrolling at 320 CSS pixels. This helps people who zoom right in, but it also makes mobile experiences less annoying.
• Touch targets (2.5.8) WCAG 2.2 has a Level AA target-size requirement and WCAG also has a stricter Level AAA one (2.5.5 Target Size (Enhanced), 44×44 CSS px with exceptions)
• Input modalities (2.5.1–2.5.4) mean users complete tasks via touch, stylus, voice, or switch controls. You know that shake-to-undo gesture? You’d better have an alternative, because not everyone can shake their device.
• Contrast for UI components (1.4.11) extends beyond text. Buttons, form fields, and focus indicators all need 3:1 contrast against adjacent colors so people with low vision can find them.

If your team’s still working from WCAG 2.0 assumptions, these mobile and low-vision criteria are usually where audits surface problems. The new standards improve the experience for everyone, making it much easier to sell the work to leadership.

Accessibility governance and ROI

Treat accessibility as a governed operating discipline, not a legal fire drill. The same controls that reduce exposure also cut rework, speed delivery, and expand revenue reach.

I’ve seen too many companies treat accessibility like a surprise pop quiz. Legal forwards a demand letter, everyone panics, teams bolt on fixes three days before a deadline, and six months later, the same problems are back. Organizations juggling both ADA and WCAG compliance need systems that run continuously, not crisis management that kicks in when web accessibility laws or the ADA suddenly become urgent. There’s a better way, and it starts with running accessibility like you’d run security or performance, with clear ownership, baked-in controls, and metrics that matter.

Build governance that runs itself

Good governance doesn’t mean more meetings. It means fewer surprises.

Start with an executive sponsor who co-owns the program with Legal and Compliance. This matters because accessibility spans Product, Design, Engineering, and QA. It needs someone with budget authority who can make trade-off decisions when deadlines collide with accessibility debt.

Then clearly define who is responsible, accountable, consulted, and informed across teams. Product owns acceptance criteria and prioritization. DesignOps maintains the design system. Engineering implements and tests. QA validates before release. When everyone knows their functions, you stop getting the “I thought someone else was handling that” problem.

Now for the controls that prevent bad code from shipping:

• Design system tokens enforce accessible color combinations, type scales, and spacing from the start. Your designers literally can’t pick a color combo that fails contrast without a warning.
• Semantic HTML and ARIA linting catch mistakes during code review. Precommit hooks or CI checks can flag missing alt text, broken heading hierarchies, or ARIA abuse before the pull request (PR) even lands.
• Automated accessibility checks run premerge. While they scan every build, automated accessibility checks won't catch every WCAG issue. Combine automation with manual and assistive-technology testing, especially for critical user flows.
• Manual and assistive technology sweeps on high-risk flows, such as checkout, account creation, and form submissions. Have someone use a keyboard to tab through. Fire up NVDA or VoiceOver and listen to what a screen reader announces. You’ll find problems automation misses.
• Stop-the-line authority for Sev-1 failures. If someone discovers a keyboard trap or a form that’s completely unusable with assistive tech, they can block the release. Sounds dramatic, but it’s way cheaper than retrofitting after launch.

Don’t forget vendor management. Build accessibility requirements into your RFPs. Require SLAs for third-party components. Request Accessibility Conformance Reports (ACRs) or Voluntary Product Accessibility Templates (VPATs) annually. Your content management system, chat widget, or analytics platform can drop your accessibility score if you’re not paying attention.

Track KPIs that connect to revenue

Accessibility metrics fall into three buckets, and only the third one gets executive attention:

• Practice quality shows how well you’re building. Track the percentage of design system components that meet WCAG 2.1 AA. Measure how many PRs pass accessibility gates without rework. Monitor assistive technology coverage across your top user tasks. These metrics show whether your process is working.
• Risk and reliability metrics catch problems before they become lawsuits. Measure your Sev-1 and Sev-2 accessibility defect rates. Track mean time to resolution (MTTR) for accessibility bugs. Monitor the percentage of your third-party UI components with current accessibility attestations. Rising defect rates or slow MTTR? These mean that your controls are slipping.
• Business impact is where you prove ROI. Measure task completion rates for keyboard and screen-reader users separately from your general population. Track conversion lift on flows you’ve remediated. We’ve seen checkout conversion jump from eight to 12 percent after fixing keyboard navigation and focus management. Monitor RFP pass-through rates; accessibility compliance increasingly determines whether you even get to compete for enterprise deals.

That last point matters more than most procurement teams realize. Ask for accessibility documentation upfront. If you can’t produce ACRs/VPATs (or equivalent evidence) that address the required standard for that buyer (often Section 508 or a WCAG Level AA target), you can lose eligibility or score poorly before the technical evaluation even starts.

To keep this from becoming a spreadsheet exercise, many teams centralize trend reporting and evidence tracking in one place (for example, Siteimprove.ai) so leaders can see accessibility risk, component coverage, and open critical issues without having to chase updates across tools.

Budget predictably, not reactively

Most companies spend three to 10 times more fixing accessibility later than they would by building it in from the start. Here’s how to avoid that:

• Quarterly program reviews keep accessibility on the agenda, not in the “we’ll get to it later” backlog. Tie them to release sign-offs so Product can’t ship unless accessibility acceptance criteria are met.
• Annual evidence packs, your ACR or VPAT, a change log showing what’s improved, and testing reports, are assembled, whether you need them or not. When Procurement, an auditor, or Legal asks for documentation, you can hand them a folder instead of scrambling for weeks.
• Budget one to two percent upfront for design system patterns, team training, and CI/CD gates. That investment prevents expensive firefights later. Compare that to the cost of pulling developers off strategic work to retrofit a revenue-critical flow three days before launch because no one considered keyboard navigation.

For executive visibility, build a weekly risk indicator that combines three signals: WCAG 2.1 AA coverage on top user tasks, aging of open Sev-1 accessibility issues, and vendor ACR status. It’s one number, updated automatically, that shows whether your accessibility program is healthy or sliding.

When you run accessibility as a discipline, not a project with a start and end date, you stop reacting to crises and start preventing them.

Inclusive design and its benefits

Inclusive design expands reach, improves UX, and converts more users by addressing diverse needs from the start.

Think of inclusive design as solving for the edges first, knowing the center benefits automatically. When you design captions for deaf users, you also help people watching videos on mute in open offices (which is most mobile users). When you verify that color isn’t the only way you convey information, you help colorblind users and anyone viewing your site in bright sunlight, where contrast drops.

The business case writes itself. Removing accessibility barriers doesn’t just help users with disabilities; it also improves the experience for everyone navigating your digital content. Captions improve video SEO because search engines can index the text. Keyboard-navigable interfaces load faster because they’re built with semantic HTML instead of JavaScript-heavy custom components. Clear error messages with specific fixes reduce support tickets. One financial services client reduced form abandonment support calls by 40 percent after rewriting vague error statements, such as “invalid entry” to “routing number must be nine digits.”

Inclusive design also means better performance. Accessible sites tend to be lighter because they rely on native HTML controls instead of reinventing buttons and dropdowns with bloated JavaScript. Faster load times improve conversions across the board, not just for users relying on assistive tech.

When you design for diverse abilities from the start, you create experiences that more people can use.

Accessibility testing and tools

Rigorous, recurring testing validates compliance, surfaces defects early, and sustains accessible experiences at scale.

But no single tool catches everything. Automated scanners can find many WCAG issues, for example, in mechanical elements such as missing alt text or broken ARIA attributes. The rest? That requires human judgment and testing with assistive technology.

This means you need both automated checks running in CI and manual sweeps from people who know what they’re looking for.

Here’s how the most common tools stack up:

Common accessibility testing tools and use cases

Tool type	What it catches	CI integration	Best for
axe DevTools	Color contrast, ARIA, and semantic HTML	Chrome extension + axe-core API	Quick spot checks during dev
Pa11y	Automated WCAG checks via CLI	Easily runs in CI pipeline	Premerge gate checks
WAVE	Visual feedback on page structure	Browser extension only	Designer/content reviews
Lighthouse	Accessibility + performance + SEO	Built into Chrome DevTools	Baseline audits
NVDA / JAWS	Screen reader compatibility	Manual testing only	High-risk flow validation
Keyboard testing	Focus management and tab order	Manual testing only	Every interactive element

Platform note: If you need ongoing governance (e.g., dashboards, issue tracking, policy evidence, and continuous monitoring) alongside point-in-time testing tools, platforms such as Siteimprove.ai can complement scanners by helping teams prioritize issues, track progress over time, and report on program KPIs.

A testing plan that works is to run automated scans on every PR. Manual keyboard navigation and screen reader sweeps should be run on high-risk flows before release. Think of checkout, registration, or any process involving forms or multistep workflows. Then bring in users who rely on assistive tech for validation quarterly or after major UI overhauls.

But regression testing is where most teams fall apart. Accessibility debt compounds faster than you’d think. One release adds a modal that traps keyboard focus. The next release breaks the fix. Three months later, you’re drowning in defects nobody prioritized.

Set actual SLAs. Sev-1 issues that block releases, such as keyboard traps and forms that don’t work with screen readers. Sev-2 will get fixed within the current sprint. Sev-3 will compete with other tech debt in backlog grooming. Without SLAs, accessibility fixes get deprioritized every single time a shiny new feature shows up on the road map.

Mobile accessibility challenges and solutions

Mobile accessibility demands touch-friendly, responsive, robust patterns to guide parity across devices and contexts.

Mobile brings problems that desktops never have. Someone’s navigating one-handed on a bus. Another person uses voice control because their hands shake. Someone mounted their tablet to a wheelchair and can’t rotate it.

The barriers are predictable. Touch targets that shrink to 32 pixels to save screen space (good luck tapping that accurately with arthritis or just average thumbs). Focus traps can lock the keyboard and switch control users inside modals, with no escape except to close the browser. Gesture-only controls (swipe to delete, pinch to zoom) exclude anyone who can’t perform those motions. Dynamic content loading on scroll? Screen readers miss it unless you’re managing focus properly.

Here’s what fixes the most common problems:

Common mobile accessibility barriers and solutions

Mobile barrier	What goes wrong	Solution
Small touch targets	Buttons under 44×44px are hard to tap	Use 44×44 CSS pixels minimum; add padding, not just visual size
Focus traps	Can’t escape modals with keyboard/switch	Trap focus inside while open, return it on close
Gesture-only controls	Swipe/pinch excludes voice and switch users	Add button alternatives for every gesture
Locked orientation	Portrait/landscape-only breaks mounter devices	Support both unless truly essential
Dynamic content	Screen readers miss loaded content	Use ARIA live regions; manage focus
Tiny text	Fixed sizes break at zoom	Use relative units; test at 200% zoom

Both Apple and Android publish platform accessibility guidelines that address web accessibility standards for mobile apps. They cover the same ground as WCAG but in platform-native terms. Follow these guidelines to improve native usability and assistive technology support, and validate against the WCAG success criteria (and any applicable regulations) to determine whether you meet your organization’s accessibility requirements.

Hybrid web apps and mobile app experiences get complicated fast. VoiceOver and TalkBack behave completely differently, with different gestures, announcements, and expectations. Test with both. Your users will notice immediately if your web view feels clunky compared with native apps. When your mobile app incorporates web pages or web content, those same web accessibility laws apply just as they would to your desktop site.

Implement accessibility in web development

Accessibility works when it’s built into your workflow from the start and not bolted on three days before launch.

Picture this: QA discovers that your new checkout flow traps keyboard users in the shipping address modal. Launch is in three days. Developers are already working on the next sprint. Product is furious about the timeline impact. Everyone agrees to circle back next quarter. (They did not circle back.)

There’s a fix, and it starts much earlier in your development process. When accessibility is built into your Definition of Done, code review checklists, and design system components, problems get caught while they’re still easy (and cheap) to fix.

Make accessibility part of the Definition of Done

Every user story needs acceptance criteria for keyboard navigation, screen reader compatibility, and WCAG conformance. If someone can’t complete the feature using only a keyboard, it’s not done. Focus management broken? Not done. These aren’t nice-to-haves for later; they’re requirements for shipping.

Enforce accessibility in code reviews

Your review checklist should include:

• Semantic HTML over divs with click handlers? (Use button elements because they come with keyboard behavior built in.)
• Logical tab order through interactive elements?
• ARIA used minimally and correctly? (Reach for ARIA only when semantic HTML can’t solve it.)
• Color contrast meeting 4.5:1 for text and 3:1 for UI components?

Practice ARIA discipline

ARIA fills gaps that semantic HTML can’t cover, announces dynamic content, manages complex widget states, and hides decorative clutter. But overuse makes experiences worse. An incorrect role or aria-label confuses screen readers instead of helping them. When in doubt, use semantic HTML first and ARIA only when necessary.

Build accessibility into your design system

Create a component library with accessibility baked in from the start:

• Buttons with visible focus states
• Form inputs with properly associated labels
• Modals that trap and manage focus correctly
• Dropdown menus with full keyboard support

Document keyboard interactions and screen reader behavior for each component. When developers grab a prebuilt accessible component instead of building it from scratch, bugs drop and consistency improves automatically.

Use tokens to prevent accessibility failures

Define accessible color combinations, type scales, and spacing in your design system. Designers work within guardrails that prevent contrast failures before they happen. Developers inherit those tokens and literally can’t create inaccessible pairings without going off system (which code review should catch).

Align everything with the WCAG 2.1 AA web accessibility standard and document why. Your design system should explain which criteria each component meets and how to use it without compromising accessibility. When accessibility is the default path, it stops being extra work.

Build a program that outlasts compliance deadlines

WCAG 2.1 AA gives you a foundation that holds up when regulations shift or your procurement team suddenly needs accessibility documentation for an RFP due Friday. You’re not scrambling to catch up every time a new lawsuit makes headlines or accessibility laws evolve.

Pick one high-traffic flow and fix it properly. Maybe that’s your checkout process where keyboard users currently get stuck. Or your demo request form that screen readers can’t parse. Fix it, then measure what changes. Did task completion jump? Did support tickets drop? When you can walk into a budget meeting and say, “We lifted conversions 12 percent by fixing keyboard navigation,” you’re speaking a language executives care about.

But nobody wants to hear that you’re done. Your design system needs updates. New developers join who have never thought about focus management. That chat widget vendor you love. Their latest update just broke your accessibility score. So Product, Design, Engineering, QA, and Legal all need to take responsibility, or you’re just one person trying to catch every problem before it ships (which, let’s be honest, never works).

Want to see how teams operationalize this day-to-day governance, QA gates, and ongoing monitoring, without becoming the accessibility police? Request a demo and discover how many organizations use platforms such as Siteimprove.ai alongside other tools to maintain consistent standards, workflows, and reporting as their sites evolve.

This content is for informational purposes only and does not constitute legal advice. WCAG is a technical standard; legal obligations vary by jurisdiction and context. Consult qualified counsel for legal guidance.