Every accessibility report I write has roughly the same shape:

  • a set of failures that look recent;
  • a set that look old;
  • evidence that someone already fixed this once.

A contractor came in, a report was produced, the critical items were resolved, and a statement went up. Then the site drifted back.

That pattern is the finding. The individual contrast ratios and missing labels are symptoms.

First, the vocabulary. Decision-makers rarely use these terms daily, and two people in one meeting can mean different things by them.

The terminology, briefly

  • WCAG stands for Web Content Accessibility Guidelines. It is a technical standard from the World Wide Web Consortium, the body that maintains the standards the web runs on. It is not a law. It is what laws and funding contracts point at to define what accessible means.
  • WCAG 2.2 is the current version, published as a W3C Recommendation on 5 October 2023. It replaced 2.1, which replaced 2.0. Each version is backwards compatible: a site that meets 2.2 also meets 2.1 and 2.0. Building to 2.2 can never leave an organisation short of an older requirement.
  • Levels A, AA and AAA describe how demanding the target is. Level A is the floor, not sufficient on its own. Level AA is the target almost all legislation, funder requirements and public procurement use worldwide. Level AAA is aspirational: the standard advises against requiring it as a general policy, because some content cannot satisfy every AAA criterion. When somebody says accessible, they almost always mean AA.
  • Success criteria are the individual testable statements that make up each level. They are pass or fail, not judgement, which makes conformance auditable.
  • POUR is the four principles the criteria sit under: content must be Perceivable, Operable, Understandable and Robust. It is useful shorthand for a board asking what the standard protects.
  • Assistive technology is the term for the tools people use to reach a site other than a mouse and a screen: screen readers, screen magnifiers, voice input software, switch devices, and plain keyboard-only navigation. Keyboard-only is the most common and the most often overlooked.
  • Conformance and accessibility are not the same thing. Conformance means the success criteria are met. Accessibility means a person can actually complete the task they came to do. A site can conform and still be hard to use. This matters more than any single criterion: it is why a passing audit score is not a working website.
  • An accessibility statement is a public document declaring which standard the organisation works to, what is known not to conform, and how to report a problem. It is a governance artefact, not a technical one, and the piece most often left to go stale.
  • EN 301 549 is the European harmonised standard for accessibility in technology. It is mostly a wrapper around WCAG, and it is how EU law points at the guidelines. It matters below, because the UK and the EU currently point at different WCAG versions through it.

What changed in WCAG 2.2

WCAG 2.2 added nine success criteria and removed one, 4.1.1 Parsing, the first removal in the standard's history. Of the nine additions:

  • Two are Level A: 3.2.6 Consistent Help and 3.3.7 Redundant Entry.
  • Four are Level AA: 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum) and 3.3.8 Accessible Authentication (Minimum).
  • The remaining three sit at AAA.

The one most likely to catch an existing charity site is 2.5.8. It asks for interactive targets of at least 24 by 24 CSS pixels, or equivalent spacing around them. That is a question about how the site is laid out on a phone, not about code.

The failures are not exotic and they are not improving

Basic failures are getting more common, not less. WebAIM has scanned the top one million home pages every year since 2019, and the 2026 edition is the first to reverse a trend of small improvements in each of the previous six years:

  • 95.9% of home pages carried detectable WCAG 2 failures at Level A or AA, up from 94.8% the previous year.
  • The average was 56.1 errors per page, against 51 the year before.

What matters more than the headline is which failures. The same six categories have topped the WebAIM Million for the last seven years:

  1. low contrast text;
  2. missing alternative text on images;
  3. empty links;
  4. missing labels on form inputs;
  5. empty buttons;
  6. missing document language.

None is a disputed reading of the standard. The first is 1.4.3 Contrast (Minimum) at Level AA, which asks for 4.5:1 on ordinary text and 3:1 on large text, and is settled the day the palette is signed off. The second is 1.1.1 at Level A. The last is 3.1.1 at Level A, a single attribute on the page. They are the most solved problems in web accessibility, and they persist at scale.

WebAIM's own explanation points at complexity, not ignorance. The average home page it scanned in February 2026 contained 1,437 elements, a 14.3% increase in a single year.

Nexer Digital, reading the same dataset, put the practical consequence plainly: close to 4% of all page elements carried an error, so a disabled visitor should now expect a barrier on roughly one in every twenty-six elements they encounter.

Sites are being built and published faster than anyone is checking them.

Where to look first. Start with those six categories: they are unglamorous and countable. Any free browser-based checker finds them in minutes, and its number is a fair proxy for how much attention the site has had lately.

What it will not tell you is whether things are getting worse. For that, repeat the scan on pages published in the last three months. If the newest pages score worse than the oldest, the problem is the publishing process, not the site.

The sector's relative position is not as reassuring as it looks

Charity sites rank among the better performers, which is less reassuring than it sounds. Warbox's State of Accessibility, published in November 2025, scored more than 1,200 UK websites across fourteen sectors using Google's automated PageSpeed Insights accessibility score:

  • Charity and nonprofit: 39% needing improvement, among the better performers.
  • Travel and tourism: 79%.
  • Retail: 63%.
  • All fourteen sectors: 48%.

I would treat that as a warning, not a result, for two reasons:

  1. It is an automated score, the cheapest test there is, so the real proportion is higher than the one reported.
  2. Close to two in five charity sites still failed it, in a sector whose audience explicitly includes disabled beneficiaries, and whose organisations regularly publish inclusion commitments in the same annual report that funds the website.

The gap between the stated position and the delivered one is exactly what a journalist or a hostile funder would look for.

There is also a structural reason to expect things to worsen. The Charity Digital Skills Report 2026, by Zoe Amar and Nissa Ramsay from a record 807 responses, found that:

Sites are getting more complex, boards are not getting more capable of overseeing them, and the money to close that gap is shrinking.

Where to look first. If your board has no digital expertise, do not start by recruiting for it; that takes time and may not be achievable. Make the reporting legible enough for a non-specialist trustee to hold someone to account.

One recurring line in the operational report, giving the conformance target, the date of the last assessment and the number of known outstanding issues, does more than a technical appendix nobody reads. Assign it to an existing committee, not a new one, and give trustees the questions worth asking rather than a dashboard.

Why remediation does not hold

A remediation project treats accessibility as a defect list. The wrong things are listed, corrected, and the project closes.

The problem is the following Tuesday, when the communications officer publishes a programme update:

  • They upload an image without alternative text, because the field is optional.
  • They paste a heading in as bold body text, because it looked right.
  • They add a link that says read more three times on the same page.
  • They embed a video with no captions, because the embed field never asked for any.

None of this is negligence. Each is the path of least resistance the system offered them. That is why accessibility and content governance are the same problem seen from two directions.

Soon the site is back near where the audit found it, and the statement describes a website that no longer exists. A statement that overstates conformance is worse than no statement. It turns an operational gap into a documented claim that can be checked against reality.

It is the same failure as a governance page still carrying a 2022 annual report. The document is not merely out of date. Its presence asserts that someone is maintaining it.

Where to look first. Before commissioning remediation, compare any previous report's findings against the site today.

Where the same items reappear, the remediation was never the problem, and repeating it will not change the outcome. The comparison is usually short, costs nothing, and decides whether the honest answer is to fix or to rebuild.

What a property of the system means

This is the distinction I would put to a board:

  • In a remediation model, accessibility depends on every person who touches the site behaving correctly every time.
  • In a system model, accessibility is a property of the components those people are given, and the correct outcome is the default one.

That changes the questions worth asking. Not whether the site passes today, which is a snapshot, but:

  • Can someone publish a page that fails, using only the tools they have been given? If yes, someone eventually will.
  • Where does accessibility live when the person who cares about it leaves? If the answer is a document they wrote, it left with them.
  • Who signs off that the accessibility statement still describes the site? If nobody, the statement is a liability with a publication date on it.
  • What happens at the next campaign, when a page is needed in two days? Campaign pressure is when systems get bypassed, and a system that only holds under normal conditions is not a system.

None of this is about knowing more criteria, which are public, stable and free. It is about whether meeting them depends on constant vigilance from one overloaded person.

Where to look first. This is a procurement question more than a technical one. Ask whoever next builds or maintains the site to demonstrate, not assert, that a non-technical colleague cannot easily publish a failing page:

  • Contrast is constrained by the palette, not chosen per page.
  • Heading levels follow from the content type, not from formatting choices.
  • Alternative text is required at upload, not optional.
  • Forms carry their labels by construction.
  • Layout and type are settled in the build, not by the person publishing: a layout that survives 400% zoom (1.4.10 Reflow) and a type system that survives a reader overriding the spacing (1.4.12 Text Spacing, which is Level AA and is often wrongly reported as AAA).

Each is a decision made once, and each removes a category of recurring failure permanently.

The regulatory position is narrower than most boards assume, and the exposure is wider

Charities are often told the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 do not apply to them. Usually correct, but not a rule.

The regulations bind public sector bodies, and the government's own guidance exempts non-governmental organisations like charities "unless they are mostly financed by public funding, provide services that are essential to the public or aimed at disabled people". Holding a grant does not put an organisation inside them. Being mostly publicly financed, or running a service the public depends on, can. Establish which side of that line you are on; do not assume.

Where they do apply, they now follow WCAG automatically. An amendment made on 25 October 2022 replaced the reference to the European standard with the Level A and AA success criteria of WCAG "as amended from time to time". When WCAG 2.2 published in October 2023, the UK public sector obligation moved with it, and the guidance now names WCAG 2.2 AA plainly.

The EU has not followed yet. EN 301 549 v4.1.1, published in September 2026, adopts WCAG 2.2 as its benchmark. But until the European Commission cites it in the Official Journal, the legal reference remains v3.2.1, which cites WCAG 2.1 AA. Working to 2.2 AA satisfies both today and needs no re-audit when the citation lands. That is the case for adopting 2.2 now.

The wider reading matters more than the sector classification:

  • Contracts. Charities delivering statutory services or holding significant public contracts often accept these standards contractually. The obligation is then real whether or not the regulations bind them directly.
  • The Equality Act 2010. It requires service providers to make reasonable adjustments for disabled people, a duty that reaches the provision of services under section 29. A website through which a person cannot access a service or complete a donation sits squarely within it.
  • The European Accessibility Act. Organisations that supply an in-scope service to consumers in an EU member state fall within the European Accessibility Act, enforceable since 28 June 2025. For a charity that means online sales, not donations or information, which is a narrower scope than the Act is usually given.

The practical exposure, though, is rarely a regulator. It is a funder's due diligence, a beneficiary who cannot complete a referral form, and a board that discovers at the wrong moment that its own website does not support its published inclusion commitment.

Where to look first. Adopt WCAG 2.2 Level AA as the stated organisational target and record that decision at board level. A target nobody has formally agreed is a target nobody owns.

Then check the existing accessibility statement against it. If it names an older version, names no version, or claims full conformance without evidence, correcting it is the fastest available reduction in exposure, and costs nothing but honesty.

If your site is built in Webflow

Everything above is platform independent. It holds on WordPress, Drupal, Craft or anything else, and I would make the same case to an organisation with no plan to change platform.

That said, most of my implementation work is in Webflow. If that is where your site lives, I can take this from a finding to a resolved position:

  • constraining the design system so failing combinations are not available;
  • structuring the CMS so required fields are actually required;
  • correcting the existing failures;
  • monitoring conformance as the site changes, not annually.

The detail of what that looks like in practice is written up separately. If you are on something else, the audit still stands on its own and the report is written for whoever implements it.

The finding underneath the findings

When I run a Blueprint Audit, the accessibility section is usually not the most uncomfortable part of the report. The timeline is. The organisation invested in fixing this, the fix worked, and the fix decayed, because nothing in the way the site is built or published prevented the decay.

An accessibility audit that produces a defect list produces another stretch of conformance. What decides whether the site is accessible in three years is whether the accessible option is also the easiest one for the person publishing at four o'clock on a Friday.

If you want to know which of those two positions your organisation is in, that is what the Blueprint Audit establishes. It stands alone, and the report is yours whether or not anything follows it.