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.

What data should your nonprofit stop collecting right now?

Let’s start with something a little uncomfortable: most women’s rights organizations are collecting more information about the people they serve than they actually need. Not out of bad intentions—usually out of habit, or because the intake form was built years ago and nobody’s questioned it since, or because someone once said “we might need this later.”

But for organizations serving survivors of domestic violence, people seeking reproductive healthcare, or clients navigating legal systems that don’t always protect them—unnecessary data isn’t just a compliance issue. It’s a safety issue.

Here’s a practical look at what to reconsider.

The intake form problem

Intake forms are where most of the damage happens. They’re often the first point of contact between your organization and someone who may be in a vulnerable, high-stakes situation—and they tend to accumulate fields over time without anyone asking whether each one is actually necessary.

Some of the most common offenders:

Full date of birth—Unless you’re providing a service with a strict age requirement, you probably don’t need a full birthdate. What you usually actually need is an age range, or confirmation that someone is over 18. A full date of birth is a piece of personally identifiable information that can be used to locate or identify someone—and storing it creates risk.

Full legal name—This one is context-dependent, but worth examining. Many organizations default to collecting full legal names out of habit. If you’re providing services where legal name isn’t necessary—a support group, a resource library, a crisis line—consider whether a first name, or even no name at all, would serve just as well.

Gender and pronouns—This is a nuanced one. For organizations serving LGBTQ+ communities, collecting gender identity and pronouns can be important and affirming. But it’s also sensitive data—particularly for trans and nonbinary people in environments where that information could be used against them. If you collect it, be deliberate about why, how it’s stored, and who can access it.

Full home address—For survivors of domestic violence or people in unsafe housing situations, a home address is genuinely dangerous data to have sitting in a form submission or a spreadsheet. Ask yourself: do you actually need a full address, or do you need a general service area, or just a way to contact them? If you do need an address for service delivery, think carefully about how it’s stored and who has access to it.

Titles and honorifics—Low-stakes compared to the above, but worth noting—fields like “Dr./Mr./Mrs./Ms.” are often just vestigial form elements that collect gender information under a different label. If you don’t have a specific reason to collect this, remove it.

The “we might need it later” trap

One of the most common reasons organizations collect more data than they need is future-proofing. Someone once thought “it would be useful to know our clients’ income levels” or “we should track how people heard about us”—and now those fields live in the intake form forever, collecting data that nobody’s actually looking at.

The principle to apply here is data minimization: only collect what you actively use for a specific, defined purpose. If you can’t point to a concrete use for a piece of information, don’t collect it. Not only does this reduce your risk exposure, it also makes your forms shorter and less overwhelming for the people filling them out—which, for someone in a crisis, matters enormously.

A useful exercise: go through your intake form field by field and ask, for each one, “what do we do with this information?” If the answer is “nothing, really”—cut it.

The invisible data problem: your website

Intake forms are the obvious place to look, but your website may be collecting data you’re not even aware of.

Social media pixels. If you have a Facebook pixel, a TikTok pixel, or similar tracking code on your site, you are allowing those platforms to collect information about every person who visits your website—including people who may have come looking for help with a DV situation, an abortion, or immigration status. That data can be used for ad targeting, and in some cases may be accessible to third parties including law enforcement. For most women’s rights organizations, this is an unacceptable risk. Remove them.

Social sharing buttons. Even if you don't have a pixel, embedded social sharing buttons (the little “share on Facebook” icons) often load third-party scripts that track visitors. If you want people to be able to share your content, a plain text link does the job without the surveillance infrastructure.

Analytics tools. Most websites use some form of analytics to understand how people find them and what they do once they arrive. That’s legitimate—you need to know if your resources are being found and used. But not all analytics tools are created equal.

Google Analytics is the most widely used option, and if you’re already using it, the good news is that the current version (GA4) automatically anonymizes IP addresses by default—you don’t have to do anything to enable that. What you should do is check your data retention settings: GA4 defaults to storing user-level data for two months, and you can verify or reduce that in your property settings under Data Settings > Data Retention. You should also make sure Google Signals is turned off if you’re not actively using it, as it enables cross-site tracking and behavioral advertising features you almost certainly don’t need. Google has a number of privacy options available for Google Analytics, they just might need to be enabled/disabled (depending what they are).

If you’re setting up analytics from scratch, or considering switching, there are privacy-focused alternatives worth knowing about. Plausible and Fathom are both cookie-free, don’t collect personal data, and are fully GDPR-compliant by design. They give you the traffic information you actually need—where people are coming from, which pages they visit, what’s working—without the broader surveillance infrastructure. Both have paid plans starting around $9–15/month, which for most small organizations is a reasonable trade for significantly better privacy posture.

Where to start

If this feels overwhelming, don’t try to fix everything at once. Start with your intake form, because that’s where the most sensitive data lives and where your risk is highest. Go field by field, apply the “what do we do with this?” test, and remove anything that doesn’t have a clear answer.

Then take a look at your website’s third-party scripts—most platforms make it relatively easy to see what’s loading. If you see social pixels, remove them. If you’re not sure what’s there or how to evaluate it, that’s exactly the kind of thing I can help with. Get in touch and we can take a look together.

The goal isn’t a perfect system. It’s a deliberate one—where every piece of data you collect is there for a reason, and the people you serve aren’t carrying more risk than they have to.

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.