Getting Started

Before you can fix anything, you need to know where you stand. An accessibility audit gives you a clear picture of which WCAG 2.2 criteria your site currently passes or fails, and how severe each issue is.

Most automated scanners only catch around 30 to 40 per cent of WCAG issues. The rest require manual testing or AI-powered analysis. For a thorough assessment, combine automated scanning with manual testing by people who use assistive technology day to day.

You do not need to fix everything at once. Research consistently shows the same issues appearing on the majority of inaccessible websites. Start here:

• →Low contrast text — Ensure all text meets a 4.5:1 contrast ratio against its background (3:1 for large text).
• →Missing alt text — Every meaningful image needs a text alternative that describes its purpose.
• →Unlabelled form fields — Form inputs without associated labels are invisible to screen readers.
• →Empty links and buttons — Clickable elements with no discernible text leave keyboard users stranded.
• →Missing page language — Without a lang attribute, screen readers cannot pronounce content correctly.

Accessibility is not a one-person job. Designers, developers, content writers, product managers, and QA testers all play a role. Training does not need to be exhaustive for everyone — target it to each role.

Our training programmes are designed around real scenarios and can be tailored to your team's specific roles and technology stack.

The most expensive accessibility fixes are the ones you make after launch. The cheapest are the ones you prevent during design and development.

• →Design phase — Check contrast ratios, touch target sizes, and focus states before any code is written.
• →Development — Use linting tools, write semantic HTML, and test with a keyboard as you build.
• →Code review — Add accessibility to your review checklist — ARIA usage, heading hierarchy, form labelling.
• →QA and testing — Include automated scanning in your CI/CD pipeline and manual testing with assistive technology before release.

The EAA requires organisations to publish accessibility statements explaining how products and services meet the requirements. A good statement includes:

• →Which WCAG conformance level you are targeting and currently meeting
• →Known limitations and what you are doing to address them
• →How users can report accessibility barriers
• →Contact details for accessibility enquiries
• →The date the statement was last reviewed

Accessibility is not a one-off project. Content changes, new features are added, third-party components are updated, and team members change. Without continuous monitoring, accessibility can regress quickly.

Set up regular automated scans (monthly at minimum) and periodic manual audits (quarterly or after major releases). Track your compliance score over time and investigate any regressions immediately.