Nonprofit Website Accessibility: U.S. Guide for 2026

More than 70 million adults in the United States report living with a disability, and accessibility barriers remain widespread online. The 2025 WebAIM Million report found detectable WCAG failures on 94.8% of the one million home pages it tested. Because automated testing can only identify some accessibility problems, the actual number of websites with accessibility barriers is likely higher.

For nonprofits, inaccessible digital experiences can directly affect the people an organization is trying to reach. A donor may be unable to complete a contribution, a volunteer may get stuck in a registration form, or a program applicant may not be able to access important information or services.

Website accessibility can also involve several different legal and technical frameworks. The Americans with Disabilities Act (ADA), Section 504, Section 508, and the Web Content Accessibility Guidelines (WCAG) are related, but they are not interchangeable and do not apply to every nonprofit in the same way.

This guide explains what U.S. nonprofits should know about website accessibility in 2026, which requirements may be relevant, where accessibility barriers commonly occur, and how organizations with limited resources can decide what to address first.

What does website accessibility mean for a nonprofit?

Website accessibility means designing and maintaining digital content so people with disabilities can use it and achieve the same practical outcomes as other visitors.

For a nonprofit, those outcomes may include reading information about programs, applying for services, completing a donation, registering for an event, volunteering, accessing educational resources, watching a video, downloading a document, or contacting the organization.

Consider a few common nonprofit journeys. A supporter using a screen reader needs to be able to understand and complete a donation form. Someone navigating only with a keyboard should be able to register for an event without becoming trapped in a menu or form. A person with low vision needs sufficient contrast to read eligibility information, while someone who is deaf or hard of hearing may rely on captions to understand a video.

Accessibility therefore isn’t only about individual website elements. It is about whether people can successfully complete the activities the website exists to support.

Which accessibility requirements may apply to your nonprofit?

There is no single accessibility rule that applies identically to every U.S. nonprofit. Which requirements matter depends on factors such as what the organization does, whether it receives government funding, how many people it employs, whether it provides public-facing services, and whether it works with government agencies.

More than one framework may be relevant, and state laws, contracts, grant conditions, or sector-specific rules may create additional requirements. Organizations with questions about their particular legal obligations should review the applicable rules and consider qualified legal advice.

Does the ADA apply to nonprofit websites?

Nonprofit status does not create a general exemption from the Americans with Disabilities Act.

For organizations with 15 or more employees, ADA Title I covers employment discrimination and can be relevant to digital employment processes such as online job applications.

For public-facing nonprofit websites, ADA Title III is often more relevant. Title III covers qualifying places of public accommodation. Nonprofit organizations can fall within its scope depending on their activities and the type of services they provide.

Website accessibility under Title III is less straightforward because there is currently no federal Title III regulation establishing a single technical website standard comparable to the rule that exists under Title II. Courts have also taken different approaches to how Title III applies to websites. That does not mean nonprofits should assume their websites fall outside the ADA. The Department of Justice has consistently taken the position that the ADA’s accessibility requirements apply to the goods, services, privileges, or activities offered by covered public accommodations online.

What about the DOJ’s Title II website rule?

In 2024, the Department of Justice adopted specific web and mobile accessibility requirements for state and local governments under ADA Title II. The rule uses WCAG 2.1 Level A and AA as its technical standard.

In April 2026, DOJ extended the compliance deadlines. State and local government entities with populations of 50,000 or more now have until April 26, 2027, while smaller public entities and special district governments have until April 26, 2028.

Title II does not apply to a private nonprofit simply because it is a nonprofit. However, the rule also addresses web content and mobile apps public entities make available through contractual or other arrangements. That makes it important for nonprofits delivering digital services on behalf of government entities to review their contracts and accessibility responsibilities.

What WCAG means for nonprofits

The Web Content Accessibility Guidelines (WCAG) are technical standards published by the World Wide Web Consortium (W3C). They explain how digital content can be made more accessible to people with visual, auditory, physical, cognitive, neurological, and other disabilities.

WCAG itself is not a U.S. law. However, it is frequently incorporated into regulations, contracts, procurement requirements, policies, and settlements, making it the main technical reference point for web accessibility.

WCAG is based on four principles, commonly abbreviated as POUR. Web content should be:

• Perceivable: information can be perceived in different ways.
• Operable: users can navigate and interact with the interface.
• Understandable: content and interactions are clear and predictable.
• Robust: content works reliably with browsers and assistive technologies.

WCAG has three conformance levels: A, AA, and AAA. Level AA is the level most organizations encounter when accessibility requirements reference WCAG.

It is also important to distinguish WCAG 2.1 from WCAG 2.2. Major current U.S. federal web accessibility regulations, including the DOJ Title II rule and the HHS Section 504 requirements discussed below, incorporate WCAG 2.1 Level A and AA. WCAG 2.2 is the newer W3C Recommendation and adds additional accessibility criteria, so organizations may choose WCAG 2.2 AA as a forward-looking technical target where no applicable law, contract, or funding requirement specifies another version.

Conformance with WCAG should not be presented as a guarantee of ADA compliance. WCAG provides the technical benchmark; legal obligations depend on the circumstances of the organization.

Section 504 and nonprofits receiving federal funding

Section 504 of the Rehabilitation Act prohibits disability discrimination by programs and activities receiving federal financial assistance.

This makes Section 504 especially important for nonprofits because federal grants, cooperative agreements, and other forms of federal financial assistance can trigger obligations that would not apply simply because an organization has nonprofit status.

Requirements can vary depending on which federal agency provides the funding, so organizations should identify the source of their federal assistance rather than assuming the same requirements apply to every grant.

Important 2026 update for HHS-funded nonprofits

One of the most significant developments for nonprofits involves organizations receiving financial assistance from the U.S. Department of Health and Human Services.

HHS’s updated Section 504 regulations include specific accessibility standards for web content and mobile applications using WCAG 2.1 Level A and AA.

In May 2026, HHS extended the applicable compliance dates by one year:

• recipients with 15 or more employees now have until May 11, 2027;
• recipients with fewer than 15 employees now have until May 10, 2028.

This can be particularly relevant to nonprofit hospitals, community health centers, primary care providers, health and human-services organizations, and other nonprofits receiving HHS financial assistance.

The HHS rule also contains specific exceptions, so nonprofits should review the actual regulation and their circumstances rather than treating WCAG 2.1 AA as an unconditional rule for every piece of historical or third-party content.

When Section 508 matters to nonprofits

Section 508 of the Rehabilitation Act directly governs federal agencies and the information and communication technology they develop, procure, maintain, or use.

It does not generally apply to a nonprofit simply because the organization receives federal funding. However, it can become relevant when a nonprofit develops or supplies technology, software, websites, or other digital services to a federal agency.

Federal procurement requirements may require vendors to document how their products or services conform to applicable Section 508 standards. This information is commonly provided through an Accessibility Conformance Report (ACR), often created using a Voluntary Product Accessibility Template (VPAT).

The Revised Section 508 Standards incorporate WCAG 2.0 Level A and AA requirements for applicable web content.

For nonprofits without a federal ICT procurement relationship, Section 508 will usually be less directly relevant than the ADA or Section 504.

Where accessibility barriers commonly appear on nonprofit websites

Accessibility problems can occur anywhere on a website, but several areas repeatedly create barriers.

Navigation and keyboard use. Menus, buttons, modal windows, dropdowns, and other interactive components should be usable without requiring a mouse. Users should also be able to see where keyboard focus is located.

Images and page structure. Informative images need meaningful alternative text, while headings should describe the structure of the page rather than simply being used for visual styling.

Color and contrast. Text, buttons, form controls, and information presented over images need sufficient contrast. Important meaning should not depend on color alone.

Forms and error messages. Fields need programmatically associated labels, instructions should be understandable, and errors need to explain what went wrong rather than relying only on a red outline or icon.

Third-party services. Donation platforms, event registration systems, membership tools, scheduling services, chat tools, and embedded forms can introduce accessibility barriers even when the nonprofit’s own website is accessible.

Documents and multimedia. PDFs, videos, audio content, and other downloadable resources require their own accessibility considerations.

Prioritize donation, application, and registration journeys

For many nonprofits, forms are where website accessibility has the most direct practical impact.

A donation process should be usable with a keyboard and assistive technology from beginning to end. Fields should have clear labels, amount selectors and recurring-donation controls should communicate their purpose and state, and validation errors should explain how users can correct a problem.

The same principles apply to volunteer registrations, membership forms, event bookings, newsletter sign-ups, and applications for programs or services. Multi-step processes deserve particular attention because accessibility barriers may not appear until later in the journey.

Third-party platforms should be included in the review. A nonprofit may not control a fundraising provider’s source code, but the vendor still forms part of the visitor’s experience. Ask prospective providers about their accessibility testing, applicable WCAG targets, accessibility documentation, and process for reporting and remediating issues.

CAPTCHAs and other anti-bot mechanisms should also be reviewed so they do not create an unnecessary barrier to completing a form.

Don’t overlook PDFs and video

Nonprofits frequently publish annual reports, financial documents, research, program information, event materials, and downloadable forms as PDFs.

Where practical, important information can be easier to access and maintain when published as an accessible web page rather than only as a PDF. When a PDF is necessary, review its document structure, reading order, alternative text, form controls, and whether the text is searchable rather than existing only as a scanned image.

Video content needs similar attention. Captions are important for people who are deaf or hard of hearing, while audio description may be needed when important information is communicated visually but not through the audio. Media-player controls should also be operable by keyboard.

Automated accessibility testing vs. manual testing

Automated testing is an efficient way to identify many accessibility problems across a website. A scanner can flag issues such as missing alternative text, certain color-contrast failures, missing form labels, and some structural problems.

But automation can only detect part of the accessibility picture.

A tool cannot reliably determine whether alternative text actually communicates the purpose of an image, whether the instructions on a page make sense, whether a screen-reader user can comfortably complete a complex donation process, or whether a custom interface behaves logically with assistive technology.

That is why a practical accessibility program combines automated testing with manual review, including keyboard testing and appropriate assistive-technology testing. Where feasible, feedback from people who use assistive technologies can reveal barriers that automated rules and scripted tests do not identify.

No automated scan should be presented as proof that a website is fully accessible or legally compliant.

Where accessibility widgets fit

Accessibility widgets can give visitors additional control over aspects of their browsing experience, such as text presentation, contrast, spacing, and navigation preferences.

These options can be useful for people who choose to use them, but a widget does not replace the underlying work required to create accessible website content and functionality.

A widget cannot independently correct poorly structured code, make an inaccessible form fully usable, write meaningful alternative text, or add captions that do not exist. It should therefore be treated as one component of a broader approach that includes accessible design and development, content practices, testing, and remediation.

Clym’s Accessibility Widget gives visitors options to customize aspects of content presentation and navigation as part of that broader accessibility approach.

How nonprofits can prioritize accessibility with limited resources

Accessibility can feel difficult for a nonprofit with a small website team or limited budget, particularly when an initial review produces a long list of issues. Trying to correct everything simultaneously is rarely the most practical approach.

A simpler framework is:

1. Identify major barriers.
Use automated testing alongside a basic manual review of your most important pages to understand where problems are concentrated.

2. Prioritize critical user journeys.
Focus first on activities that directly affect access to your organization, such as applying for services, donating, registering for events, volunteering, or contacting your team.

3. Address blocking issues first.
A form that cannot be completed using a keyboard is generally more urgent than a minor issue on a rarely visited archive page.

4. Build accessibility into normal workflows.
Train staff who publish website content and make alternative text, headings, captions, document accessibility, and basic accessibility checks part of the publishing process.

5. Test and review continuously.
Accessibility can change as content, templates, software, and third-party integrations change. Establish a reasonable review cadence and test again after significant redesigns, CMS changes, new features, or vendor integrations.

This makes accessibility an ongoing operational practice rather than a large remediation project that has to be restarted every few years.

Publish an accessibility statement and provide a feedback route

Testing will not identify every barrier experienced by real users. Organizations should also make it easy for visitors to understand their accessibility approach and tell them when something is not working.

An accessibility statement can describe the organization’s accessibility goals or technical target, identify known limitations where appropriate, explain how visitors can request assistance, and provide contact information for reporting accessibility problems.

Statements should reflect the organization’s actual accessibility status rather than making unsupported claims about compliance.

Clym’s Accessibility Statement solution can support nonprofits in creating, publishing, and maintaining accessibility information, while Accessibility Issue Reporting provides a structured way for visitors to report barriers and for organizations to track and respond to those reports.

Together, these tools can support documentation and ongoing feedback, but they do not replace accessibility testing or remediation.

Nonprofit website accessibility checklist

Use this checklist as a starting point rather than a substitute for a complete accessibility evaluation:

• Test important website journeys using keyboard navigation.
• Confirm interactive elements have a visible focus indicator.
• Provide meaningful alternative text for informative images.
• Use descriptive headings in a logical page structure.
• Review text and interface color contrast.
• Give form fields clear, programmatically associated labels.
• Make validation and error messages understandable without relying on color.
• Test donation, registration, application, and volunteer forms from beginning to end.
• Provide captions for video and review multimedia accessibility.
• Review important PDFs and downloadable documents.
• Include third-party platforms and embedded tools in accessibility testing.
• Combine automated checks with appropriate manual testing.
• Retest after major website, template, CMS, or vendor changes.
• Give users a clear way to report accessibility barriers.

A more detailed audit will involve additional WCAG criteria and testing methods, but these checks can help a nonprofit identify some of the most common and consequential barriers first.

Conclusion

Nonprofit status does not automatically determine whether a website is subject to accessibility requirements. The ADA, Section 504, Section 508, state requirements, government contracts, and funding arrangements can all affect which obligations apply.

What is consistent is the practical value of making digital services usable by more people. For nonprofits, accessibility directly affects whether someone can find information, receive a service, complete an application, volunteer, participate in an event, or support the organization.

The most practical approach is to understand which requirements may apply, identify barriers in the user journeys that matter most, address high-impact issues first, and build accessibility into ongoing website operations.

Clym’s accessibility solutions can support different parts of that process, including testing, visitor customization, accessibility statements, and issue reporting, alongside the underlying design, development, content, testing, and remediation work required to improve digital accessibility.