Accessibility is not a feature you add at the end. It is a fundamental quality of well built software. Despite this, we regularly encounter applications, some handling millions of users, that fail basic accessibility checks. Buttons without labels, images without alt text, forms that cannot be completed with a keyboard, color contrast ratios that make text invisible to anyone with low vision.

The Web Content Accessibility Guidelines (WCAG) provide a clear, testable standard for what accessible software looks like. Most organizations that need to comply are targeting WCAG 2.1 Level AA, which is the standard required by Section 508 (federal government), the ADA (for private businesses in the US), the European Accessibility Act, and an increasing number of state laws.

This post is a practical guide for development teams. Not a legal overview, not a theoretical framework, but a concrete walkthrough of what AA compliance requires and how to build it into your workflow.

The Four Principles of WCAG

WCAG is built on four principles, abbreviated as POUR. Every guideline maps back to one of these.

Perceivable: Information and interface components must be presentable in ways users can perceive. This covers text alternatives for non text content, captions for video, sufficient color contrast, and the ability to resize text without breaking the layout.

Operable: Interface components and navigation must be operable. Users must be able to use the interface with a keyboard alone, have enough time to read and interact with content, and the interface must not cause seizures or physical reactions.

Understandable: Information and the operation of the interface must be understandable. Text must be readable, the interface must behave in predictable ways, and users must receive help avoiding and correcting errors.

Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This primarily means using proper semantic HTML and following established web standards.

The Most Common Accessibility Failures

After auditing dozens of web applications, we have found that the same failures come up repeatedly. Fixing these 10 issues resolves the majority of accessibility problems.

1. Missing or inadequate alt text on images. Every meaningful image needs a descriptive alt attribute. Decorative images should use an empty alt attribute (alt="") so screen readers skip them. The alt text should describe the function or content of the image, not just "image" or "photo."

2. Insufficient color contrast. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). We see this violated constantly with light gray text on white backgrounds, or colored text on colored backgrounds. Tools like the WebAIM Contrast Checker make this trivial to verify.

3. Forms without proper labels. Every form input must have a programmatically associated label element. Placeholder text is not a label. Screen readers cannot consistently read placeholder text, and it disappears once the user starts typing. Use a visible `` element with a matching `for` attribute.

4. Missing keyboard navigation. Every interactive element must be reachable and operable with the keyboard alone. This means `Tab` to move between elements, `Enter` or `Space` to activate buttons, arrow keys for menus, and `Escape` to close modals. Custom components like dropdowns, date pickers, and carousels are the most frequent offenders.

5. Focus indicators removed or hidden. CSS resets that include `outline: none` on interactive elements break keyboard navigation. Users need to see where focus is. If you replace the default outline, replace it with a visible alternative that meets contrast requirements.

6. Dynamic content not announced. When content changes on the page, like a form validation error appearing, a notification popping up, or search results loading, screen readers must be informed. Use ARIA live regions (`aria-live="polite"` or `aria-live="assertive"`) to announce changes.

7. Missing page structure and headings. Screen reader users navigate by headings. Your pages need a logical heading hierarchy: one `

` per page, followed by `

` sections, `

` subsections, and so on. Do not skip heading levels. Do not use headings for visual styling alone.

8. Links and buttons without descriptive text. "Click here" and "Read more" tell a screen reader user nothing about where the link goes. Every link should make sense out of context. Instead of "Click here to view pricing," use "View our pricing plans."

9. Missing language attributes. The `` element needs a `lang` attribute (e.g., `lang="en"`) so screen readers use the correct pronunciation. If sections of the page are in a different language, those sections need their own `lang` attribute.

10. Inaccessible modals and dialogs. When a modal opens, focus must move to the modal. While the modal is open, `Tab` should cycle only within the modal (focus trapping). When the modal closes, focus must return to the element that triggered it. Most modal implementations get at least one of these wrong.

Building Accessibility Into Your Development Process

Retrofitting accessibility is expensive. In our experience, fixing accessibility after a build is complete costs 3 to 5 times more than building it in from the start. Here is how we approach it on projects we ship.

Use semantic HTML first. Native HTML elements like ``, `` is keyboard focusable, activatable with Enter and Space, and announced as a button by screen readers. A `

` is none of these things without significant extra work.

Add ARIA only when HTML is not enough. ARIA (Accessible Rich Internet Applications) attributes fill gaps where native HTML does not cover complex interactions like tabs, accordions, tree views, and drag and drop. The first rule of ARIA is: do not use ARIA if native HTML can do the job. Misused ARIA is worse than no ARIA at all.

Automate what you can. Tools like axe core, Lighthouse, and pa11y catch approximately 30 to 40% of accessibility issues automatically. Integrate these into your CI/CD pipeline so every pull request is checked. This catches regressions and obvious violations before they reach production. We covered CI/CD best practices in our post on zero downtime deployments.

Manual testing is non negotiable. Automated tools cannot test the user experience. You must manually test with a keyboard (can you complete every task without a mouse?), with a screen reader (does the content make sense when read aloud?), and at different zoom levels (does the layout hold at 200% zoom?). VoiceOver on Mac, NVDA on Windows, and TalkBack on Android are free and cover the major platforms.

Include accessibility in your design system. If you are using a component library or design system, bake accessibility into every component. Buttons, inputs, modals, tooltips, and menus should be accessible by default. This way, developers building features cannot accidentally create inaccessible interfaces because the building blocks are already correct.

The Legal and Business Case

Accessibility lawsuits have increased by over 300% since 2018 in the United States. Plaintiffs do not need to prove harm. They need to show that your application is not accessible. The ADA applies to most businesses operating online, and courts have consistently ruled that websites and applications are places of public accommodation.

Beyond the legal risk, accessible applications reach more users. Approximately 15% of the global population has some form of disability. Many accessibility improvements, like clear navigation, readable text, and keyboard support, improve the experience for all users. Captions help users in noisy environments. High contrast benefits users in bright sunlight. Keyboard navigation helps power users move faster.

Building web and mobile applications with accessibility from the start is not just about compliance. It is about building better software that works for everyone. Compared to trying to build it yourself or using a no code tool, working with a team that understands accessibility standards means you do not discover compliance gaps after launch.

Getting Started

If you have an existing application that has never been audited, start with an automated scan using axe DevTools or Lighthouse. Fix the critical and serious issues first, as these are the violations that completely block users from completing tasks. Then move to manual testing of your core user flows with a keyboard and screen reader.

If you are starting a new project, define accessibility requirements in your technical requirements document alongside functional requirements. Choose a component library with strong accessibility support. Set up automated accessibility testing in your CI pipeline from day one.

If you need help building an accessible application or bringing an existing one into compliance, get in touch with us. We build to WCAG AA by default on every project we deliver.