Accessibility Is a Business Decision, Not Just Compliance
Roughly one in six people lives with some form of disability. When your product is hard to use with a keyboard, a screen reader, or low vision, you are quietly turning away customers, and increasingly inviting legal risk. Accessibility lawsuits against websites rise every year, and procurement teams now routinely demand a VPAT before signing.
The good news: the same work that makes a product usable for people with disabilities makes it faster, clearer, and more robust for everyone. Captions help in noisy rooms. High contrast helps in bright sunlight. Keyboard support helps power users.
The Four Principles: POUR
WCAG is organised around four ideas. Content must be:
- Perceivable, users can perceive it (text alternatives, contrast, captions).
- Operable, users can operate it (keyboard access, enough time, no seizure triggers).
- Understandable, content and operation are predictable and clear.
- Robust, it works across browsers, devices, and assistive technologies.
Most teams aim for WCAG 2.2 Level AA, the standard referenced by most regulations.
What WCAG 2.2 Added
WCAG 2.2 introduced several success criteria worth knowing:
- Focus Appearance and Focus Not Obscured, the keyboard focus indicator must be visible and not hidden behind sticky headers.
- Target Size (Minimum), interactive targets should be at least 24 by 24 CSS pixels.
- Dragging Movements, any drag action needs a single-pointer alternative.
- Accessible Authentication, do not force users to solve puzzles or memorise things to log in.
The High-Impact Fixes
You do not need to memorise all 80-plus criteria to make real progress. Start here:
| Common issue | Practical fix |
|---|---|
| Div soup with click handlers | Use real semantic HTML, button, a, nav, main |
| Images with no description | Meaningful alt text; empty alt for decorative images |
| Low contrast text | Meet 4.5:1 for body text, 3:1 for large text |
| Keyboard traps | Ensure every interaction works with Tab, Enter, and Escape |
| Invisible focus | Never remove outline without replacing it visibly |
| Unlabelled form fields | Associate every input with a label element |
Reach for ARIA only when native HTML cannot express the pattern. The first rule of ARIA is: do not use ARIA if a native element already does the job.
Semantic HTML is accessibility's biggest free win. A native button is focusable, clickable, keyboard-operable, and announced correctly, all without a line of extra code.
Testing: Automated Plus Manual
Automated tools catch roughly a third of issues. They are necessary but never sufficient.
- Automated: run axe DevTools or Lighthouse in CI to catch contrast, missing labels, and ARIA misuse.
- Keyboard only: unplug the mouse and navigate the whole flow with Tab, Shift+Tab, Enter, and Escape.
- Screen reader: test with VoiceOver on macOS or NVDA on Windows on your critical paths.
- Zoom: make sure the layout survives 200% zoom and 320px width without losing content.
Make It Part of the Workflow
Accessibility decays without process. Add an accessibility linter to your build, include focus-state and contrast checks in design tokens, write a short checklist into your definition of done, and add accessibility acceptance criteria to tickets. Catching issues in the pull request is a fraction of the cost of fixing them after launch.
Conclusion
Accessibility is not a phase at the end of a project, it is a quality attribute you build in from the first component. The teams that treat it that way ship products that are usable by more people and rarely face a frantic remediation scramble later.
Need an audit or an accessible rebuild? Our web development team builds WCAG-compliant interfaces by default. Get in touch to talk through your product.
