8 min read
What Nonprofits Need to Know About ADA Compliance When Buying Software
Most nonprofit leaders think of ADA compliance as a front-door problem — the donation page, the event calendar, the contact form — but the software your staff opens every morning, the portal your board uses to review materials and vote, and the volunteer system your team relies on week after week all carry the same legal and ethical weight. In some ways that internal software carries even more, because it shapes the experience of the people inside your organization, not just the visitors passing through.
In another article, we looked at the inclusion case for accessible board tools. This one is about procurement: what to evaluate before you sign, which questions actually tell you something, and what vendor responses reveal about how seriously they treat this.
Buy inaccessible software, and you have essentially handed the problem to your vendor’s roadmap. You cannot fix a third party’s product. That is the central issue, and it is why accessibility has to be a buying criterion, not something you circle back to after deployment.
Nonprofit Software Procurement: Why Accessibility Is a Buying Decision, Not a Design Problem
Your own website is something you control. If the donation page has an accessibility problem, your team can fix it or hire someone to do so. With SaaS software, that is not how it works. You get what the vendor has built, and changes happen on their schedule.
That dynamic matters a lot when you are evaluating board management software, volunteer platforms, or donor management tools. Switching costs are significant: data migration, retraining, contract exit, and the disruption of changing platforms mid-cycle. An organization that buys inaccessible software today and later recruits a board members who uses a screen reader, or hires a staff member who navigates by keyboard, may not have a clear path forward.
For nonprofits with federal funding, there is an added layer. The Department of Justice’s 2024 Title II rulemaking extended web and application accessibility requirements for public entities, and depending on your grand agreements, those obligations may reach your organization. If you have specific questions about your situation, talk to legal counsel familiar with nonprofit compliance.
Vetting accessibility before you sign is cheaper, faster, and less disruptive than trying to address it after the fact.
ADA, WCAG, and Section 508 Explained: What These Standards Mean for Software You Buy
These terms come up in vendor conversations regularly, and they are not always well-explained. Here is what each one means and why it matters when you are buying software.
| Standard | What It Is | Why It Matters for Nonprofits |
| ADA (Americans with Disabilities Act) | Federal civil rights law prohibiting discrimination based on disability. Title 1 covers employment, Title II covers government entities, Title III covers places of public accommodation. | Most nonprofits face exposure under Title III and, if federally funded, Title II obligations. The ADA does not name a technical standard, but courts and regulators increasingly point to WCAG. |
| WCAG 2.1 | Web Content Accessibility Guidelines from the W3C, published in 2018. Add criteria for mobile accessibility and cognitive disabilities. Level AA is the widely accepted minimum. | WCAG 2.1 AA is the floor. A vendor who cannot confirm this level of conformance is a procurement risk. |
| WCAG 2.2 | The current version, published in October 2023. Adds refinements for users with cognitive and learning disabilities. | WCAG 2.2 AA is current best practice. Ask vendors which version they target and at what level. “We follow WCAG” without specifics is not a useful answer. |
| Section 508 | A federal procurement standard for electronic and information technology. Applies directly to federal agencies. | Not binding on most nonprofits, but commonly used as a benchmark in NGO and institutional procurement. Worth understanding if your organization works with federal partners. |
| VPAT (Voluntary Product Accessibility Template) | A structured document vendors use to self-report their conformance with accessibility standards. | This is where any serious vendor evaluation starts. A VPAT is a self-assessment, not a certification, but a detailed, current one tells you a lot. An absent or outdated one tells you more. |
Who Needs Accessible Software: Staff, Volunteers, and Board Members
Procurement teams often frame this as a board member issue and stop there. The actual scope is wider, and the people who get overlooked tend to be the ones most affected when something is not accessible.
- Board members. The board portal is the core use case, and it is not a light one. Members need to read and navigate documents, review agenda materials, participate in voting, follow discussion threads, and find archived records through a document center. Every piece of that has to work with assistive technology, independently, without requiring staff to step in. If it does not, the software is not accessible.
- Staff. ADA Title 1 requires reasonable accommodation in the workplace. If the tools your administrative team uses to manage board operations are not accessible, you may be looking at accommodation requests or a forced platform change. Staff accessibility is a compliance issue, not just a preference.
- Volunteers. Volunteer management tools tend to get evaluated last, but volunteers span a wide range of ages, tech comfort levels, and physical ability. The same standard that applies to staff-facing software should apply here too.
- Remote and async participants. Accessibility gaps get worse in virtual environments. Screen reader support, caption availability, and keyboard navigation all matter more when participation is fully digital. A board member reviewing documents on a tablet or joining a meeting through a video integration is working in a different environment than someone sitting in the room, and the software has to account for that.
Your full user population is broader than your full-time staff. Keep that in mind when you are scoping what accessible software actually needs to cover.
Vendor Accessibility Checklist: Questions to Ask Before You Sign
Work through these with every vendor, and write down what they say. The answers, and the way they answer, are both useful data.
- Do you have a current VPAT?
- When version of WCAG does your product confirm to, and at what level (A, AA, or AAA)?
- Has your product been audited by a third-part accessibility consultant, or this self-reported?
- How do you handle accessibility bug reports from users? What is your typical response time?
- What does your accessibility roadmap look like for the next 12 months?
- Does your mobile app meet the same accessibility as your web interface?
- Are keyboard navigation and major screen readers (NVDA, JAWS, VoiceOver) fully supported?
- Do your embedded video or meeting integrations support closed captions?
- Are exported documents (PDFs, board packets) tagged for screen read compatibility?
A vendor who answers these specifically and without friction has put real work into accessibility. Hedged or defensive responses are worth noting.
Reading a VPAT: Red Flags and What “We’re Working on It” Really Means
Getting a VPAT is step one. Knowing what to look for in it is step two.
- No VPAT at all. For any SaaS product in 2025 or later, this is a significant problem. A vendor should be able to document where they stand, even if the answer is not flattering.
- A VPAT dated two or more years ago. Software changes constantly. A conformance document from 2022 does not reflect what you are actually buying today. Ask when it was last updated and whether it covers the current release.
- “Fully compliant” with no supporting detail. A vendor who claims full compliance without documentation should be asked to back that up. Broad claims without specifics tell you very little.
- “We’re working on it” as a complete answer. That is only acceptable if it comes with a specific roadmap, named features, and a realistic timeline. On its own, it is likely a deflection.
- Accessibility showing up only in the legal disclaimers. If the sole reference to accessibility in a vendor’s documentation is a liability carve-out in the terms of service, that tells you where it lands on their internal priority list.
If your current vendor falls short on any of these, put it in writing. Refer to your procurement standards, request a remediation timeline, and check whether your contract includes accessibility warranties. That paper trail matters, especially for organizations with federal funding obligations.
Asking These Questions is Part of the Job
Vendors take accessibility seriously when buyers require it. When nonprofits make accessibility a real evaluation criterion rather than a checkbox, the market moves. You are not being difficult by asking; you are doing what any responsible buyer should do.
The point is not to pass an audit. It is to ensure that every person in your organization, whatever device they use or assistive technology they rely on, can participate without workarounds. That applies to your donation page. It applies to your board portal too.
FAQs
ADA Compliance Software Frequently Asked Questions
Are nonprofits required to comply with the ADA when purchasing software?
It depends on how your organization is funded and what it does. Nonprofits that receive federal funding or operate as places of public accommodation have clear obligations. Organizations without direct legal exposure still have a responsibility to ensure their tools do not create barriers for staff, volunteers, or board members with disabilities. If you have specific concerns about your situation, a lawyer familiar with nonprofit compliance can give you a clear answer.
What is a VPAT and should I ask software vendors for one?
A VPAT is a document vendors use to self-report how their product conforms to accessibility standards like WCAG. You should absolutely ask for one, and check when it was last updated. It is not a third-party certification; it is a self-assessment. A detailed, current VPAT is a sign the vendor is paying attention. An outdated or missing one is a reason to push harder before you commit.
What is the difference between WCAG 2.1 and WCAG 2.2, and which should nonprofit software meet?
WCAG 2.1, published in 2018, added criteria for mobile accessibility and cognitive disabilities. WCAG 2.2, published in 2023, refined those further, with particular focus on users with cognitive and learning disabilities. For software you are buying today, WCAG 2.1 AA is the minimum; WCAG 2.2 AA is what a vendor actively investing in accessibility should be targeting. When you ask, get the specific version and conformance level in writing.
