Nonprofit Website Accessibility Checklist

Website accessibility can involve everything from keyboard navigation and donation forms to PDFs, testing, and visitor feedback. This checklist organizes those areas into eight practical categories so your nonprofit can work through them one at a time.

For the legal background and reasoning behind each area, see our nonprofit website accessibility guide. Here, the focus is action: what to review and what to prioritize first.

1. Confirm your legal and regulatory starting point

This can help you understand which technical standards, deadlines, or additional requirements may be relevant as you work through the checklist.

• Review whether the ADA applies to your nonprofit, including whether your website could be treated as a place of public accommodation under Title III.
• Check whether your organization receives federal financial assistance that could trigger Section 504's website accessibility requirements, particularly if any of that funding comes from HHS.
• Decide which WCAG version and level your organization will use as a working target, since most of the technical items below are easier to evaluate against a specific standard.
• Note any state law, government contract, or grant-specific accessibility requirements that may apply on top of federal rules.

2. Navigation and keyboard access

• Test your main navigation, menus, and any modal windows or dropdowns using only a keyboard.
• Confirm every interactive element has a visible focus indicator so keyboard users can see where they are on the page.
• Check that no interactive component traps keyboard focus or prevents a user from moving forward or backward.
• Make sure a logical tab order follows the visual layout of each page.

3. Images, headings, and page structure

• Add meaningful alternative text to informative images, describing their purpose rather than just their content.
• Mark purely decorative images so assistive technology can skip over them.
• Use headings that describe the page structure in a logical order, rather than choosing heading levels for visual style.
• Give each page a clear, descriptive page title.
• Make sure links and buttons have clear, descriptive names so visitors can understand their purpose without relying only on surrounding visual context.

4. Color and contrast

• Check text and background color combinations against your working WCAG contrast target.
• Review contrast on buttons, form fields, and other interface elements, not just body text.
• Confirm that important information, such as required fields or error states, doesn't rely on color alone.

5. Forms, donations, and multi-step processes

Forms tied to important visitor tasks, such as donations, registrations, and applications, are often where accessibility barriers most directly affect your core outcomes. Reviewing your donation form for common accessibility barriers covers this in more depth.

• Confirm every form field has a clear, programmatically associated label.
• Write error messages that explain what went wrong and how to fix it, rather than relying only on a red outline or icon.
• Test your full donation flow using a keyboard and, where possible, a screen reader, from selecting an amount through confirmation.
• Do the same for volunteer, membership, event, and program application forms, especially multi-step ones.
• Include third-party forms and embedded platforms in your review because donors and applicants still interact with them as part of the overall journey, even when you don't control the underlying code.

6. Documents and multimedia

Nonprofits often publish annual reports, financial disclosures, and program materials as PDFs.

• Identify which PDFs are used to apply for, access, or participate in a program, and review those first.
• Confirm important PDFs have real, searchable text rather than existing only as a scanned image.
• Add captions to video content, and consider audio description where information is communicated only visually.
• Where practical, consider moving frequently updated PDF content to an accessible web page instead.

7. Testing and ongoing maintenance

Testing is most useful as an ongoing habit rather than a one-time project. Automated vs. manual accessibility testing explains what each method can and cannot catch, and how to build a lightweight testing workflow.

• Run a quick automated scan, such as Clym's Scanner, to identify potential rule-based issues and get a starting list.
• Do a keyboard-only pass and a basic screen reader spot-check on your highest-stakes pages.
• Prioritize issues that block someone from completing an important task before addressing lower-impact issues.
• Retest after any redesign, CMS change, or new third-party integration, not just once a year.
• Build basic accessibility checks, such as alt text and heading structure, into your normal content publishing process.

8. Accessibility statement, feedback, and ownership

• Publish an accessibility statement that reflects your organization's actual accessibility status, rather than making unsupported claims.
• Give visitors a clear way to report accessibility barriers they encounter.
• Assign someone on your team to review and respond to accessibility feedback on an ongoing basis.