WCAG for Enterprise Developers (The Practical Version)

I've read the WCAG 2.1 specification cover to cover twice. The first time took me a week and I retained maybe 10% of it. It's written for auditors and policy people, not for developers trying to ship a portal that 500 staff will use every morning. The second time, I went through it with a highlighter and pulled out the things that actually matter when you're building enterprise software. That's what this guide is.

What You Need to Know

WCAG has 78 success criteria across three conformance levels (A, AA, AAA). Most enterprise contracts require AA
About 15 of those 78 criteria cover the vast majority of real-world accessibility issues in enterprise web apps
Keyboard navigation, colour contrast, form labels, and screen reader structure get you 80% of the way
Automated tools catch roughly 30% of issues. The rest needs manual testing and structural thinking

Why Enterprise Developers Should Care

This isn't about building software for "accessibility users." It's about building software that works.

Enterprise applications get used eight hours a day by people who didn't choose to use them. They're mandated tools. Payroll systems, case management platforms, internal portals. If the software is hard to use, people can't opt out. They just suffer through it, or they find workarounds that create data quality problems downstream.

Good accessibility constraints produce better software for everyone. Clear focus states mean power users can navigate faster with keyboards. Proper heading structure means the interface is scannable. Sufficient colour contrast means the application works in a sunny office with screen glare. These aren't niche concerns.

The 20% That Covers 80%

Every interactive element needs to be reachable and operable with a keyboard alone. Tab moves forward. Shift+Tab moves backward. Enter or Space activates. Escape closes. Arrow keys navigate within components like tabs, menus, and radio groups.

The most common failure: custom components that only respond to mouse clicks. A dropdown menu built with div and onClick that has no keyboard handler. A modal that opens but can't be closed with Escape. A custom date picker that requires mouse interaction to select a date.

The fix is straightforward. Use semantic HTML elements where possible. A button element gets keyboard interaction for free. An a element gets focus for free. When you build custom components, add tabIndex, onKeyDown, and manage focus deliberately.

// Don't do this
<div className="button" onClick={handleClick}>Submit</div>

// Do this
<button type="button" onClick={handleClick}>Submit</button>

// If you must use a div, make it accessible
<div role="button" tabIndex={0}
  onClick={handleClick}
  onKeyDown={(e) => {
    if (e.key === 'Enter' || e.key === ' ') handleClick()
  }}>
  Submit
</div>

Focus management matters most in modals and drawers. When a modal opens, focus should move into it. When it closes, focus should return to the trigger element. Without this, keyboard users get lost in the page.

2. Colour Contrast

WCAG AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). That sounds technical. In practice, it means don't put light grey text on a white background.

Enterprise dashboards are the worst offenders. Grey text on light grey cards. Low-contrast status badges. Subtle borders that disappear on certain monitors. These choices look refined in a design tool on a high-end display. They fall apart on the cheap monitors most office workers use, under fluorescent lighting, at 3pm when everyone's eyes are tired.

Test with the Chrome DevTools contrast checker. Inspect any text element, look at the colour picker, and it shows the contrast ratio with a pass/fail indicator. Do this for your body text, your secondary text, your labels, and your placeholder text. Placeholder text is almost always too low contrast.

3. Form Labels and Error Messages

Every form input needs a visible label. Not a placeholder, a label. Placeholders disappear when you start typing, which means users can't check what field they're filling in. For enterprise forms with 15+ fields, this is a real problem.

<!-- Don't do this -->
<input placeholder="Email address" />

<!-- Do this -->
<label htmlFor="email">Email address</label>
<input id="email" type="email" />

Error messages need to be associated with their inputs using aria-describedby. Screen readers announce the error when the user focuses the field, so they know what to fix without visually scanning the page.

Group related fields with fieldset and legend. A set of radio buttons for "Application Status" should be wrapped in a fieldset so screen readers announce the group context.

Screen reader users navigate by headings, landmarks, and link text. If your page has no heading hierarchy, they're listening to every element linearly, which is like reading a book with no chapters.

Heading hierarchy must be sequential. H1, then H2, then H3. Don't skip from H1 to H4 because you liked the font size. Use CSS for visual styling, HTML for structure.

Landmarks tell screen readers about page regions. Use main, nav, aside, header, and footer elements. In a typical enterprise layout with a sidebar, header, and content area, these landmarks let screen reader users jump directly to the content without tabbing through 40 navigation items.

Link text must make sense out of context. "Click here" and "Read more" are meaningless when a screen reader lists all links on the page. "View Q3 financial report" tells the user exactly where the link goes.

5. Focus Visibility

When a user tabs through your interface, they need to see where they are. The browser provides a default focus ring, but many design systems remove it for aesthetic reasons and forget to replace it.

Every focusable element needs a visible focus indicator. The WCAG 2.2 specification is stricter about this than 2.1, requiring a minimum contrast and area for focus indicators. If you're building a design system, get focus styles right once at the component level and every instance inherits them.

97.8%

of homepages had detectable WCAG failures in 2019

Source: WebAIM Million Report, 2019

What Automated Tools Miss

Tools like axe, WAVE, and Lighthouse are useful. Run them. But they only check things that can be evaluated by reading the DOM. They can tell you that an image is missing alt text. They can't tell you that the alt text you wrote is unhelpful.

They can detect that a contrast ratio is below 4.5:1. They can't detect that your keyboard focus order makes no logical sense, or that your modal traps focus and the user can't escape.

The things automated tools miss are often the things that matter most:

Logical tab order through complex layouts
Whether ARIA labels actually describe the element
Whether focus management in dynamic content works correctly
Whether the page makes sense when read linearly by a screen reader

Manual testing fills this gap. Tab through your application without touching the mouse. Turn on VoiceOver (Mac) or NVDA (Windows) and try to complete a common task. You'll find issues in the first five minutes that no scanner would catch.

Getting Started Without Getting Overwhelmed

Don't audit your entire application at once. Pick the three workflows your users complete most often and test those. Log in, complete primary task, find a specific record. Make those three paths fully accessible and you've covered the majority of user interaction.

Build accessibility into your component library, not your pages. A properly accessible button component means every button in the application is accessible by default. Fix it once at the foundation and it radiates outward.

If your team builds enterprise software used by hundreds of people daily, this isn't optional work. It's engineering quality. The same discipline that makes you write tests and review code should extend to making sure everyone can actually use what you've built.