Is Your Nonprofit Website Accessible? How to Show Compliance

If you run a nonprofit website, you might get board members or other curious stakeholders asking whether your site is accessible. 

How do you answer that question? Even if you built your site with accessibility in mind and regularly test it and fix bugs, how do you prove it's accessible? The question almost becomes a trap — causing anxiety and internal friction. 

What you need is a pre-packaged, definitive, and professional response. Something that says, “We have a strategic handle on this. Here is the documentation.”

I recommend you answer with an Accessibility Compliance Report (ACR) and an Accessibility Statement.

What is an Accessibility Compliance Report?

Accessibility Compliance Reports (ACRs) are a formal way to demonstrate how well your website aligns with accessibility standards.

ACRs list every rule from a set of accessibility guidelines (e.g., WCAG, Section 508, EN 301 549) and indicate whether the website passes, partly passes, or fails each rule. 

To create an ACR, an accessibility expert needs to comb through a representative sample of pages from your website, looking for accessibility bugs. When they find a bug, they indicate which guideline it relates to and how and where it fails. 

Here is an example of what you might see in an ACR (from the ACR for our website):

This website Partially Supports WCAG Success Criterion 3.1.1 Language of Page. While the majority of the website is in English and appropriately marked in code, the page Configurando campos UNIÓN en Drupal Search API is written primarily in Spanish but is still programmatically marked as English.

Here are a few full ACRs to get an idea of what they look like in their entirety:

• Github.com’s ACR
• Deque’s Product Docs Site ACR
• Google’s ACR for Gmail
• Capellic.com’s ACR (the site you are looking at right now) 

While anyone can technically make an ACR, I highly recommend partnering with an accessibility expert outside your organization.

Since we can’t see our own blind spots, it can be difficult to objectively review our own work. Much like standard QA best practices for new features, where we never have a developer QA their own work. A third-party audit provides the credibility needed to validate your site's performance and demonstrate a strong commitment to accessibility.

What is a Voluntary Product Accessibility Template?

VPAT stands for “Voluntary Product Accessibility Template” and is, technically, just a special template for making ACRs.

The federal government, along with the Information Technology Industry Council (ITI), established VPATs to provide a common format for documenting ACRs. They help federal agencies evaluate the accessibility of products and services.

Over time, other procurement offices (such as those in the education or grant-making space) began requesting ACRs in the VPAT format from product owners to demonstrate that their products were accessible.

You can see what VPATs look like on ITI’s VPAT page.

Does my website need a VPAT?

In the nonprofit website space, the VPAT format is usually required only for organizations that sell a version of their platform to the federal government or other procurement offices. 

For example, you might need one if you provide a "site-in-a-box" platform to a network of local chapters, or if you sell a proprietary digital learning tool to school districts. In these cases, the other organization is buying your tech and needs to validate its accessibility before they can legally or ethically deploy it. And if that organization is the federal government, they might ask for an ACR that uses the VPAT format. 

If you aren’t selling parts of your website to someone else, you probably don’t need to worry about VPATs. 

Does my website need an ACR?

While you probably don’t need to do anything with VPATs, it is worthwhile to create an ACR.

Outside of proving the accessibility of your site, ACRs do two things:

• It builds trust with your users, donors, and partners. Funders may want the organizations they partner with to prioritize diversity, equity, and inclusion, and having a public-facing ACR is a strong signal that you live those values.
• It empowers your users with disabilities. ACRs tell your users exactly which parts of your site are not yet fully accessible. This transparency shows respect for their time.

You could use a VPAT as the template for your ACR, but I find the VPAT format pretty unreadable and with way too much preamble. I recommend building out your ACR in a simpler, plain-language format. 

What is an Accessibility Statement page?

Since ACRs can be long and detailed and only show the status of your website at a certain point in time, an Accessibility Statement is the place where you can talk more generally about your accessibility process, goals, and ongoing testing procedures.

Accessibility Statements contain things like:

• Contact information for users to share accessibility-related feedback or request information in a different format. This can be a form, email, or phone number.
• A description of the methods you took to ensure the site was accessible. This should be detailed and timestamped. Don't just say "we are accessible." Say, "On October 12, 2025, our site was audited by [Firm Name/Internal Team] against WCAG 2.2 AA standards." Include the tools used in the assessment (e.g., automated testing with Axe DevTools, manual screen reader testing with JAWS, manual keyboard-only testing) and the accessibility standard applied (usually WCAG 2.2 AA). The gold standard here is to provide a link to an Accessibility Compliance Report.
• A "known issues" log. List the things that you know are not accessible. Don’t skip this part! Accessibility is a journey. Be transparent and proactive. When you list a limitation, also note what you are doing to resolve it. IE.“Not all of our embedded podcasts have transcripts. We are in the process of creating transcripts and plan to be complete by August, 2026.”
• A statement of commitment to accessibility. If you are in the nonprofit space and inclusion is part of your mission statement or core values, you can speak to how ensuring your site is accessible is a demonstration of those values.

A few websites with Accessibility Statements that we think are good examples:

• On Scope’s Accessibility Statement page, they list known accessibility issues with their site and state that they are in the process of fixing them. They also provide links to instructions on using accessibility features already on your computer.
• On The British Museum’s Accessibility Statement page, they provide multiple ways to contact them about any accessibility-related issue. They also provide a list of the ways their website is not fully compliant, in both plain language and more technical terms.
• On The Financial Times Accessibility Statement page, they link to an ACR from the Digital Accessibility Centre. Users can see when the site was audited, that it was audited by a third-party (not just their in-house developers), and the issues found during the audit.
• Our Accessibility Statement page on capellic.com. 

How do you get started proving your site is accessible?

1. The easiest way to start is to create a new page on your site titled “Accessibility Statement” and put a link to it in your global footer.
2. Use W3C WAI’s Accessibility Statement Generator to create a first draft for your statement. Update its output to be tailored to your organization and audience.
3. Partner with another organization to conduct an accessibility analysis and produce an ACR, and post it publicly on your Accessibility Statement page. Capellic can help with this! We have an accessibility evaluation and roadmapping service that delivers both an ACR and a roadmap for fixing the issues we find. Organizations like Deque and Perkins School for the Blind also offer excellent services.
4. Extra points for going out and doing some user accessibility testing. While expert accessibility testing is great, nothing compares to testing with real people who regularly use assistive technology to navigate the web.
5. Lastly, decide on a cadence for continually reviewing your site's accessibility. Usually, organizations make a new ACR annually or whenever a major new version of their website is released.

You can do it!

When you document the accessibility of your website, you are not only building trust and empathy with your users, but you are highlighting the importance of accessibility on the web. 

And the web needs your help.