An accessible nonprofit website lets people with disabilities use the services it offers: finding help, learning about a program, volunteering, or donating. A practical first review follows those tasks from start to finish, including any external forms and documents. Start with the pages people depend on most. Check keyboard operation, form errors, readable content, and the handoff to outside tools. Record what prevents a task from being completed, then assign each repair and test it again. This checklist is a starting point, not a full accessibility assessment. W3C's Easy Checks explains that passing a preliminary review does not establish that a site is accessible.
Choose the tasks you will test
For a small nonprofit, a useful starting set is: find a service, contact the organization, sign up to volunteer, and make a donation. Choose the tasks your site actually supports. Include the homepage, relevant content pages, forms, and any confirmation screens.
Write down the page, device, browser, and steps used when recording a problem. This makes a finding easier for a developer to reproduce. For payments, use the provider's test environment where available rather than experimenting with live charges.
Check keyboard navigation and focus
Use Tab and Shift+Tab to move between controls. Some components, such as radio groups and tabs, use arrow keys within the group. Test activation as well as navigation: Enter for links, and the appropriate Enter or Space behavior for buttons and other controls. W3C documents these conventions in its keyboard interface guidance.
Look for a visible focus indicator and a sensible sequence. Make sure a sticky header or banner does not hide the focused control entirely; see W3C's focus visibility requirement.
A modal dialog normally keeps focus inside while it is open. That is different from a keyboard trap: users must be able to close the dialog using the keyboard and return to a sensible place. W3C's modal dialog pattern describes the expected behavior.
Check forms and error recovery
For donation, contact, and volunteer forms, prefer persistent visible labels that identify each field. A placeholder disappears during entry and should not be the field's only label. A developer should verify the accessible name and its association with the control; clicking a label is only a preliminary check. See W3C's form labeling guidance.
Submit an incomplete test form. Can you identify what went wrong and how to correct it? Errors should be expressed in text, not only in color, and associated with the relevant fields. Depending on the form, an error summary, focus movement, or an announced status can help people find the problem. Moving focus to the first error is not the only valid approach. See W3C's user notification guidance.
Check readable text, zoom, and images
| Check | What to look for |
|---|---|
| Text contrast | WCAG AA uses at least 4.5:1 for normal text and 3:1 for large text, with specified exceptions |
| Text resizing | At 200%, text should remain usable without losing content or functionality, subject to the criterion's exceptions |
| Reflow | Test narrow layouts and zoom separately; enlarging text alone does not establish that the layout reflows |
| Image alternatives | Convey the image's meaning or function in context; decorative images generally use an empty alternative |
For contrast, “large” means at least 18-point regular or 14-point bold text under the criterion. A logo is not treated like ordinary body text. Consult W3C's contrast guidance for definitions and exceptions.
The text resizing and reflow checks address different issues. As a practical reflow test, examine a layout at a width equivalent to 320 CSS pixels; content that genuinely needs two-dimensional layout has exceptions.
An image used as a button needs a name describing the action, while a chart may need a fuller text explanation. Avoid adding descriptions that repeat adjacent text without adding meaning. W3C's images tutorial explains these distinctions.
Include content and outside tools
Check headings and labels for clarity: they should describe the section or control, not simply provide visual styling. W3C explains the intent in Headings and Labels.
If a video contains speech or meaningful sound, check the captions for accuracy and synchronization. Automatically generated captions need review. See W3C's prerecorded captions guidance.
Follow links to donation platforms, embedded forms, and essential PDFs. Record barriers there too. If an outside supplier controls the problem, assign someone to contact them and evaluate an accessible alternative. A clean homepage does not help a visitor who cannot finish the next step.
Turn findings into a repair plan
Prioritize barriers that prevent essential tasks, then issues affecting many pages. Fixing a shared navigation component may improve multiple journeys at once. Consider effort alongside impact, but do not let an easy cosmetic change displace a blocked application or donation.
W3C's interim repair guidance supports addressing urgent barriers while planning more complete improvements.
Use this iQyra worksheet to track the work. The rows illustrate how to record a finding; they are not observations from a client site.
| Task and location | Observed barrier | Priority reason | Responsible person | Re-test evidence |
|---|---|---|---|---|
| Volunteer application | Submit control cannot be activated by keyboard | Prevents completion | Assign a name | Repeat the original steps after repair |
| Find a program | Sticky header hides the focused link | Makes navigation difficult | Assign a name | Check the affected viewport and focus sequence |
| Contact form | Error identifies no field | User cannot locate the problem | Assign a name | Submit invalid data and check recovery |
When to get a fuller assessment
A preliminary review cannot cover every WCAG requirement or assistive-technology combination. Seek a more complete assessment when you need to establish conformance, investigate complex barriers, or review a major redesign. Combine automated checks with knowledgeable manual testing; an automated score alone is not a conformance result.
A widget or overlay should not be treated as proof that underlying barriers are fixed. Test the actual tasks after any change.