Is WCAG AA legally required for UK charity websites?

Public sector bodies (which include some charities) must meet WCAG 2.1 AA under the 2018 regulations. For most independent charities it is not strictly required by law, but the Equality Act 2010 effectively requires equivalent accessibility, and funders increasingly expect WCAG AA as a baseline.

Do we need an accessibility statement on our website?

Yes - it is best practice for every charity and legally required for public-sector bodies. A short, honest statement is more useful than a long, evasive one. Name what is accessible, what is not, and how to report problems.

How often should we re-audit?

An automated scan monthly, a manual review every six months, and a full third-party audit every two years. The discipline is the cadence, not the depth of any single audit.

Charity Website Accessibility Without a Rebuild: How-To Guide

Most charity website accessibility audits end in a quote for a full rebuild. The fixes that recover most of the value without one - and the ongoing habits that stop the next regression.

Most charity accessibility audits end the same way. A report arrives listing 80 issues. A meeting is held. The conversation drifts toward a full rebuild, because the report has not separated the four issues that block screen-reader users from the 76 issues that affect nobody in practice. The rebuild is quoted at £40,000 and 18 months. The site does not get fixed. Three years later, the same report is commissioned again.

The good news is that accessibility on an existing site is mostly fixable without rebuilding. Around 80% of the practical accessibility gains for a typical charity site come from around 10 fixes, all of which can be applied inside the existing content management system in a fortnight. The rest can be tackled incrementally, and a few may genuinely justify deferral to the next rebuild cycle.

What an accessibility issue actually costs

Issues vary by severity. A useful triage scale:

Blocking: a real user cannot complete a critical task (donate, get support, find information).
Significant: a real user can complete the task but with disproportionate effort.
Cosmetic: technically fails a WCAG criterion but does not impede any real user task.

Almost all of the value of an accessibility programme lies in fixing blocking and significant issues. Cosmetic issues are real and worth resolving in time, but they do not justify a rebuild.

The ten high-impact fixes

1. Alt text on every meaningful image

Every image that conveys meaning needs alt text. Decorative images should have empty alt text (alt="") so screen readers skip them. Most charity sites have neither: either no alt text at all, or generic alt text like "image" on every photograph.

2. Headings in correct order

One H1 per page. H2s under it. H3s under those. Pages with five H1s, or pages that jump from H2 to H4, fail for screen-reader navigation. Most CMS templates allow correction without code.

3. Sufficient colour contrast

WCAG AA requires a contrast ratio of at least 4.5:1 for normal text. Light-grey text on white backgrounds (common in charity "clean" design) routinely fails. A 20-minute design system review and CSS update fixes the bulk of it.

4. Focus indicators on interactive elements

Keyboard users tab through pages. They need a visible indicator of where focus currently sits. Modern stylesheets often strip the default browser outline without replacing it. Reinstate a visible, designed focus state on links, buttons and form fields.

5. Form labels on every field

Every input needs an associated label, programmatically linked. Placeholder text is not a label. Forms without proper labels are unusable for screen-reader users and fail HMRC and ICO accessibility expectations for any form that handles personal data.

6. Captioned and transcribed video

Every video on the site needs captions; long-form video needs a transcript as well. YouTube auto-captions are a starting point, not a finished product - they need a human review pass.

A small link at the top of each page that lets keyboard users skip past the main navigation directly to the content. Standard pattern, 10 lines of code, makes the site significantly faster to use with assistive technology.

8. Document accessibility for PDFs

PDFs on a charity site (impact reports, policy documents, application forms) are often the worst-offending content. Re-export with tagged headings and alt text from the source document, or convert key documents to web pages. PDFs are not exempt from accessibility expectations.

9. Sensible link text

"Click here" and "read more" as standalone link text fail screen-reader navigation. Link text should describe its destination. "Read our 2025 impact report" beats "click here" every time.

10. A working keyboard journey for the donate button

The single most important interaction on most charity sites. Tab through the donation flow without a mouse. If you cannot reach the donate button, or cannot fill in card details, the entire fundraising engine is inaccessible. This is the test the trustees should be asking about.

What an audit should look like

Three layers, in order:

Automated scan: free tools like Axe or WAVE pick up around 30% of issues quickly. Run monthly.
Manual keyboard test: spend 30 minutes navigating the key journeys (homepage, donate, contact, key service page) using only the keyboard.
Assistive technology test: spend an hour using a screen reader (VoiceOver on Mac, NVDA on Windows) on the same journeys. The most uncomfortable hour of the quarter; the most useful.

Annual or biennial, a third-party audit from a specialist (often partnered with disabled testers) adds the depth automated and DIY tests cannot.

The accessibility statement

A short, honest statement on the site that names: what standards the site aims to meet, what is currently inaccessible, what the timetable for fixing it is, and how to report problems. Update it as the site changes. The hardest part of the statement is the honesty; the easiest part is the publishing.

The habits that prevent regression

Every new page reviewed against the ten fixes before publication.
Every contributor (staff, agency, volunteer) trained on alt text, heading order, and link text.
Every PDF reviewed for accessibility before upload.
Every quarter, a 30-minute keyboard test on a high-traffic page.

Accessibility regresses without these habits. A perfectly remediated site, left to organic content updates with no review, will fail again inside 18 months.

Accessibility is not a project. It is a maintenance discipline, like email deliverability or data hygiene. The site needs minor care every month, not a hero rebuild every five years.

When a rebuild really is the answer

Three signs the existing site genuinely cannot be brought to standard:

The CMS does not allow editing of heading structure, alt text or form labels.
The donate flow is hard-coded in a way that prevents keyboard interaction.
The visual design cannot be brought to AA contrast without redesign.

Even then, the focused fixes above should be applied in the meantime. The rebuild can take a year; users need an accessible site this quarter.

The 14-day improvement plan

Days 1 to 3: Run the automated scan, keyboard test, and screen-reader test. Triage to blocking, significant, cosmetic.
Days 4 to 9: Apply the ten high-impact fixes to the existing site.
Days 10 to 12: Update or publish the accessibility statement honestly.
Days 13 to 14: Brief the team on the ongoing habits. Diary the next monthly scan.

Two weeks. No rebuild. Most of the value captured. The site that disabled users encounter next month is meaningfully better than the one they encountered last month. That is the test that matters.

Charity Website Accessibility Without a Rebuild

What an accessibility issue actually costs