Accessibility Fails Because It Is Treated as a Task, Not a Property of the System
Last reviewed
Key takeaways
- Accessibility failures recur because remediation treats them as a defect list, while the publishing workflow that produced them stays unchanged.
- WCAG 2.2 Level AA is the target worth adopting formally: it is backwards compatible, so meeting it also satisfies 2.1 and 2.0.
- The UK public sector obligation moved to WCAG 2.2 automatically because a December 2022 amendment made the regulations reference the current published version rather than a fixed one.
- The EU has not yet followed, as EN 301 549 still cites WCAG 2.1 AA with an update expected during 2026, so working to 2.2 covers both positions and avoids a re-audit.
- WebAIM found 95.9% of the top million home pages carried detectable failures in 2026, reversing six years of improvement, with the same six basic error types dominating for a seventh year.
- Conformance and accessibility are not the same thing: a site can meet every success criterion and still be difficult for a disabled visitor to actually use.
Summary
Most charity accessibility work is remediation. An audit produces a defect list, the defects are corrected, and the site drifts back within about a year because nothing in the way it is built or published prevented the drift. This post argues that WCAG 2.2 AA has to be a property of the system rather than a task on someone's list, explains the terminology plainly for readers who do not use it daily, and sets out what the 2026 WebAIM and Charity Digital Skills data say about where the sector is heading.
Every accessibility report I write has roughly the same shape. There is a set of failures that look recent, a set that look old, and somewhere in the organisation's history there is evidence that someone already fixed this once. A contractor was brought in, a report was produced, the critical items were resolved, and a statement went up on the site. Then eighteen months passed and the site drifted back.
That pattern is the finding. The individual contrast ratios and missing labels are symptoms.
Before the argument, the vocabulary. Most of the people who have to make decisions about this are not the people who use these terms daily, and the terms get used loosely enough that two people in the same meeting can mean different things by them.
The terminology, briefly
- WCAG stands for Web Content Accessibility Guidelines. It is a technical standard published by the World Wide Web Consortium, the body that maintains the standards the web runs on. It is not itself a law. It is the document that laws and funding contracts point at when they need to define what accessible means.
- WCAG 2.2 is the current version, published in October 2023. It replaced WCAG 2.1, which replaced WCAG 2.0. Each version is backwards compatible, which is the practically important point: if a site meets 2.2, it also meets 2.1 and 2.0 automatically. There is no scenario in which building to 2.2 leaves an organisation short of an older requirement.
- Levels A, AA and AAA describe how demanding the conformance target is. Level A is the floor and is not sufficient on its own. Level AA is the standard target used by almost all legislation, funder requirements and public procurement worldwide. Level AAA is aspirational, and the standard itself acknowledges it cannot be met across all content. When somebody says a site should be accessible, AA is almost always what they mean.
- Success criteria are the individual testable statements that make up each level. They are pass or fail rather than matters of judgement, which is what makes conformance auditable. WCAG 2.2 added nine new criteria and removed one, the first removal in the standard's history. Six of the additions apply at Level A or AA, and they concentrate on cognitive load, touch and mobile interaction, and authentication.
- POUR is the four principles the criteria are organised under: content must be Perceivable, Operable, Understandable and Robust. It is a useful shorthand when a board wants to understand what the standard is actually trying to protect.
- Assistive technology is the category term for the tools people use to access a site that are not a mouse and a screen. It includes screen readers, screen magnifiers, voice input software, switch devices, and simple keyboard-only navigation. Keyboard-only is the most common and the most frequently 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 technically conform and still be difficult to use. This distinction matters more than any single criterion, because it is the reason a passing audit score is not the same as a working website.
- An accessibility statement is a public document on the site declaring which standard the organisation is working to, what is known not to conform, and how to report a problem. It is a governance artefact rather than a technical one, and it is 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 the route by which EU law points at the guidelines. It matters below because the UK and the EU are currently pointing at different WCAG versions through it.
The failures are not exotic and they are not improving
WebAIM has run an automated scan of the top one million home pages every year since 2019, and the 2026 edition is the first to reverse a six-year trend of slow improvement. It found that 95.9% of those home pages carried detectable failures against WCAG 2.2 at Level A or AA, up from 94.8% the previous year, with an average of 56.1 errors per page against 51 the year before.
The detail that matters more than the headline is which failures. The same six categories have topped the WebAIM Million for seven consecutive years: low contrast text, missing alternative text on images, empty links, missing labels on form inputs, empty buttons, and missing document language. These are not disputed interpretations of the standard. They are the most solved problems in web accessibility, and they persist at scale.
WebAIM's own explanation points at complexity rather than ignorance. The average home page it scanned in February 2026 contained 1,437 elements, a 22.5% increase in a single year. Nexer Digital, reading the same dataset, put the practical consequence plainly: a disabled visitor should now expect to meet 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. Those six categories are the right starting point precisely because they are unglamorous and countable. Any free browser-based checker will surface them in minutes, and the number it returns is a reasonable proxy for how much attention the site has had recently. What that number will not tell you is whether the problem is getting worse, so the more useful measure is the same scan repeated on pages published in the last three months. If the newest pages score worse than the oldest, the problem is the publishing process rather than the site.
The sector's relative position is not as reassuring as it looks
Warbox's State of Accessibility survey of UK websites placed charity and nonprofit sites among the better-performing sectors it examined, with 36% of the sites tested needing improvement. That is considerably better than travel and tourism at 77% or retail at 61%.
I would treat that as a warning rather than a result. More than one in three charity sites still failed, in a sector where the audience explicitly includes disabled beneficiaries, and where 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 the position to worsen rather than hold. The Charity Digital Skills Report 2026, authored by Zoe Amar and Nissa Ramsay from 807 responses, found that almost half of charities have no trustee with relevant digital expertise, that only 28% now hold a digital strategy, a sharp fall on the previous year, and that access to dedicated digital funding dropped from 30% of organisations to 17%. Sites are getting more complex, boards are not getting more capable of overseeing them, and the money to close that gap is contracting.
Where to look first. The practical response to a board with no digital expertise on it is not to recruit for it, which takes a year and may not be achievable. It is to make the reporting legible enough that a non-specialist trustee can hold someone to account. A single recurring line in the operational report, stating 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 rather than creating a new one.
Why remediation does not hold
A remediation project treats accessibility as a defect list. Something is wrong, the wrong things are enumerated, the wrong things are corrected, and the project closes.
The problem is what happens 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. None of these is negligence. Each one is the path of least resistance offered by the system they were handed.
Within a year the site has drifted back to a state close to where the audit found it, and the accessibility statement is now describing a version of the website that no longer exists. A statement that overstates conformance is worse than no statement, because it converts an operational gap into a documented claim that can be checked against reality.
This is the same failure mode as a governance page 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 any remediation, establish what the site looked like immediately after the last one. If a previous report exists, compare its findings against the site today. Where the same items reappear, the remediation was never the problem and repeating it will not change the outcome. That comparison is usually a single afternoon of work and it changes what the organisation should be buying.
What a property of the system means
The distinction I would put to a board is this. 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 currently passes, 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 success criteria. The criteria are public, stable and free. It is about whether the organisation has arranged itself so that meeting them does not depend on continuous vigilance from one overloaded person.
Where to look first. This is a procurement question more than a technical one. Whoever next builds or maintains the site should be asked to demonstrate, not assert, that a non-technical colleague cannot easily publish a failing page. Contrast should be constrained by the palette rather than chosen per page. Heading levels should follow from the content type rather than from formatting choices. Alternative text should be required at upload rather than optional. Each of those is a decision made once in the build, and each one removes a category of recurring failure permanently.
The regulatory position is narrower than most boards assume, and the exposure is wider
Charities are frequently told that the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 do not apply to them, which is usually correct. The regulations bind public sector bodies rather than charities.
Two details are worth knowing anyway. Those regulations were amended in December 2022 so that they reference WCAG directly and point at the current published version, rather than naming a fixed one. When WCAG 2.2 published in October 2023, the UK public sector obligation moved with it. The EU has not yet followed: the harmonised standard EN 301 549 still cites WCAG 2.1 AA, and the updated version incorporating 2.2 is expected during 2026. An organisation working to 2.2 AA satisfies both positions today and will not need re-auditing when the European standard catches up, which is the practical case for adopting 2.2 now rather than waiting.
The wider reading matters more than the sector classification. Charities delivering statutory services or holding significant public contracts frequently accept these standards contractually, at which point the obligation is real regardless of whether the regulations bind them directly. The Equality Act 2010 requires service providers to make reasonable adjustments for disabled people, and a website through which a person cannot access a service or complete a donation sits squarely within that duty. Organisations providing relevant services into the EU fall within the European Accessibility Act, which became enforceable in June 2025.
The practical exposure, though, is rarely a regulator. It is a funder's due diligence process, a beneficiary who cannot complete a referral form, and a board that discovers at the wrong moment that its published inclusion commitment is not supported by its own website.
Where to look first. Adopt WCAG 2.2 Level AA as the stated organisational target and record that decision at board level, because a target nobody has formally agreed is a target nobody owns. Then check the existing accessibility statement against it. If the statement 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. The argument holds on WordPress, Drupal, Craft or anything else, and I would make the same case to an organisation with no intention of changing platform.
That said, most of my implementation work is in Webflow, and 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, and monitoring conformance as the site changes rather than annually. 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 uncomfortable part is the timeline. 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 eighteen months of conformance. What determines 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 is £2,500, it stands alone, and the report is yours whether or not anything follows it.
Frequently asked questions
WCAG 2.2, published in October 2023, is the current version. It adds nine success criteria and removes one, and the additions concentrate on cognitive load, touch and mobile interaction, and authentication. Six of them apply at Level A or AA. Because each version is backwards compatible, meeting 2.2 AA also means meeting 2.1 AA and 2.0 AA, so working to 2.2 cannot leave an organisation short of an older obligation. WCAG 2.2 Level AA is the target I would recommend any charity adopt formally.
Not automatically. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 bind public sector bodies rather than charities. Since a December 2022 amendment those regulations reference the current published version of WCAG, which means the public sector obligation moved to 2.2 when it published. Charities delivering statutory services or holding public contracts frequently accept the same standard contractually. Separately, the Equality Act 2010 duty to make reasonable adjustments applies to service providers, and organisations offering relevant services into the EU fall within the European Accessibility Act, enforceable since June 2025. The EU harmonised standard EN 301 549 still cites WCAG 2.1 AA, with an update to 2.2 expected during 2026, so an organisation working to 2.2 AA is covered on both sides.
Annually is the common answer, and it is the wrong frame. An annual assessment tells you the state of the site on one day a year and says nothing about the eleven months in between. The more useful arrangement is a check at the point of publication, so pages are assessed as they go live rather than retrospectively, with a fuller review when the site changes structurally. If an organisation can only do one thing, checking new pages at publication catches more than an annual scan does.
No, and research such as the WebAIM Million is explicit that it measures only what automated tools can detect. Automated tools reliably catch contrast, missing alternative text and unlabelled form fields. They cannot judge whether alternative text describes the right thing, whether a heading structure conveys the meaning of the page, or whether a keyboard user can complete a donation. A clean automated scan is a floor, not a verdict. Manual testing and testing with disabled users sit above it.
Yes, and more than most boards expect. An accessibility statement is a public claim about the current state of the website. If the site has changed and the statement has not, the organisation is publishing an inaccurate assertion about its own conformance. A stale statement is a weaker position than an honest one that names outstanding issues and dates them, because the honest version demonstrates that someone is monitoring the site.
Building to WCAG 2.2 AA from the outset adds very little to a build budget, because the decisions involved have to be made anyway. Colour contrast is settled when the palette is settled. Heading structure is settled when the page is structured. Retrofitting accessibility onto a site that was not built for it is where the cost appears, and that cost recurs every time the site drifts and needs correcting again.
Ownership at an individual level is the failure pattern rather than the solution, because it means accessibility leaves when that person does. Accountability sits with the board, in the same way as any other compliance and reputational obligation. Operationally, the objective is that no single person has to hold the standard in their head, because the publishing tools do not offer an easy route to a failing page.
