Accessibility audits with fixes your team can act on
Gjethe audits websites and web apps against WCAG 2.2 level AA: automated scans, manual checks of keyboard navigation, focus, forms, colour contrast, headings and media, and testing with screen readers such as NVDA, VoiceOver and TalkBack. You receive a prioritised report with clear explanations and code-level fixes, and we can fix the issues and re-test. We don't certify legal compliance; your legal advisers confirm obligations such as the European Accessibility Act.
- Free first consultation
- Written quote for your project
- Flexible payment milestones
At a glance
- Standard
- WCAG 2.2 level AA
- Testing
- Automated, manual, screen readers, keyboard
- Output
- Prioritised issues with code-level fixes
- Follow-up
- Fixes and re-testing on request
Definition
What is accessibility audit?
An accessibility audit checks whether a website or app can be used by people with disabilities, including people who use screen readers, keyboards, magnification or captions, usually measured against the Web Content Accessibility Guidelines (WCAG).
Accessibility problems lock real people out: a form that can't be completed without a mouse, a button a screen reader announces as "button", text too faint to read, a video without captions. Many issues are simple to fix once found. Automated tools catch only part of them, so a useful audit combines tools with careful manual testing and explains fixes in terms developers can apply.
Who is it for?
Online stores
Checkout, product pages and search usable by everyone.
SaaS products
Applications that meet customer procurement requirements.
Healthcare, education and public-facing services
Services people depend on, available to all.
Companies serving EU customers
Preparing for accessibility requirements in European markets.
What's included, and what you keep
What's included
- Scope and sampling of pages and flows
- Automated scans across the sample
- Manual WCAG 2.2 AA review
- Keyboard-only navigation testing
- Screen reader testing with NVDA, VoiceOver and TalkBack
- Colour contrast and zoom checks
- Forms, errors and focus management
- Media: captions, transcripts and audio description needs
- Prioritised issue list with code-level fixes
- Developer walkthrough of findings
- Re-testing after fixes
What you receive
Handed over at the end. Yours to keep.
- An audit report mapped to WCAG success criteria
- Prioritised issue backlog for your tracker
- Code examples for common fixes
- A re-test report after fixes
- Input for your accessibility statement
Why automated scans aren't enough
Automated tools such as axe and Lighthouse are excellent at catching some problems: missing alt attributes, low contrast, missing form labels. They can't judge whether alt text is meaningful, whether focus moves logically through a dialog, or whether a custom component makes sense to a screen reader user. Those need a person testing the real flows.
We use automated tools for breadth and manual testing for depth, focused on the tasks that matter most: signing up, searching, buying, booking, contacting.
Issues we commonly find
| Issue | Impact |
|---|---|
| Missing or unclear form labels | Screen reader users don't know what to enter |
| Custom buttons and menus without roles | Controls are unusable without a mouse |
| Invisible focus indicator | Keyboard users lose track of where they are |
| Low colour contrast | Text is hard to read for many people |
| Images without useful alt text | Content is missing for blind users |
| Error messages not announced | Users can't recover from form errors |
Prioritised, so fixing is realistic
A long list of issues with no priority stalls teams. We rank findings by severity and by how many people and key tasks they affect, group repeated issues by component so one fix solves many pages, and estimate effort, so your team can plan the work.
The European Accessibility Act and other rules
Accessibility requirements apply to many digital products and services in the EU, including e-commerce, banking services and e-books, and many countries have their own rules for the public sector. WCAG 2.2 AA is the usual technical reference. We audit against WCAG and explain the findings; whether and how specific laws apply to your business is a question for your legal advisers.
Keeping it accessible
Accessibility regresses with every release unless it's part of the process. We can add automated checks to your CI pipeline, provide component guidelines for designers and developers, and train your team so new features start accessible instead of being fixed later.
What helps us start
- The site or app and test accounts
- The most important user tasks
- Your design system or component library
- Known issues or user complaints
- Your target standard and any deadlines
- Who will fix the issues
Accessible design systems
Most accessibility issues come from shared components: a button, a menu, a modal, a form field. Fixing them in the design system fixes them everywhere they're used. We review components in your library, document accessible behaviour for each, such as keyboard interaction, focus and labels, and provide tested examples your developers can copy.
How accessibility audit works, step by step
Every step has a clear output you can review. Timing is agreed in your quote.
- 1
Scope
Pages, flows and standard agreed; sample selected.
- 2
Automated scan
Breadth checks across the sample.
- 3
Manual testing
Keyboard, screen readers, zoom and content review.
- 4
Report
Prioritised findings with WCAG references and fixes.
- 5
Fix
Your team or ours fixes the issues.
- 6
Re-test
Fixes verified and the report updated.
Tools, and what shapes your quote
Pricing is based on your project and agreed in your quote. These are the things that move it.
| Factor | Why it matters |
|---|---|
| Number of pages and flows | More templates and journeys mean more testing. |
| Complexity | Custom components and web apps need deeper manual testing. |
| Platforms | Mobile apps and several browsers add test runs. |
| Remediation | Fixing the issues is quoted separately from the audit. |
| Re-testing | Each re-test round adds verification work. |
| Area | Tools |
|---|---|
| Automated | axe DevTools, Lighthouse, WAVE, Pa11y |
| Screen readers | NVDA, JAWS, VoiceOver, TalkBack |
| Other | Colour Contrast Analyser, browser zoom and reflow tests, keyboard testing |
Common mistakes to avoid
What we see go wrong most often, and how a good project avoids it.
Relying on an overlay widget
Overlays don't fix underlying code and can make things worse for assistive technology users.
Only running automated tools
They miss many of the issues that block users.
Fixing page by page
Fix shared components once; the fix spreads across the site.
Treating it as a one-off
Without checks in your process, issues return with the next release.
Frequently asked questions
Which standard do you audit against?
WCAG 2.2 level AA, the most common technical reference for accessibility requirements.
Do you certify that our site is compliant?
No. We audit against WCAG and report findings. Whether specific laws apply and are met is confirmed by your legal advisers.
Do accessibility overlays work?
They don't fix the underlying code and can interfere with assistive technologies. We recommend fixing the site itself.
Can you fix the issues you find?
Yes. We can fix them in your codebase or guide your developers, then re-test.
Do you test mobile apps?
Yes, with VoiceOver on iOS and TalkBack on Android, against the relevant WCAG criteria.
Can you help with our accessibility statement?
We provide the findings and status that the statement should describe. The statement itself is owned and published by you.
Do you test with real screen readers?
Yes. NVDA, VoiceOver and TalkBack on real browsers and devices.
Can you add accessibility checks to our development process?
Yes, with automated tests in CI, component guidelines and team training.
How is an accessibility audit priced?
It is quoted on the number of pages and flows, the complexity of components and whether fixes and re-tests are included.
How many pages do you test?
We test a representative sample of templates and the key user journeys, chosen with you, since most issues repeat across pages built from the same components.
Do you test PDFs?
We can review important PDFs for accessibility basics, though converting key documents to accessible web pages is often the better fix.
Do you train our designers and developers?
Yes. Short practical sessions on accessible components, content and testing help new work start accessible.
Related services
Accessibility Audit by industry
Make your site usable by everyone.
Tell us what you need. You get an honest assessment, a clear plan and a written quote. The first consultation is always free.
- What happens next
- 1You tell us what you need
- 2We aim to reply within 24 hours with questions
- 3You get a written quote for your project