How to make your nonprofit website more accessible without a full redesign.

Here’s something I hear a lot from nonprofit leaders: “We know our website has accessibility issues, but we can’t afford a full redesign right now.”

That’s a fair constraint. But here’s what I want you to know: a full redesign isn’t always what’s needed. Many of the most common accessibility barriers are fixable without touching your site’s structure, visual design, or underlying platform. Some of them you can address this week, without a developer.

This post walks through the most impactful changes you can make to an existing site—and why they matter beyond legal compliance.

Why accessibility is an equity issue, not just a technical one

Before getting into the specifics, it’s worth naming what’s actually at stake. Roughly one in four adults in the US lives with a disability. That includes people with visual impairments who use screen readers, people with motor disabilities who navigate by keyboard instead of mouse, people with cognitive disabilities who need clear, simple language, and people with hearing loss who rely on captions for video content.

For nonprofits, this isn’t abstract. The people you serve are statistically more likely to face accessibility barriers than the general population—because disability intersects with poverty, housing instability, and the kinds of crises that bring people to community organizations in the first place. An inaccessible website isn’t just a usability inconvenience. It’s a door that’s closed to the people who need you most.

Start here: a quick audit before you do anything else

Before making changes, it helps to know what you’re actually dealing with. A free tool called WAVE (wave.webaim.org) lets you enter any URL and get an instant visual report of accessibility issues on that page. It flags things like missing alt text, low color contrast, and form labeling problems—and it shows you exactly where on the page the issues are.

Lighthouse, built into Google Chrome’s developer tools, does something similar and also checks for performance issues that affect accessibility on low-bandwidth connections.

Neither tool is perfect—automated checkers catch roughly 30% of accessibility issues, and the rest require human judgment. But they’ll give you a prioritized starting point and help you understand which problems are most common on your site. Run them on your homepage, your most-visited page, and any page with a form.

The fixes that make the biggest difference

Add alt text to your images

Alt text is a written description attached to an image that screen readers read aloud to people who can’t see it. If your images don’t have it, a significant portion of your visitors are getting a blank experience wherever those images appear.

Good alt text is descriptive and specific. “Two women sitting at a table reviewing documents” is useful. “image1.jpg” is not. Decorative images—background textures, dividers, purely visual elements—can be marked with empty alt text (alt="") to tell screen readers to skip them.

Most website platforms—Squarespace, Webflow, WordPress—give you a field to add alt text when you upload an image. If your existing images don’t have it, you can go back and add it without touching anything else on the page. This is one of the easiest wins available and one of the most commonly missed.

Fix your color contrast

If the text on your site is difficult to read against its background—light gray text on white, for example, or yellow text on a pale background—that’s a contrast problem. It affects people with low vision, color blindness, and honestly anyone reading on a bright screen in sunlight.

WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. You can check any color combination using a free tool like the WebAIM Contrast Checker (webaim.org/resources/contrastchecker). Paste in your text and background colors and it tells you instantly whether you pass.

If you have contrast failures, fixing them usually just means adjusting a color value in your site'‘s design settings or theme—not a structural change.

Label your form fields properly

Forms are where a lot of accessibility falls apart. The most common problem: form fields that use placeholder text instead of visible labels. Placeholder text—the greyed-out hint text inside a field—disappears when someone starts typing, which is a problem for people with cognitive disabilities or anyone who loses track of what a field is asking for. Screen readers often can’t reliably convey placeholder text either.

Every form field should have a visible label that stays visible when the field is filled in. In most platforms, this is a setting or a style choice, not a code change. While you’re at it, make sure your error messages are descriptive—“this field is required” is more helpful than just highlighting a box in red.

If your intake forms are central to how people access your services, this is one of the highest-impact areas to get right.

Make sure your site works without a mouse

Keyboard accessibility means someone can navigate your entire site using only the Tab, Enter, and arrow keys—no mouse required. This matters for people with motor disabilities, people using switch devices, and anyone who simply prefers keyboard navigation.

To test it yourself: open your site, put your mouse aside, and try to navigate using only the keyboard. Can you reach the navigation menu? Can you open dropdown menus? Can you fill out and submit a form? Can you always tell where your focus is on the page (the thing you’d click is usually highlighted or outlined)?

If you get stuck anywhere, that’s a barrier. Some keyboard issues require developer help to fix, but common ones—like a “skip to main content” link at the top of the page, or making sure interactive elements are reachable in a logical order—are often configurable within your platform.

Use headings like a structure, not a style choice

Headings (H1, H2, H3, etc.) aren’t just for making text bigger and bolder. They’re how screen readers understand the structure of a page—a person using a screen reader can jump between headings to navigate a long page the same way a sighted person might scan visually.

Common mistakes: using a heading tag because it looks good, skipping heading levels (jumping from H1 to H3), or having multiple H1s on a page. Your page should have one H1 (the main title), and subheadings should nest logically beneath it.

Most platforms let you set heading levels when you add a text block. Take a pass through your key pages and make sure the heading structure makes logical sense, not just visual sense.

Caption your videos

If you have video content on your site—explainers, testimonials, event recordings—and it doesn’t have captions, it’s inaccessible to people who are deaf or hard of hearing. Captions also help people watching in noisy environments, people for whom English is a second language, and people with certain cognitive disabilities who process written and spoken information differently.

YouTube auto-generates captions that are imperfect but editable. Squarespace and Webflow both support captioned video embeds. If you have a backlog of uncaptioned videos, start with the most-visited ones and work forward from there.

What to tackle first

If this list feels long, here’s a simple triage: start with alt text and color contrast, because they’re the easiest to fix and affect the most people. Then move to form labels, because your intake and contact forms are likely the most high-stakes interaction on your site. Headings and keyboard navigation are worth addressing next, and captions should be part of your workflow for any new video going forward.

None of these changes require a redesign. Most of them don’t require a developer. What they require is someone taking the time to go through your site with intention—which is exactly what an accessibility audit is for.

If you’d like help prioritizing what to fix or want someone to do a proper audit of your existing site, I'd love to hear from you. You don’t have to solve everything at once—you just have to start.

Does your nonprofit website need to be ADA compliant?

If you've ever Googled this question, you've probably ended up more confused than when you started. The answers range from “yes, absolutely, you could get sued” to “it depends” to “nonprofits are exempt”—sometimes all on the same page. So let's cut through it.

The short answer is: probably yes, and even if you're not legally required to comply, you almost certainly should anyway. Here's why.

What the ADA actually says about websites

The Americans with Disabilities Act was signed in 1990—well before the internet was part of everyday life. It doesn't mention websites at all. But over the past decade, courts have increasingly interpreted the ADA to cover digital spaces, particularly under Title III, which applies to “places of public accommodation.”

What counts as a place of public accommodation? Basically any organization that serves the public—which includes most nonprofits. Courts in several states have ruled that inaccessible websites violate the ADA, and the Department of Justice has made clear that it considers web accessibility part of ADA compliance for covered organizations.

In 2024, the DOJ finalized new rules requiring state and local government websites to meet a specific accessibility standard—WCAG 2.1 Level AA. While that rule applies specifically to government entities, it signals the direction things are heading for everyone else.

So: no, there's no law that says “nonprofit websites must comply with WCAG 2.1 by this date.” But there's a growing body of case law, regulatory guidance, and legal risk that makes accessibility something you can’t responsibly ignore.

What about nonprofits specifically?

Here’s where a lot of organizations get tripped up. There’s a common assumption that because you’re a nonprofit—mission-driven, budget-constrained, doing good in the world—you’re somehow exempt from accessibility requirements. That’s not really how it works.

If your organization has 15 or more employees, you’re covered by the ADA. If you receive federal funding, you’re subject to Section 508, which has its own accessibility requirements. And even if you fall below those thresholds, state laws may still apply depending on where you operate.

More practically: accessibility lawsuits have increased significantly over the past several years, and nonprofits are not immune. Demand letters—the step before a lawsuit—have become increasingly common. The good news is that courts generally look more favorably on organizations that can demonstrate a good-faith effort to improve accessibility, even if they’re not fully compliant yet.

What does “accessible” actually mean?

When people talk about web accessibility, they’re usually referring to WCAG—the Web Content Accessibility Guidelines. These are internationally recognized standards developed by the W3C (the organization that sets web standards) and they’re organized around four core principles. Your website should be:

Perceivable—people can access your content regardless of how they experience it. This means things like alt text on images, captions on videos, and enough color contrast that text is readable for people with low vision.

Operable—people can navigate and use your site without a mouse. Someone using only a keyboard, or a switch device, or voice control should be able to get around your site without hitting a wall.

Understandable—your content and navigation are clear and consistent. This one overlaps a lot with just good UX—plain language, logical page structure, forms that tell you when you’ve made an error.

Robust—your site works with assistive technologies like screen readers. This is mostly about clean code, but it matters a lot for people who rely on those tools.

WCAG comes in three levels: A, AA, and AAA. Level AA is the standard most commonly referenced in legal contexts, and it’s what most accessibility audits are measured against.

Why this matters beyond legal compliance

Here’s the part I actually care about most: accessibility isn’t just a legal checkbox. It’s a reflection of whether your organization’s values extend to your digital presence.

Think about who you serve. If you’re a domestic violence shelter, a legal aid clinic, a reproductive health provider, or an LGBTQ+ support organization—the people who need you most may also be the people most likely to face barriers on an inaccessible website. Someone using a screen reader because of a visual impairment. Someone on an older phone with a slow connection. Someone navigating your site under stress, in a hurry, without a lot of bandwidth to figure out a confusing interface.

Accessibility is how you make sure your website actually serves everyone it’s supposed to serve—not just the people who happen to have a fast internet connection and perfect vision and no disabilities.

So where do you start?

If you’re not sure where your site currently stands, a good first step is running it through a free automated checker like WebAIM's WAVE tool. It won’t catch everything—automated tools only identify about 30% of accessibility issues—but it’ll give you a quick picture of the most obvious problems.

From there, the most common issues to look for are:

• Images without alt text

• Low color contrast between text and background

• Forms without clear labels

• Pages that can’t be navigated by keyboard alone

• Videos without captions

If you’d like a more thorough look—or if you want someone to actually walk through your site and identify what’s getting in the way of the people you serve—that’s exactly the kind of work I do. Feel free to reach out and tell me a bit about your organization.

The goal isn’t perfection. It’s progress, documented and ongoing. And it starts with taking the question seriously—which, if you’ve read this far, you clearly already are.