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.