What does a nonprofit website redesign actually cost?

This is the question everyone has and nobody wants to ask out loud, because the answer they’ve heard before is either “it depends”—which is both technically true and completely unhelpful—or a number that made them close the browser tab.

So let’s actually talk about it. Not in the abstract, but honestly: what does a nonprofit website redesign cost, what drives that cost, and how do you know if what you’re being quoted is fair?

The range is wide, and that’s not an accident

Website pricing spans an enormous range, and the reason isn’t arbitrary. A website can be almost anything—a simple four-page brochure site or a complex platform with custom integrations, member portals, and a content management system that serves fifty staff members. The same word covers wildly different things.

That said, here’s an honest picture of the market:

At the low end, under $500, you’re in DIY or volunteer territory. Someone on the board offers to build it, or a well-meaning volunteer puts something together over a weekend, or you use a template and fill it in yourself. Sometimes this works fine for an organization in its earliest stages with very simple needs. More often, it produces a site that doesn’t quite represent the organization, that nobody fully understands how to manage, and that becomes increasingly embarrassing over the next three years as staff turnover means institutional knowledge about it quietly disappears.

In the mid-range—roughly $3,000 to $10,000—you’re typically working with an experienced independent designer or small studio. This is where I work, with projects starting at $5,000 for a Squarespace build. At this level, you’re paying for someone who does this full time, who brings strategic thinking to the project, who has opinions about what works and what doesn’t, and who is going to ask you a lot of questions before touching a single design element.

At the higher end—$15,000 to $25,000 and above—you’re usually working with an agency, or with an independent designer on a complex custom build. Complex WordPress implementations, custom-developed features, large content migrations, and sites with significant technical requirements can legitimately reach these numbers. The price reflects the scope, not necessarily the quality.

What you’re actually paying for

When people see a $5,000 quote for a website and think “that seems like a lot,” they’re usually picturing the end product—a website—and not the process that produces it.

Here’s what that process actually looks like on my end, before a single page gets designed:

Understanding the organization. What do you do, who do you serve, how do people find you, what do they need when they get there, what are you trying to communicate, what’s not working about what you have now? This isn’t small talk—it’s the research that determines whether the final site actually solves the right problem.

Deciding what the site needs to contain. How many pages, what goes on each one, how does content flow between them, what forms are needed, how are resources organized, what’s the hierarchy of information? These decisions take time and require back-and-forth.

Thinking through content. Who's writing it? If you are, great—but writing for the web is a specific skill and most organizations underestimate how long it takes. If I’m doing it, that’s additional scope. If you’re doing it and it comes in as a wall of text that reads like a grant application, someone is going to need to reshape it, and that someone is usually me.

Only after all of that does design and build actually begin.

The point is that a website project is a collaborative process that requires a significant investment of time from both sides. Organizations that go in expecting to hand off a brief and receive a finished product six weeks later tend to have a difficult time, regardless of who they hire.

The things that drive cost up

Beyond the baseline, a few things consistently add to the scope and price of a redesign:

Content migration. If you have an existing site with years of blog posts, resources, or archived content that needs to move to the new site, that’s a significant amount of work that people consistently underestimate. It’s not just copying and pasting—it’s reviewing, organizing, reformatting, and making decisions about what’s worth keeping.

Third-party integrations. Donation platforms, CRM systems, event registration tools, email marketing software—connecting your website to outside systems takes time, and sometimes the integration is less seamless than the tool’s marketing suggests. A surprising amount of integration work ends up being custom CSS to make a third-party donation form look like it belongs on your site, rather than like it was embedded from a different decade.

Copywriting. If you want help writing the actual words on your site—and most organizations do, even if they don’t realize it upfront—that’s typically scoped separately. DIY copywriting is almost always the thing that slows a project down the most and produces the result people are least happy with.

Complexity of content structure. A site with five pages and a contact form is a different project than one with eight service areas, a resource library, staff directories, and multilingual content. Scope determines price.

The pattern I see most often

Here’s the thing about nonprofit web design that I think is worth saying directly: organizations tend to either want it to be cheap or assume it has to be expensive. Neither instinct serves them well.

The organizations that go cheap usually end up with something built by a volunteer or a board member who means well but isn’t a designer—or they hire someone at a surprisingly low price and get a site that looks like it cost what it cost. It goes live, nobody knows how to update it, it sits untouched for five years, and eventually they decide they need to redo it. At which point the cycle often repeats.

The organizations that assume expensive means quality sometimes hire an agency at $20,000, get a sprawling WordPress site loaded with plugins and custom code, and find themselves eighteen months later with a site that’s become a liability—slow to load, difficult to update, increasingly vulnerable to security issues, and requiring ongoing developer fees for every small change. The price tag didn’t guarantee the outcome.

The organizations that fare best tend to be the ones that think carefully about what they actually need, hire someone whose process they trust (not just whose portfolio they like), and go in understanding that their participation in the project is part of what determines the result.

A note on WordPress specifically

WordPress powers a significant portion of the web and can be the right choice for organizations with complex, specific technical requirements. But a lot of nonprofits end up with WordPress sites not because they needed what WordPress offers, but because it’s what their developer knew, or because “it's free,” or because it seemed like the powerful, future-proofed option.

A heavily customized WordPress site with a premium theme, ten plugins, and custom development is not cheap—it’s often more expensive to build than a well-designed Squarespace site, and considerably more expensive to maintain. The plugins need updating, the theme needs updating, the WordPress core needs updating, and if any of those updates breaks something (which happens), you need a developer to fix it. That ongoing cost is real and rarely factored into the initial conversation.

I'm not saying don’t use WordPress. I’m saying be honest with yourself about whether you need it.

So what should you budget?

If you’re a small to mid-sized nonprofit with a clear set of content needs—services, about, resources, contact, maybe a blog—and you want a site your team can actually manage, budget $5,000 to $10,000 for an experienced independent designer. Expect the process to take two to four months and to require meaningful time from your side.

If you have more complex needs—large content libraries, custom integrations, significant technical requirements—budget more, get detailed quotes, and ask specifically what’s included and what isn’t.

Whatever you’re quoted, ask the person you’re hiring what happens after launch. Who handles updates? What does ongoing support look like? What does your team need to know to manage the site independently? The answers to those questions will tell you a lot about whether you’re going to end up with something that works for the long term or something that needs to be completely redone in five years.

If you’d like to talk through what a project might look like for your organization—scope, timeline, what to expect—I’m always happy to have that conversation before anyone commits to anything.

How to audit your nonprofit website for privacy risks.

Most nonprofit leaders assume their website is basically fine from a privacy standpoint. They have a privacy policy somewhere in the footer, they’re not selling data, and they’re not doing anything sketchy. What more is there to think about?

Quite a bit, it turns out—and most of it is invisible unless you know where to look.

Your website is probably collecting more data than you realize, sharing it with more third parties than you’d expect, and retaining it longer than is necessary. None of that is unusual, and none of it means your organization has done something wrong. It means you’re using tools that were built to collect data by default, and no one has gone back to examine what’s actually happening under the hood.

This post walks you through a practical self-audit you can do without a technical background. You don’t need to understand code. You just need to know where to look and what questions to ask.

Step one: find out what’s loading on your site

The first thing to understand is what third-party scripts are running on your website. Every time someone visits your site, their browser loads not just your content but potentially a collection of scripts from other companies—analytics tools, social media platforms, advertising networks, embedded widgets, font libraries. Each of those is a data relationship you’ve entered into on behalf of your visitors, whether you meant to or not.

To see what’s running, open your website in Google Chrome or Brave Browser, right-click anywhere on the page, and select “Inspect.” Click the “Network” tab, then reload the page. You’ll see a list of everything loading—look specifically at the entries that aren’t your own domain. You’re looking for things like google-analytics.com, facebook.net, doubleclick.net, platform.twitter.com, or any other third-party domains.

If that feels too technical, a simpler option is to use a tool like Blacklight (themarkup.org/blacklight) — paste in your URL and it gives you a plain-language report of the trackers, ad networks, and third-party scripts it detects on your site. It was built specifically to make this kind of information accessible to non-technical people, and it’s free.

Once you know what’s loading, you can start making decisions about what should stay and what should go.

Step two: evaluate each third-party tool

Not all third-party scripts are equal. Here’s a framework for thinking through each one:

Do you know it’s there? Sometimes scripts end up on a site through an embedded widget, a social sharing button, or a plugin someone installed years ago without fully understanding what it did. If you’re not sure why something is loading, that’s worth investigating before you decide whether to keep it.

What data does it collect, and where does it go? Analytics tools collect visitor behavior. Social pixels collect information about who visits your site and share it with advertising platforms. Embedded maps and video players may collect location and viewing data. Each tool’s privacy policy will tell you what it collects—though reading those is its own adventure—and whether that data is shared with or sold to third parties.

Is it necessary? This is the most important question. For every third-party tool on your site, ask what you’d lose if you removed it. If the answer is “not much,” remove it. If it’s serving a purpose, ask whether there’s a less data-intensive way to serve that same purpose.

Social media sharing buttons are a common example of tools that feel useful but aren’t worth the tradeoff. The buttons themselves load scripts from Facebook, Twitter, and other platforms that track every visitor who lands on the page—regardless of whether they click the button. A plain text link to share something accomplishes the same goal without the tracking infrastructure.

Step three: look at your analytics setup

If you’re using Google Analytics, there are a few specific things worth checking.

First, confirm you’re using GA4 rather than the older Universal Analytics. GA4 anonymizes IP addresses by default, which is a meaningful baseline privacy improvement.

Second, check your data retention settings. In GA4, go to Admin > Data Settings > Data Retention. The default is two months for user-level data, which is reasonable—make sure it hasn’t been changed to a longer period without a clear reason.

Third, look at whether Google Signals is enabled. Google Signals connects your analytics data to Google’s advertising network, enabling cross-site tracking and behavioral targeting. For most nonprofit websites, this feature serves no purpose and should be turned off. You’ll find it under Admin > Data Settings > Data Collection.

If you’re open to switching analytics tools entirely, privacy-focused alternatives like Plausible or Fathom collect only what you actually need—page views, referral sources, popular content—without the broader data collection that comes with Google’s ecosystem. They’re not free, but they’re not expensive, and the tradeoff is worth considering for organizations serving vulnerable populations.

Step four: review your forms

Your contact forms, intake forms, and newsletter sign-ups are some of the most sensitive data collection points on your site. A few things to check:

What platform is handling your forms? If you’re using Google Forms, your submissions are stored in Google’s infrastructure. If you’re using Typeform or JotForm, your submissions are in their databases, under their privacy policies. Native form tools built into your website platform—like Squarespace’s built-in forms—typically give you more control over where data goes and who can access it.

Where do submissions go after someone fills out a form? Most platforms send an email notification, store the submission in a backend database, or both. Check whether submissions are accumulating in your platform’s backend without anyone actively managing or deleting them. Old form submissions are data you’re responsible for—and data you’re not actively using is data you probably shouldn’t be keeping.

How long do you keep form submissions? If you don't have an answer to this question, that’s the gap to close. A simple retention policy—“we delete intake form submissions after 90 days unless they've been transferred to our case management system”—is better than no policy, and it protects your clients.

Step five: check your privacy policy

Your privacy policy should accurately describe what your site actually does—not what you intended it to do when the policy was written, but what it does right now. If you’ve added tools or changed platforms since the policy was last updated, it may no longer be accurate.

At minimum, your privacy policy should cover: what data you collect and why, what third-party tools you use and what they collect, how long you retain data, and how someone can request that their data be deleted. It should be written in plain language, not legal boilerplate, and it should live somewhere easy to find—not buried at the bottom of a page nobody visits.

A privacy policy that doesn’t reflect your actual practices isn’t just a document problem. It’s a trust problem.

What to do with what you find

A privacy audit isn’t meant to produce a perfect score—it’s meant to give you a clear picture of where you are, so you can make deliberate decisions about where you want to be. You might find that most of your setup is fine and there are two or three specific things to address. You might find a tracking pixel that got added during a social media campaign and was never removed. You might find that your analytics data retention is set to something nobody consciously chose.

Whatever you find, the goal is the same: make sure the data your website collects is the data you’ve decided to collect, for reasons you can explain, handled in ways you’ve thought through.

If you’d like help working through this audit—or want someone to do a more thorough technical review—that’s work I do with organizations regularly. Sometimes a second set of eyes finds things that are easy to miss when you’re close to the work.

Squarespace for nonprofits: is it the right platform for your organization?

If you’ve ever gone looking for advice on which website platform to use, you’ve probably encountered some version of the same conversation: someone recommends WordPress because it’s powerful and free, someone else warns that it’s a nightmare to maintain, someone mentions Wix or Weebly, and then everyone piles on to explain why those aren’t great either.

It’s a genuinely confusing landscape, and the stakes feel high—your website is often the first thing people encounter when they’re looking for help, so getting the platform wrong has real consequences.

I’ve been building websites for nonprofits and advocacy organizations for a long time, and I work primarily in Squarespace and Webflow. This post is specifically about Squarespace—what it does well, where it runs into limitations, and how to think about whether it’s the right fit for your organization.

What Squarespace is

Squarespace is an all-in-one website platform—hosting, design tools, domain management, analytics, and form handling are all bundled together. You pay a monthly or annual fee and get a fully managed environment. You don’t install software, manage server configurations, or worry about keeping plugins up to date.

That bundled model is both Squarespace’s biggest strength and the source of most of the criticism you’ll see of it. You get a lot out of the box, but you’re working within the constraints of what Squarespace has built. Whether that’s a good trade depends almost entirely on what your organization actually needs.

Where Squarespace excels

Security—and I don’t think this gets enough credit. Squarespace handles security at the infrastructure level. SSL is included and automatic. The platform manages its own updates, patches vulnerabilities, and protects against common attacks without you having to do anything. There’s no plugin ecosystem introducing new vulnerabilities every time someone pushes an update.

This is a meaningful consideration for organizations handling sensitive client information. A WordPress site loaded with plugins—which describes the majority of nonprofit WordPress sites I’ve encountered—has a much larger attack surface. Each plugin is a potential entry point, and plugins that aren’t regularly updated become liabilities. I’ve seen organizations get hacked through an outdated contact form plugin, a neglected SEO tool, a theme that stopped being maintained. That’s not hypothetical—it’s common.

With Squarespace, that category of risk largely disappears. For organizations serving vulnerable populations where a data breach would be truly harmful, that’s not a small thing.

Privacy by default. Squarespace’s built-in analytics are relatively lightweight—you get traffic data without the surveillance infrastructure of Google Analytics. Form submissions are primarily handled via email notification rather than stored indefinitely in a database, which means sensitive intake information isn’t accumulating somewhere you’ve forgotten about. You can configure session data not to be stored. SSL and domain privacy are standard. None of this requires technical expertise to set up—it’s just how the platform works.

Accessibility out of the box. Squarespace templates are built to modern standards, with clean semantic structure, good keyboard navigation defaults, and straightforward image alt text fields. You’re not starting from zero on accessibility, which you often are with a custom WordPress theme or a heavily modified template. That said, Squarespace isn’t a substitute for thoughtful design decisions—you can still make inaccessible choices within an accessible framework—but the foundation is solid.

Your team can actually manage it. This is underrated. Squarespace’s drag-and-drop editor, layout suggestions, and visual interface mean that a non-technical staff member can update content, add pages, and make design changes without breaking anything or needing to call a developer. That matters enormously for organizations with limited budgets and high staff turnover.

I’ve encountered WordPress sites where the client was actually afraid to log in and make changes. That’s not a hypothetical—it’s one of the most common things I hear from organizations who come to me after a bad experience. “We have a developer who built it but we can’t afford to keep paying them for every little update, and no one on staff knows how to touch it.” Squarespace largely solves that problem.

The real cost comparison. Squarespace’s pricing looks expensive compared to “free WordPress”—but that comparison isn’t honest. A WordPress site in practice means paying for hosting (typically $10–30/month for something reliable), a premium theme ($50–200/year), and an assortment of plugins for forms, SEO, security, backups, and performance (which can easily add another $100–300/year). Then there’s the ongoing cost of maintaining all of it—updates, troubleshooting, the occasional developer call when something breaks. When you add it up, Squarespace’s annual plan often comes out cheaper than a properly maintained WordPress setup, and significantly cheaper than one that’s been patched together over several years.

Where Squarespace has limitations

Complex, deep content structures are harder to manage. Squarespace works beautifully for organizations with a clear, relatively contained set of pages—services, about, resources, contact, blog. Where it gets harder is when you have a large resource library with multiple levels of categorization, complex navigation hierarchies, or a lot of content that needs to be organized in sophisticated ways. The platform’s content management tools are simpler than WordPress’s by design, and at a certain scale of complexity, that simplicity becomes a constraint.

If your organization has dozens of programs, several distinct service areas with their own sub-pages, or a content-heavy site that functions more like a database than a brochure—Squarespace may not be the right fit, and Webflow or a well-built WordPress site might serve you better.

Custom functionality has limits. Squarespace has a robust set of built-in tools, but if you need something very specific—a custom intake workflow, complex membership features, integration with a specialized case management system—you’ll hit the edges of what the platform can do. Extensions exist, but the ecosystem is much smaller than WordPress’s. For most nonprofit websites, this isn’t a problem. For organizations with highly specific technical requirements, it might be.

You’re on Squarespace’s timeline. When Squarespace changes something—updates the editor, deprecates a feature, changes how templates work—you adapt. You don’t control the infrastructure. For most organizations this is fine, and the tradeoff (not having to manage the infrastructure yourself) is worth it. But it’s worth knowing that the platform has made significant changes in the past that required existing sites to update.

So is it right for your organization?

Squarespace tends to be a great fit for nonprofit organizations that have a clear, contained set of content and services, want their team to be able to manage the site without ongoing developer dependence, care about security and privacy without wanting to manage those things themselves, and don’t have highly specialized technical requirements.

It tends to be a harder fit for organizations with large, complex content structures, very specific custom functionality needs, or technical teams who want full control over the infrastructure.

If you’re currently on WordPress and your site is stagnant because nobody feels confident updating it, that’s a real problem worth solving—and a platform change might be part of the answer. If you’re on Wix or Weebly and wondering if there’s something better, there almost certainly is.

If you’re not sure which platform makes sense for your organization’s specific situation, that’s exactly the kind of question I help organizations think through—before they commit to a build. Feel free to reach out and we can talk it through.

Are your intake forms putting your clients at risk?

Intake forms are one of the most important pieces of infrastructure on your organization’s website. They’re often the first real interaction someone has with you—the moment a person in a difficult situation decides to share something personal and ask for help.

They’re also, in many organizations, one of the least examined pieces of infrastructure on the site. The form was built when the organization launched, or when someone switched platforms, or when a volunteer with some web skills offered to help. Questions got added over time. Nobody ever went back to ask whether all of them should still be there.

This post is an invitation to do that—to look at your intake forms not just as a functional tool but as a data collection decision, and to think carefully about whether what you’re collecting serves your clients or creates risk for them.

The basic question: do you need this?

Every field on your intake form is a piece of data you’re responsible for. It gets stored somewhere—in your platform’s database, in an email notification, in a spreadsheet someone exported once and forgot about. It can be accessed by people inside your organization, and potentially outside it. It persists until someone deliberately deletes it, which in many organizations means it persists indefinitely.

The principle of data minimization says: only collect what you actually need, for a specific purpose, and only keep it as long as that purpose requires. It sounds simple, but it runs counter to how most forms get built, which is additive—fields get added and rarely removed.

A useful exercise is to go through your intake form field by field and ask two questions: what do we do with this information, and what would happen if we didn’t collect it? If the answer to the first question is “not much” and the answer to the second is “nothing significant,” that field probably shouldn’t be there.

Some of the most common fields worth reconsidering:

Full date of birth. If you need to verify someone is over 18, a checkbox confirmation does that job without creating a record of someone’s exact birthdate. If you need age for service eligibility, an age range works just as well.

Full home address. For many organizations, a general service area or zip code is all that’s actually needed for intake purposes. A full address is sensitive—particularly for someone fleeing an unsafe situation—and storing it creates responsibility.

Demographic details that aren’t tied to service delivery. Race, ethnicity, income level, and household composition are sometimes collected for grant reporting purposes, which is legitimate. But if you’re collecting them by default on every intake form without a clear reporting need, it’s worth asking whether that’s the right place to gather that information, and whether it could be collected separately and anonymously.

Open text fields with no guidance. “Tell us about your situation” sounds welcoming, but it’s an invitation for people to share more than you need—and more than is safe for them to have in a form submission. If you need some context, narrow the question. “What kind of support are you looking for?” gets you what you need without encouraging people to disclose sensitive details upfront.

Who can see what gets submitted

This is a question a lot of organizations haven’t fully answered, and it’s worth sitting with. When someone fills out your intake form, where does that data go?

Most form submissions do at least one of the following: they get stored in your website platform’s backend, they get sent to one or more email addresses as a notification, or they get routed to a CRM or case management system. In many organizations, all three.

Each of those destinations has its own access controls, or should. Some questions worth asking:

Who receives the email notifications when a form is submitted? Is it a personal inbox, a shared inbox, or a role-based address? What happens to those emails—are they archived, deleted after a certain period, or just sitting in someone’s inbox indefinitely?

Who has admin access to your website platform or CRM, and when was that list last reviewed? Former staff or volunteers who still have access to form submissions is a more common problem than most organizations realize.

If your form submissions are being stored in your website platform’s backend—Squarespace, WordPress, or similar—are you periodically exporting and deleting old submissions, or are they accumulating? Many platforms store form submissions indefinitely by default, which means years of client data may be sitting in a database that nobody’s actively managing.

None of this requires a complicated technical solution. It requires a policy—a clear, written answer to “where does this data go, who can see it, and how long do we keep it”—and someone responsible for making sure that policy is actually followed.

How the form itself communicates trust

Beyond what you collect and how you store it, the form itself sends signals to the person filling it out. Those signals matter, especially for people who have reason to be cautious about sharing personal information.

A form that asks for a lot of sensitive information upfront, with no explanation of why it’s needed or what happens to it, can feel extractive—like handing over details to an institution that hasn't earned that trust yet. A form that’s transparent about what you’re collecting and why, that acknowledges the sensitivity of the information, and that tells people what to expect after they submit—that feels different.

Some practical ways to build trust into the form itself:

Add a brief note at the top explaining what the form is for and what happens next. “This form helps us understand your situation so we can match you with the right support. Someone from our team will be in touch within 48 hours.” That one sentence reduces anxiety and sets expectations.

If you collect sensitive information, explain why. “We ask for your zip code so we can connect you with services in your area” is more reassuring than a blank address field.

Include a privacy note near the submit button. It doesn’t need to be long—something like “Your information is kept confidential and shared only with the staff member handling your case” tells people what they need to know.

Be honest about what you can and can’t guarantee. If your organization has mandated reporting obligations, people deserve to know that before they share information that might trigger them.

A note on third-party form tools

If you’re using a third-party form tool—Typeform, JotForm, Google Forms, or similar—it’s worth understanding that those platforms have their own data storage and privacy policies, which may not align with your organization’s values or your clients’ expectations.

Google Forms, in particular, stores submissions in Google’s infrastructure and may use that data in ways that aren’t fully transparent. For organizations serving vulnerable populations, a form tool that stores data on Google’s servers is worth reconsidering. There are alternatives—Tally, Formspree, or native form handling built into your website platform—that give you more control over where submissions go and who can access them.

Where to start

If this post has made you want to look at your intake forms with fresh eyes, start with the simplest version of the audit: open the form yourself, read every field, and ask whether you’d be comfortable explaining to a client exactly why you need that information and what you do with it. If the answer to any field is uncomfortable, that’s a signal.

From there, trace where submissions go—email, platform backend, CRM—and make sure you know who has access at each step. Then set a retention policy, even a simple one, and make sure old submissions are actually being cleared.

It’s not a complicated process. It just requires intentionality—which is something your clients, who trusted you enough to fill out the form in the first place, deserve. If you’d like help thinking through your forms or your broader data handling practices, I’d love to hear from you.

WCAG 2.2: what changed and what it means for advocacy organizations.

If you’ve been paying attention to web accessibility conversations over the past couple of years, you've probably seen “WCAG 2.2” come up. Maybe your web developer mentioned it. Maybe it appeared in a grant requirement or a compliance checklist. Maybe you Googled it, landed on the official documentation, and immediately closed the tab.

That’s fair. The official WCAG documentation is written for developers and auditors, not for nonprofit leaders trying to understand what they actually need to do. This post is the version for everyone else.

A quick refresher on what WCAG is

WCAG stands for Web Content Accessibility Guidelines. It’s the international standard for web accessibility, developed by the W3C—the organization that sets technical standards for the web. When courts and regulators talk about what an “accessible website” means, they’re almost always referring to WCAG.

The guidelines are organized into three compliance levels: A (minimum), AA (the standard most commonly required by law and best practice), and AAA (the highest level, which most sites don’t fully achieve). When someone says “WCAG 2.2 Level AA compliance,” that’s the target most organizations should be working toward.

WCAG 2.2 was published in October 2023. It builds on the previous version (2.1) by adding nine new success criteria—specific, testable requirements your site either passes or fails. If your site already meets WCAG 2.1, you’re most of the way there. But those nine additions matter, and a few of them are particularly relevant for advocacy organizations.

What’s actually new

Not all nine new criteria will feel equally urgent for every organization. Here are the ones most worth your attention.

Focus appearance (2.4.11 and 2.4.12)—When someone navigates your site using a keyboard—no mouse—there’s a visual indicator that shows which element is currently focused, like an outline around a button or link. WCAG 2.2 sets new minimum requirements for how visible that indicator needs to be. The older standard just said “there must be one.” The new one says it needs to be large enough and have enough contrast to actually be usable.

This matters for advocacy organizations because keyboard navigation is essential for people with motor disabilities—and because a lot of sites technically had focus indicators that were so faint they were functionally invisible. If your site uses a very subtle focus style (or has had it removed entirely for aesthetic reasons), this is worth checking.

Dragging movements (2.5.7)—Any functionality that requires dragging—think sliders, drag-and-drop interfaces, interactive maps—must also be operable with a single pointer action like a click or tap. Dragging is genuinely difficult for people with motor disabilities or tremors, and this criterion closes a gap that affected a lot of interactive content.

For most advocacy organization websites, this one is low-stakes—you probably don’t have many drag-based interactions. But if you have any interactive resources, tools, or embedded maps with draggable elements, it’s worth a look.

Target size (2.5.8)—Clickable elements—buttons, links, form controls—need to meet a minimum size of 24x24 pixels, with some flexibility for inline links in text. The intent is that small, tightly clustered tap targets are genuinely hard to use for people with motor impairments, on touchscreens, or with limited dexterity.

This one has real practical implications for mobile design. If your site has tiny buttons, links packed closely together, or form elements that are difficult to tap on a phone, this criterion applies. And given how many people access community organization websites from mobile devices—often in situations where they can’t use a desktop—getting this right matters.

Accessible authentication (3.3.8)—This criterion requires that login or verification processes don’t rely solely on cognitive function tests—meaning CAPTCHAs that require you to identify objects in images, solve puzzles, or remember and transcribe codes. People with cognitive disabilities, dyslexia, or memory impairments can find these entirely impossible to complete.

For most advocacy organizations, this is relevant if you have any member portals, client login areas, or gated resources. If you do, the authentication method should offer an alternative that doesn’t require solving a puzzle—like a magic link sent to email, or a simpler numeric code.

Redundant entry (3.3.7)—If your site asks for the same information more than once in a single process—say, asking for someone’s name and contact information on one page of a multi-step form and then again on a later page—the previously entered information must be auto-populated or otherwise available to the user. Making someone re-enter information they’ve already provided creates unnecessary burden, particularly for people with cognitive disabilities or anyone filling out a form under stress.

For organizations with multi-step intake forms, this is directly applicable. It’s also just good UX—nobody likes re-entering information.

Focus not obscured (2.4.12)—When a keyboard user tabs to a focused element, that element shouldn’t be completely hidden behind a sticky header, a cookie banner, or any other fixed overlay. This is a common and often overlooked problem—a user navigates to a link, it gets focus, but a floating header covers it so they can’t see it. WCAG 2.2 requires that the focused element is at least partially visible.

If your site has a sticky navigation bar or a persistent cookie consent banner (which, given the privacy conversation, you may want to reconsider anyway), this is worth testing.

What this means practically for your organization

If your site was built or last audited against WCAG 2.1, you don’t need to start from scratch—most of what you had still applies. What you should do is:

Run your site through an updated accessibility checker. Tools like WAVE (wave.webaim.org) are regularly updated to reflect current standards and will flag issues against WCAG 2.2 criteria.

Pay particular attention to mobile. Several of the new criteria—target size, focus appearance, dragging—disproportionately affect mobile users, and mobile is often the primary way people access community organization websites.

Review any forms that span multiple steps or require authentication. The redundant entry and accessible authentication criteria are most likely to apply there.

And if you have a sticky header, test keyboard navigation with it active. It’s a surprisingly common source of focus-obscuring issues that are easy to miss if you’re not specifically looking for them.

The bigger picture

WCAG doesn't update frequently—2.1 was published in 2018, and 2.2 came five years later. The next major version (WCAG 3.0) is still in development and likely several years away. So 2.2 is the standard you’ll be working against for the foreseeable future, and it’s worth getting right.

More importantly: the new criteria in 2.2 aren’t arbitrary technical requirements. They address real barriers that real people encounter. The focus on cognitive load, motor accessibility, and mobile usability reflects where accessibility research and advocacy have been pointing for years. For organizations whose mission is to serve people equitably, aligning your website with those standards is part of walking the talk.

If you’re not sure where your site stands against WCAG 2.2, or you want help prioritizing what to tackle first, I’m happy to take a look. An accessibility audit doesn’t have to be a massive undertaking—sometimes it just takes a fresh set of eyes.

What is trauma-informed web design, and does your organization need it?

If you work in human services, you’ve probably heard the phrase “trauma-informed care.” It’s become a guiding framework across social work, healthcare, education, and advocacy—the idea that organizations serving people who have experienced trauma should structure their practices around an understanding of how trauma affects people, rather than inadvertently making things worse.

What doesn’t get talked about as often is how that same framework applies to your website.

Trauma-informed web design is exactly what it sounds like: an approach to designing digital experiences that accounts for the ways trauma affects how people think, feel, navigate, and make decisions—particularly in high-stress moments. It’s not a checklist or a certification. It’s a design philosophy, and for organizations serving survivors, people in crisis, or communities that have historically been harmed by institutions, it’s one of the most meaningful things you can build into your digital presence.

What trauma actually does to how people use websites

To understand why this matters, it helps to understand a little about what trauma does to the brain. Trauma—whether from abuse, violence, loss, systemic oppression, or chronic stress—affects the nervous system in ways that are well-documented. People who have experienced trauma may have difficulty concentrating or processing information. They may be hypervigilant, scanning for threats. They may feel easily overwhelmed. They may dissociate under stress, or freeze when confronted with too many choices.

Now think about what a typical nonprofit website asks of someone in that state. Navigate a dense menu to find the right service. Fill out a long intake form with personal questions. Figure out what “click here to get started” actually means. Read through paragraphs of text to find a phone number.

For someone who isn’t in a heightened state, these are minor friction points. For someone in crisis—someone looking for a domestic violence shelter at 2am, or trying to find out if they can access abortion services, or figuring out if they qualify for legal aid—they can be the difference between getting help and giving up.

Trauma-informed web design tries to close that gap.

The core principles, and what they look like in practice

Trauma-informed care is typically organized around a set of principles developed by SAMHSA (the Substance Abuse and Mental Health Services Administration): safety, trustworthiness, peer support, collaboration, empowerment, and cultural sensitivity. Not all of these translate directly to web design, but several do—in very concrete ways.

Safety is about making sure your site doesn’t inadvertently create fear or danger for the people using it. For organizations serving survivors of domestic violence or people seeking sensitive health services, this can have a literal application: a quick-exit button.

A quick-exit button is a prominently placed button—usually in a corner of the screen—that immediately redirects the browser to a neutral page (often Google or a weather site) and clears the browsing session. It exists because someone might be browsing your site in a situation where being discovered could put them at risk. The UK government’s domestic abuse support pages have had these for years. Many DV shelter sites in the US use them. If your organization serves people in potentially unsafe situations, this is one of the most direct ways your website can prioritize their physical safety.

Safety also means being transparent about what your site does and doesn’t do. If you have a contact form, does it tell people whether their inquiry is confidential? If you’re a mandated reporting organization, do you say so upfront, before someone shares something they might not have shared if they’d known? Clarity about what happens to someone’s information—before they give it—is a form of safety.

Trustworthiness in web design means your site does what it says it will do, consistently and predictably. Navigation that works the same way on every page. Links that go where they say they go. Forms that tell you what happens after you submit them. Error messages that explain what went wrong rather than just flagging that something did.

This sounds basic, but a lot of websites fail at it—and for someone whose trust has been broken by institutions or individuals, an unpredictable or confusing interface can feel like a much bigger deal than it would to someone without that history.

Empowerment is about giving people agency and choice wherever possible. This shows up in web design in ways like: letting people choose how to contact you (form, email, phone) rather than forcing one path. Giving people a way to save their progress on a form rather than losing everything if they get interrupted. Using language that positions the person as capable and in control rather than as a passive recipient of services.

It also shows up in the content itself. Plain language that explains things clearly without jargon empowers people to understand what they’re reading and make their own decisions. Dense, institutional language—even when well-intentioned—can feel exclusionary and disempowering, particularly for communities that have been historically underserved by the systems you’re navigating.

Cultural sensitivity means your site reflects and respects the communities you serve. This is partly about representation—do the images on your site reflect the actual diversity of your clients? But it’s also about language, tone, and assumptions. Does your site assume a certain level of English fluency? Does it assume people have stable housing, reliable internet, or a private device? Does it use terms and frameworks that resonate with the communities you serve, or does it speak from an institutional perspective that may feel distant or even alienating?

What this looks like beyond the big features

The quick-exit button is probably the most-cited example of trauma-informed design, but it’s far from the only one. Some of the most impactful trauma-informed design choices are smaller and more pervasive:

Cognitive load—Trauma affects working memory and concentration. A page with too much text, too many competing calls to action, or a complex navigation structure creates cognitive load that can overwhelm someone who is already struggling to focus. Simpler is not dumbing down—it’s designing for the hardest moment, which means it also works for everyone else.

Tone—The language on your site carries emotional weight. Words like “victim,” “case,” or “client” land differently than “survivor,” “person,” or “someone we work with.” Headlines that lead with crisis and urgency can activate rather than calm. A tone that is warm, direct, and human—rather than clinical or institutional—signals that this is a safe place to be.

Form design—Intake forms deserve their own category here. A form that asks sensitive questions without explaining why, or that requires information someone may not feel safe providing, or that has no way to save progress and return later—these are design failures with real consequences. Every question on an intake form should be there for a reason that would make sense to the person filling it out, and where possible, that reason should be stated.

Visual design—Color, imagery, and layout all carry emotional associations. High-contrast, high-urgency visual design—lots of red, bold alerts, aggressive CTAs—can feel activating and stressful for someone in a heightened state. Calmer palettes, generous white space, and imagery that centers dignity rather than crisis tend to feel safer.

So does your organization need it?

If your organization serves people who have experienced trauma—and for most nonprofits, the honest answer is yes, even if that’s not your primary focus—then trauma-informed web design isn’t a luxury feature. It’s a baseline responsibility.

That doesn’t mean you need to rebuild your site from scratch. It means asking, at every design decision: who is the most vulnerable person likely to use this, and does this work for them? It means reviewing your forms, your language, your navigation, and your content with that question in mind. And it means being willing to prioritize their experience over design conventions that might look good but create unnecessary friction.

If you’re not sure where your site stands, that’s a good place to start. I work with organizations on exactly this kind of review—looking at your existing site through a trauma-informed lens and identifying what’s working, what isn’t, and what the highest-leverage changes would be. You don’t have to overhaul everything to make a meaningful difference.

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.