If your website can't be used by someone with a disability, it doesn't fully work. Here's what nonprofits should know about building sites that actually include everyone.
Why this matters for mission-driven organizations
Nonprofits exist to serve people. But when a donation form has no labels, a blind donor can't complete it. When a sign-up page requires precise mouse movements, a volunteer with a motor disability is locked out. When a video has no captions, a deaf community member gets nothing from it.
That's the contradiction: the people an organization is trying to reach may be the ones its website excludes. Accessibility isn't something you tack on after launch. If a nonprofit claims inclusion in its mission statement but publishes an inaccessible website, that gap is visible to funders, to partners, and to the communities being served.
There's a practical side too. Accessible websites tend to be better structured, load faster, and rank higher in search results because search engines reward well-marked-up content. Building with accessibility from the start is also cheaper than trying to retrofit it later.
The legal and ethical landscape
WCAG 2.1, published by the W3C, is the recognized standard. It has three conformance levels (A, AA, AAA), and Level AA is the baseline most organizations should aim for. The guidelines boil down to four principles: content should be perceivable, operable, understandable, and robust.
In the U.S., courts have increasingly treated websites as places of public accommodation under the ADA. Nonprofits have faced legal action over inaccessible sites. Canada's Accessible Canada Act and British Columbia's accessibility legislation set similar expectations. The legal landscape is catching up to what should have been obvious from the start: public-facing websites need to work for everyone.
But framing this as purely a legal risk misses the point. Excluding people with disabilities from your digital presence is a form of discrimination, even when unintentional. Most nonprofits already claim equity as a value. The website should reflect that.
Common accessibility barriers on nonprofit websites
The same problems show up on nonprofit websites over and over. Most are preventable.
Missing or inadequate alt text. Images without descriptive alternative text are invisible to screen reader users. This includes hero images, infographics, team photos, and icons used for navigation. When alt text is present but vague — "image1.jpg" or "photo" — it provides no useful information. Every meaningful image needs a concise description of what it conveys.
Poor color contrast. Light gray text on a white background may look elegant in a design mockup, but it can be unreadable for people with low vision or color blindness. WCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Many nonprofit sites fall short, particularly in footer text, placeholder text in form fields, and secondary navigation.
Inaccessible forms. Donation forms, volunteer sign-ups, and contact pages are critical conversion points for nonprofits — and they are frequently among the least accessible elements on the site. Common issues include form fields without associated labels, error messages that are not announced to screen readers, and CAPTCHA challenges that have no accessible alternative.
No keyboard navigation. Not everyone uses a mouse. People with motor disabilities, repetitive strain injuries, or temporary impairments often rely on keyboard navigation. When interactive elements like dropdown menus, modal dialogs, or custom sliders cannot be reached or operated with the Tab and Enter keys, those users are effectively blocked. Focus indicators — the visible outline that shows which element is currently selected — are often removed for cosmetic reasons, making keyboard navigation even harder.
By the numbers
"About 1.3 billion people, roughly 16% of the world's population, live with some form of disability. An inaccessible website excludes one of the largest minority groups on the planet."
Practical steps to improve accessibility today
You won't fix everything at once, but you can start making a real dent today.
Use semantic HTML. The foundation of an accessible website is proper document structure. Use heading elements (h1 through h6) in a logical hierarchy, not just for visual styling. Use <nav> for navigation, <main> for primary content, <button> for interactive controls, and <a> for links. Screen readers and other assistive technologies rely on these elements to communicate the structure of a page. A <div> styled to look like a button is not a button — it lacks keyboard support, focus management, and role announcement unless all of those are manually re-implemented.
Add ARIA labels where needed. Accessible Rich Internet Applications (ARIA) attributes fill gaps where HTML alone does not convey enough information. Use aria-label to provide text for icon-only buttons, aria-expanded to indicate the state of collapsible sections, and aria-live regions to announce dynamic content changes. However, the first rule of ARIA is to avoid using it when native HTML can do the job. ARIA supplements semantic markup — it does not replace it.
Test with screen readers. Automated testing tools catch many issues, but they cannot tell you what the experience actually feels like. Spend time navigating your site with VoiceOver (macOS/iOS), NVDA (Windows, free), or TalkBack (Android). Listen to how your pages are announced. Try completing key tasks — making a donation, finding contact information, reading a blog post — without looking at the screen. The gaps become obvious quickly.
Check color contrast. Use tools like the WebAIM Contrast Checker or browser developer tools to verify that all text meets WCAG contrast requirements. Pay particular attention to text over images, placeholder text in inputs, and disabled-state styling. If a color combination fails the ratio test, adjust it — no design aesthetic is worth excluding readers.
Ensure full keyboard operability. Tab through every page on your site using only the keyboard. Can you reach every link, button, and form field? Can you open and close menus? Is there a visible focus indicator at all times? If any interactive element traps focus or is unreachable, fix it before the next deployment.
How Oasis of Change approaches accessibility
Every website we build through Web-Ready uses semantic HTML, gets tested against WCAG 2.1 Level AA, and goes through assistive technology review before it goes live. Accessibility isn't a phase we add at the end. It's baked into the design and dev process from the start.
During design, we check contrast ratios and target sizes. During development, automated linting catches missing labels, broken heading hierarchies, and ARIA misuse. Before launch, we do manual keyboard and screen reader testing across browsers. This isn't heroic, it's just how it should be done.
We also know that accessibility isn't a one-time audit. Sites change. Content gets added, features get updated, integrations evolve. We publish a formal Accessibility Statement that documents our standards, our known gaps, and how people can report barriers. Being honest about where we fall short matters as much as the work we get right.
Nonprofits that don't have the resources to do this alone can work with our WRA Platform, which provides grants and hands-on support for building sustainable, accessible websites.