WCAG 2.1 AA is the most widely referenced accessibility standard and the benchmark for legal compliance in most jurisdictions. Meeting it means your site works for people using screen readers, keyboard navigation, and assistive technologies. This guide breaks down what matters most and where to start.
The four principles
WCAG is organised around four principles: Perceivable, Operable, Understandable, and Robust. Perceivable means all content can be presented in ways users can sense — through sight, hearing, or touch. Operable means all functionality is available via keyboard and other input methods. Understandable means content and interface behaviour are predictable and legible. Robust means content works across current and future assistive technologies.
Each principle contains guidelines, and each guideline contains success criteria rated A, AA, or AAA. AA is the standard most organisations target because it represents a practical balance between accessibility and implementation effort.
The highest-impact changes
Not all WCAG criteria carry equal weight in practice. Some affect large user groups or block access entirely, while others address edge cases. Here are the changes that make the biggest difference.
Colour contrast
Body text needs a contrast ratio of at least 4.5:1 against its background. Large text (18px bold or 24px regular) needs 3:1. This is the single most common failure and the easiest to fix. Use a contrast checker to validate your colour combinations, paying special attention to text on images, gradients, or coloured backgrounds.
Alt text for images
Every informational image needs a text alternative that conveys its purpose. Decorative images should have empty alt attributes (alt="") so screen readers skip them. The most common mistake is using file names as alt text or writing generic descriptions like "image" or "photo." Good alt text describes what the image communicates in context — "Revenue growth chart showing 40 percent increase in Q3" is useful; "chart.png" is not.
Keyboard navigation
Every interactive element — links, buttons, form fields, menus, modals — must be reachable and operable using only a keyboard. This means logical tab order, visible focus indicators, and no keyboard traps where the user cannot tab away from an element. Test by unplugging your mouse and navigating your entire site with Tab, Shift+Tab, Enter, and Escape.
Form labels and errors
Every form input needs a programmatically associated label — not just placeholder text, which disappears when the user starts typing. Error messages should identify which field has the problem and what the user needs to do to fix it. Avoid relying on colour alone to indicate errors; add text or an icon as well.
Heading hierarchy
Headings should follow a logical order: one H1 per page, followed by H2s for major sections, H3s for subsections, and so on. Screen reader users navigate by heading level, so skipping from H1 to H4 or using headings purely for visual styling creates a confusing experience.
Cognitive accessibility
WCAG 2.1 introduced several criteria focused on cognitive accessibility, recognising that accessibility is not only about sensory or motor impairments. These include providing purpose for each input field, ensuring content does not require complex gestures, and allowing users to undo or confirm important actions.
Beyond the formal criteria, cognitive accessibility means writing in plain language, keeping layouts predictable, avoiding auto-playing media, and giving users enough time to complete tasks. These improvements benefit everyone, not just users with cognitive differences.
How Fixpath checks accessibility
The Inclusive Design module runs automated WCAG checks across your entire site. It flags violations by severity: critical issues like missing form labels or inaccessible navigation are prioritised over advisory items like suboptimal link text. Each finding links directly to the relevant WCAG success criterion so you can understand the requirement, read the official guidance, and verify your fix.
Automated tools catch roughly 30 to 50 percent of accessibility issues. The rest require manual testing — navigating with a keyboard, testing with a screen reader, and checking content comprehension. Fixpath identifies the automated findings; the manual checks are noted as recommendations where relevant.
Building an accessibility practice
Accessibility is not a one-time project. Every new feature, page, or design change can introduce regressions. The most effective approach is to integrate accessibility into your existing workflow: include it in design reviews, add automated checks to your CI pipeline, and re-audit regularly with Fixpath to catch issues before they reach production.
Want to see these checks applied to your site?
Start your free audit →