Website Accessibility for Nonprofits
Key takeaways
- WCAG AA appears in most briefs but is rarely specified in enough detail to be a meaningful deliverable, so sites launch nominally compliant and drift as editors add content without accessibility awareness.
- For nonprofits, accessibility is not primarily a legal risk but evidence of whether stated inclusion commitments are architectural reality or just mission-statement rhetoric.
- Funders read the contradiction plainly: an application claiming inclusion alongside a website full of barriers suggests the commitment is performative, and organisations have lost funding over that mismatch rather than a legal breach.
- Inaccessible sites tend to exclude the very people the mission serves — beneficiaries with disabilities — as well as disabled donors, staff and volunteers.
- Meeting WCAG AA demonstrates that inclusion is architectural, that beneficiary dignity matters institutionally, and that values claims are verifiable and competently delivered.
- Launch-day compliance is not the same as compliance eighteen months later, so accessibility needs ongoing governance rather than a one-off sign-off.
Summary
WCAG AA compliance is cited in most nonprofit web project briefs as a requirement, but it is rarely specified in enough detail to be meaningful as a deliverable. The result is a site that is nominally WCAG-compliant at launch — the developer ran an automated scan, fixed the flagged issues, and signed off — and progressively non-compliant as content editors add pages, images, and updates without accessibility awareness. The compliance that existed at launch is not the compliance that exists eighteen months later.For nonprofits, WCAG AA is not optional. Organisations receiving public funding, serving beneficiaries with disabilities, or operating under the Equality Act 2010 have a legal obligation that extends beyond the website build. It extends to the ongoing management of the site under real editorial conditions. The distinction between building an accessible website and maintaining an accessible website under real-world use is where most nonprofit organisations discover, usually expensively, that their implementation was not as robust as they believed.This post covers WCAG AA accessibility for nonprofits as an institutional governance obligation rather than a technical specification: what the standard requires, how to assess whether an existing site meets it, what the most common failure modes are for nonprofit websites, how to choose a web platform and CMS architecture that preserves compliance under real editorial conditions, and how to build accessibility monitoring into the governance cycle so that failures are caught and remediated before they accumulate into a systemic compliance problem.
I recently spoke with a Communications Director who'd just received accessibility audit results showing 73 WCAG violations on their charity's website. Her first question: "Will this affect our funding?"
My response surprised her: "The bigger question is whether your website currently excludes the very people your mission claims to serve—and what that says about institutional values."
Accessibility isn't primarily legal risk for nonprofits. It's evidence of whether inclusion commitments are architectural reality or just mission statement rhetoric.
Through my nonprofit work building 100+ websites, I've learned that organisations treating WCAG compliance as regulatory checkbox miss the fundamental point: for charities claiming to serve marginalised communities, inaccessible websites aren't legal liability—they're values contradiction visible to everyone paying attention.
Why Nonprofits Can't Treat Accessibility as Legal Compliance
Commercial websites approach accessibility through risk management lens: "What's legally required? What's our liability exposure? How do we demonstrate compliance if challenged?"
This framework makes sense for organisations whose primary obligation is shareholder value and regulatory adherence.
Nonprofits operate under fundamentally different accountability structure. Your charitable purpose likely involves:
- Serving marginalised or vulnerable populations
- Promoting equality and reducing disadvantage
- Advocating for inclusion and dignity
- Demonstrating social responsibility
When you state these commitments in mission statements, funding proposals, and public communications—then build inaccessible websites—you create institutional values contradiction that undermines credibility far beyond legal risk.
The real questions aren't:
- "Are we legally required to meet WCAG standards?"
- "What's our liability if we don't comply?"
- "How do we demonstrate minimum regulatory adherence?"
The real questions are:
- "Does our digital presence reflect the inclusion values we claim institutionally?"
- "Are we excluding people our mission commits to serving?"
- "What does inaccessibility say about whether we actually believe our stated principles?"
This reframes accessibility from legal checkbox to institutional integrity issue.
The Values Contradiction Visible to Funders
I regularly see nonprofits with beautiful mission statements about inclusion, equality, and serving marginalised communities—alongside websites with dozens of WCAG violations creating barriers for disabled users.
The contradiction isn't subtle. Here's what funders notice:
Your grant application states: "We're committed to disability inclusion and believe everyone deserves equal access to our services."
Your website demonstrates: Colour contrast failures making text unreadable for low vision users. Keyboard navigation failures preventing access for people who can't use mice. Missing alt text on images blocking screen reader users. Form errors without clear descriptions frustrating people with cognitive disabilities.
The funder's reasonable conclusion: Your inclusion commitment is performative rhetoric, not institutional reality. Because if you genuinely valued accessibility, it would appear in basic infrastructure like your public-facing website.
I've watched organisations lose funding not because they violated legal requirements, but because funders questioned whether stated values matched institutional behaviour. The accessibility audit became values audit—and the organisation failed.
The Stakeholder Groups You're Excluding
When nonprofits ignore accessibility, they typically exclude the exact populations their missions claim to serve:
Beneficiaries with Disabilities
If your charitable purpose involves serving vulnerable or marginalised populations, significant percentage likely have disabilities requiring accessible digital infrastructure.
Youth services organisation with keyboard navigation failures: Excluding young people with motor disabilities from accessing programme information.
Mental health charity with complex navigation and unclear instructions: Creating barriers for people with cognitive disabilities or mental health conditions affecting concentration.
Poverty alleviation nonprofit with low colour contrast: Excluding older beneficiaries and people with visual impairments from understanding available services.
You're not just creating legal risk. You're actively excluding the people you exist to serve—whilst simultaneously claiming commitment to their dignity and inclusion.
Donors with Disabilities
Approximately 22% of UK population has a disability. When your donation forms aren't keyboard accessible, your giving pages have colour contrast failures, or your impact reports can't be read by screen readers—you're excluding donors who want to support your work.
The message you send: "We value your financial support—unless accessing our giving infrastructure requires accommodations we couldn't be bothered to provide."
Staff and Volunteers with Disabilities
Inaccessible internal tools, volunteer portals, or resource pages exclude people with disabilities from participating in your organisation's work.
The institutional statement: "We want diverse staff and volunteers—except we didn't build infrastructure enabling full participation."
WCAG as Institutional Values Framework
After 7+ years specialising in nonprofits, I've learned to position WCAG compliance as institutional values evidence rather than legal requirement.
Web Content Accessibility Guidelines (WCAG) 2.1 Level AA represents international consensus on what makes digital content accessible to people with disabilities. It's not regulatory burden—it's codified inclusion expertise.
When organisations meet WCAG AA, they demonstrate:
Inclusion is architectural commitment: Accessibility isn't afterthought or accommodation—it's foundation informing every design and content decision.
Beneficiary dignity matters institutionally: People with disabilities aren't special cases requiring separate consideration—they're stakeholders whose needs inform standard approach.
Values claims are verifiable: Inclusion rhetoric in mission statements translates to measurable infrastructure accessible to independent verification.
Institutional competence exists: The organisation understands its obligations, implements professional standards, and maintains accountability for public commitments.
This transforms accessibility from "legal thing we should probably address" to "fundamental evidence of institutional character visible in basic infrastructure decisions."
The Four WCAG Principles Applied to Nonprofit Context
WCAG organises accessibility around four principles: Perceivable, Operable, Understandable, Robust. Here's what these mean for nonprofit institutional values:
1. Perceivable: Information Must Be Presentable to All Users
Technical requirement: Alternative text for images, captions for videos, sufficient colour contrast, content doesn't rely solely on colour.
Values interpretation for nonprofits: Beneficiaries, donors, and stakeholders with visual impairments, colour blindness, or cognitive disabilities can perceive your institutional communications equally to sighted users.
Common violations I see:
- Impact photos without alt text (screen reader users can't understand visual impact stories)
- Infographics conveying data only through colour (colour-blind users miss critical information)
- Videos without captions (deaf users excluded from multimedia content)
- Low contrast text (vision-impaired users can't read content)
What this violates: Commitment to inclusive communication and equal access to institutional information.
2. Operable: Interface Components Must Be Operable by All Users
Technical requirement: Keyboard accessibility, sufficient time for interactions, navigation mechanisms, focus indicators.
Values interpretation for nonprofits: Beneficiaries and donors with motor disabilities, who can't use mice, or who need extra time can navigate and interact with your website independently.
Common violations I see:
- Donation forms requiring mouse interaction (excluding people with motor disabilities from giving)
- Dropdown menus closing too quickly (frustrating users who need extra time)
- Custom navigation without keyboard support (preventing non-mouse users from accessing content)
- Missing skip links (forcing keyboard users through repetitive navigation)
What this violates: Commitment to enabling full participation regardless of how people interact with technology.
3. Understandable: Information and Operation Must Be Understandable
Technical requirement: Readable text, predictable navigation, input assistance, error identification and correction.
Values interpretation for nonprofits: Beneficiaries with cognitive disabilities, learning difficulties, or those under stress can understand your institutional communications and successfully complete interactions.
Common violations I see:
- Jargon-heavy content without plain language alternatives (excluding people with cognitive disabilities)
- Inconsistent navigation patterns (confusing users who rely on predictable structures)
- Form errors without clear explanations (preventing successful completion)
- Complex language in critical information like safeguarding policies (excluding people who need these most)
What this violates: Commitment to clear communication and enabling beneficiaries to access services independently.
4. Robust: Content Must Work with Current and Future Technologies
Technical requirement: Valid HTML, proper semantic markup, assistive technology compatibility.
Values interpretation for nonprofits: Your institutional communications work reliably with screen readers, voice control, and other assistive technologies that disabled users depend on.
Common violations I see:
- Invalid HTML breaking screen reader interpretation (making content inaccessible)
- Improper heading hierarchy confusing navigation tools (preventing users from understanding structure)
- Custom components without proper ARIA labels (blocking assistive technology users)
- Non-semantic markup hiding content meaning (preventing proper interpretation)
What this violates: Commitment to professional standards and ensuring infrastructure serves all stakeholders reliably.
The Compliance Verification Framework
Nonprofits can't claim accessibility commitment without verification methodology proving adherence. Here's the governance framework I recommend:
1. Initial Compliance Audit
Professional WCAG 2.2 Level AA audit using:
- Automated testing tools (identifies ~30% of issues)
- Manual expert review (identifies remaining ~70%)
- Assistive technology testing (verifies real-world functionality)
This establishes baseline understanding of current compliance status and required remediation.
2. Remediation with Verification
Addressing identified issues with:
- Priority ranking (critical barriers first)
- Fixes verified through re-testing
- Documentation of changes made
- Confirmation of successful remediation
This ensures issues are actually resolved, not just marked complete.
3. Ongoing Maintenance Protocol
Accessibility isn't one-time achievement—it requires continuous attention:
- Quarterly automated testing identifying new issues
- Annual comprehensive review verifying sustained compliance
- Content creation guidelines preventing new violations
- Staff training ensuring accessibility understanding
This prevents compliance decay as website evolves.
4. Public Accountability
Accessibility statement documenting:
- Current compliance status with evidence
- Known issues and remediation timeline
- Contact method for reporting barriers
- Organisational commitment to accessibility
This demonstrates institutional accountability and enables stakeholder verification.
Why "We'll Fix It Later" Fails
I regularly hear: "We know accessibility is important, but we need to launch now. We'll address WCAG compliance in the next phase."
This approach fails because:
Retrofitting costs 2-3x more than building accessibly initially: Changing colour schemes, restructuring navigation, rewriting content, fixing forms—all more expensive when addressing violations than implementing properly from start.
"Later" rarely happens: Once launched, accessibility gets deprioritised for "urgent" projects. Years pass with inaccessible infrastructure whilst organisations claim commitment to inclusion.
You're actively excluding people during "temporary" non-compliance: Each day with inaccessible website is another day beneficiaries with disabilities can't access services, donors can't contribute, stakeholders can't engage.
Values contradiction becomes institutional pattern: When accessibility is always next phase priority, never current requirement, you've revealed what the organisation actually values versus what it claims to value.
The Board Governance Questions
Trustees should ask these accessibility questions as part of website governance oversight:
"How do we verify we meet WCAG 2.2 Level AA standards?"
Not "Are we accessible?" but "What's the verification methodology proving compliance?" If there isn't one, you can't make accessibility claims.
"What's our protocol for maintaining accessibility as the website evolves?"
Compliance isn't static. How does the organisation prevent new violations through content updates, design changes, or feature additions?
"Does our accessibility approach reflect the inclusion values we claim institutionally?"
Are we meeting minimum legal requirements, or demonstrating genuine commitment to full participation by people with disabilities?
"Can beneficiaries with disabilities access our services through our digital presence?"
Not theoretical accessibility, but practical verification that people we exist to serve can actually use our infrastructure.
"What institutional accountability exists for accessibility failures?"
Who's responsible for compliance? What happens when violations are identified? How do stakeholders report barriers?
These questions shift accessibility from technical consideration to governance responsibility reflecting institutional values.
The Funder Perspective on Accessibility
Many major funders now require accessibility compliance as grant condition. But the requirement reveals something deeper than legal obligation:
Funders use accessibility as proxy for organisational competence and values alignment.
Accessible website suggests:
- Organisation understands professional standards
- Leadership takes inclusion commitments seriously
- Infrastructure investment reflects stated values
- Institutional governance includes compliance verification
Inaccessible website suggests:
- Organisation doesn't understand basic obligations
- Inclusion claims are performative, not operational
- Infrastructure decisions contradict stated commitments
- Governance gaps exist in institutional oversight
I've seen funders question organisations' capacity to deliver programmes effectively when basic website accessibility failures indicate governance and competence gaps.
The accessibility audit becomes institutional capability audit—and failures undermine credibility beyond the immediate technical violations.
What Accessibility Excellence Actually Looks Like
Meeting WCAG AA is baseline, not aspirational goal. Organisations genuinely committed to accessibility demonstrate:
Accessibility integrated into workflows: Content creators understand requirements, developers build accessibly by default, reviewers verify compliance before publication.
User testing with people with disabilities: Actual users with assistive technology needs provide feedback ensuring compliance translates to usability.
Proactive improvement beyond minimum standards: Organisation identifies barriers before users complain, implements enhancements beyond WCAG requirements, leads rather than follows.
Public accountability and transparency: Accessibility statement honestly describes current status, known limitations, remediation plans, and stakeholder feedback mechanisms.
Accessibility expertise in decision-making: When making design, content, or structural choices, accessibility implications inform decisions rather than being afterthought considerations.
This is what values-driven accessibility looks like versus checkbox compliance.
The Blueprint Audit Accessibility Framework
This is why Blueprint Audit process includes accessibility governance as core component rather than optional consideration.
The accessibility analysis includes:
Current compliance audit: Professional WCAG 2.2 AA evaluation identifying existing violations and required remediation.
Values alignment assessment: Does current accessibility approach reflect stated institutional inclusion commitments? Where are contradictions between values claims and infrastructure reality?
Verification methodology: What protocols prove ongoing compliance? How does Board verify accessibility obligations are met?
Maintenance framework: How does organisation prevent new violations as website evolves? What training, guidelines, and testing sustain compliance?
Stakeholder accountability: How can beneficiaries, donors, or users with disabilities report barriers? What institutional response addresses accessibility failures?
The output provides Board-endorsed accessibility governance framework treating compliance as institutional values evidence rather than legal checkbox.
The Implementation Reality
Building accessible websites requires:
- Design decisions prioritising contrast, clarity, and simplicity
- Development following semantic HTML and ARIA standards
- Content creation with plain language and alternative formats
- Testing protocols verifying assistive technology compatibility
- Maintenance procedures preventing compliance decay
This takes more expertise, more attention, more verification than building inaccessible websites.
But for organisations claiming inclusion values, it's not optional overhead—it's fundamental institutional integrity requirement.
The Cost of Inaccessibility
Organisations treating accessibility as deferrable expense should calculate the actual costs:
Retrofitting remediation: £4,000-£8,000 to fix violations after launch (2-3x more than building accessibly initially)
Excluded stakeholder impact: Beneficiaries who can't access services, donors who can't contribute, volunteers who can't participate—unquantified but real institutional loss
Funder credibility damage: Questions about organisational competence and values alignment affecting funding decisions beyond accessibility requirements
Legal risk: Potential complaints, regulatory attention, reputational damage if accessibility failures create discrimination claims
Values contradiction exposure: Public documentation that inclusion commitments are rhetoric rather than operational reality
Total cost of inaccessibility: Far exceeds investment in proper compliance.
The Core Insight
For nonprofits claiming inclusion values, website accessibility isn't legal compliance issue—it's institutional integrity evidence.
WCAG standards aren't regulatory burden—they're codified expertise on what makes digital content accessible to people with disabilities.
When organisations meet WCAG AA, they demonstrate inclusion commitments are architectural reality, not mission statement rhetoric.
When organisations defer, ignore, or minimise accessibility, they reveal actual institutional values regardless of stated commitments.
Your Board, funders, beneficiaries, and external observers understand this distinction. Accessible infrastructure builds credibility. Inaccessible infrastructure creates values contradiction undermining everything else you claim institutionally.
The choice isn't between compliance and non-compliance. It's between institutional integrity and performative inclusion rhetoric visible to everyone paying attention.
Need accessibility governance framework demonstrating institutional values commitment? The Blueprint Audit includes WCAG compliance audit, values alignment assessment, and verification methodology enabling Board oversight of accessibility as institutional integrity issue. £2,500 for governance framework preventing values contradiction.
Learn more about the Blueprint Audit
Further reading:
What Genuine Accessibility Changes
Organisations that build accessibility in from the start — rather than auditing and remediating after launch — describe it as something that improves the site for every user, not just those with disabilities. Clear heading hierarchies make content easier to navigate for everyone. Sufficient colour contrast is easier to read in bright light. Keyboard navigation produces better focus states that benefit users on tablets. Accessible design and good design converge more often than they conflict.
The organisations that get this right also describe a secondary benefit: they stop having the retrofit conversation. Accessibility isn't a recurring audit they fail and fix. It's a standard that's maintained because it was built into the foundation.
Frequently asked questions
WCAG — Web Content Accessibility Guidelines — is the international standard for web accessibility published by the W3C. WCAG 2.2 Level AA is the compliance standard required by the Equality Act 2010 for UK organisations providing digital services to the public, which includes virtually all registered charities. Meeting WCAG 2.2 AA means the website is usable by people with visual, hearing, motor, and cognitive disabilities using assistive technologies including screen readers, keyboard navigation, and switch access devices.
The most common failures are: insufficient colour contrast between text and background (failing the 4.5:1 ratio requirement for normal text), images without descriptive alt text, form fields without proper labels, navigation that cannot be operated by keyboard alone, PDFs that are not tagged for screen reader accessibility, video content without captions, focus indicators that are invisible or insufficient, and heading hierarchy that skips levels or uses headings for visual styling rather than document structure. Most of these are fixable without a rebuild but require technical knowledge to address properly.
Yes. The Equality Act 2010 requires organisations providing goods, services, or facilities to the public to make reasonable adjustments for disabled people. For digital services, WCAG 2.2 AA is the accepted standard for what constitutes reasonable accessibility. While there is no specific 'WCAG compliance law', charities that fail to provide accessible digital services risk Equality Act claims, EHRC investigation, and reputational damage. Public sector bodies are subject to the additional Web Accessibility Regulations 2018, but the Equality Act applies to all nonprofits regardless of public funding.
Automated testing tools — WAVE, Axe, Lighthouse — check for programmatic accessibility issues: missing alt text, insufficient contrast ratios, form label problems, and structural HTML issues. They catch approximately 30-40% of accessibility failures. Manual testing checks for issues automated tools cannot detect: whether alt text is actually descriptive, whether keyboard navigation is logically ordered, whether focus management is appropriate, whether content is understandable to users with cognitive disabilities, and whether the site is usable in practice with screen reader software. Genuine WCAG compliance requires both.
WCAG compliance is not an aesthetic constraint — it is a design requirement that produces better outcomes for all users, not just disabled users. High contrast design is more readable in bright sunlight. Clear heading hierarchy makes content scannable. Keyboard-navigable forms work better on television remotes and gaming controllers. Properly labelled form fields reduce errors for all users. The most common misconception is that accessible design means plain or unattractive design — in practice, organisations with strong brand identities consistently achieve WCAG compliance without compromising visual quality.
An accessibility statement is a published page documenting the website's current accessibility compliance level, known accessibility issues, the standard it aims to meet, and a mechanism for users to report accessibility problems. Public sector organisations are legally required to publish accessibility statements under the Web Accessibility Regulations. While the regulations don't apply directly to nonprofits unless they receive significant public funding, publishing an accessibility statement is considered best practice, demonstrates accountability, and provides a mechanism for identifying and addressing issues before they become complaints.
The most reliable accessibility testing involves disabled users who use assistive technology daily — their lived experience reveals usability problems that automated tools and non-disabled testers miss. Recruit testers through disability organisations, through the organisation's own beneficiary networks where appropriate, or through specialist accessibility testing services. Testing should cover: a screen reader user attempting to navigate and complete key tasks, a keyboard-only user attempting the same tasks, and a user with cognitive disabilities or low literacy attempting to understand key content. Each group reveals different categories of failure.
A basic automated audit using free tools costs only time and produces a list of technical failures to address. A manual audit by an accessibility specialist costs £2,000-£8,000 depending on site size and typically includes: automated scan results, manual testing against WCAG 2.2 AA success criteria, user testing with assistive technology users, a prioritised remediation list, and recommendations for preventing future failures. Charities can often access subsidised accessibility auditing through sector bodies and technology grant programmes. The audit cost is almost always lower than the remediation cost it prevents by identifying issues early.
Partially. Template websites often have structural accessibility failures — inadequate heading hierarchy, poor focus management, inaccessible navigation patterns — that cannot be fixed through content changes alone. Achieving genuine WCAG 2.2 AA compliance on an inaccessible template typically requires significant custom development. At that investment level, the cost-benefit of staying on the template diminishes significantly. The most cost-effective path to accessibility compliance for nonprofits with templates is often a rebuild on a platform where accessibility is built into component design from the start.
Maintaining compliance requires: an accessibility review as part of the publishing workflow for new content (is alt text added to all images, are new videos captioned, do new forms have proper labels), periodic full site audits — at least annually — to catch issues introduced by content updates, a process for responding to accessibility complaints, and accessibility training for all staff who publish content. Accessibility is not a one-time project — it deteriorates with every content update made by someone without accessibility awareness, and requires ongoing governance to maintain.
