Web Accessibility for Nonprofits: A Complete Guide

Access to the web is a requirement for full participation in modern society. Whether reading the news, registering to vote, or applying for a job, everyone should have equal, barrier-free access online.

As website managers and product owners, we have a business, legal, and moral imperative to make (and keep) our websites accessible.

Maybe you're going into a big redesign, and you want to make sure your new site is accessible. Or maybe you've been asked to "make the website accessible" and are wondering how to start.

This guide is for nonprofit digital teams who are navigating the complex world of accessibility. It includes:

• A definition of web accessibility
• An overview of web accessibility standards and the legal landscape
• Talking points for helping others understand the value of investing in accessibility
• Best practices for building and maintaining an accessible website
• Three steps to get started making your website more accessible today

While this guide is comprehensive, you don't need to do everything at once. Accessibility is a journey, and there are always more things to learn. Any step you take that makes your website even slightly more accessible is a step worth taking.

What is web accessibility?

One in four people in the United States has a disability.

When people with disabilities access the web, some require assistive technologies to use computers, such as screen readers, refreshable Braille displays, and screen magnifiers.

Others require websites to meet certain baseline standards. Things like meeting color contrast thresholds, being accessible via keyboard and not just a mouse, images having alternative text descriptions, videos having captions, and many other requirements.

Others might need content written in a readable, predictable way to ensure they can understand it. Things like avoiding jargon and unusual words, providing labels and instructions to prevent errors on forms, and designing an information architecture that is easy to navigate.

Just as poorly designed buildings prevent access to people with disabilities, poorly designed websites create barriers on the web. Access problems often occur because website designers mistakenly assume that everyone sees and uses a website in the same way they do.

Learn more about the fundamentals of web accessibility:

• How People with Disabilities Use the Web (W3C Web Accessibility Initiative)
• Introduction to Web Accessibility Video (Michelle Williams & A11Y Project)

Inclusive & Universal Design

While they are distinct concepts and design methodologies, web accessibility overlaps significantly with inclusive and universal design.

Disability isn't always permanent. Temporary or situational obstacles can also prevent people from accessing your site. A broken wrist might require someone to temporarily use a keyboard instead of a mouse, or a person might want to turn on closed captions on a video when they are in a public space.

Designing accessible experiences often results in a better, more usable experience for all people. When sidewalk curbs are cut to aid wheelchair users, people pushing strollers and riding bikes suddenly have a much better experience. Often, the things we do to make things accessible to people with disabilities will have a "curb-cut effect" and benefit everyone.

Learn more about inclusive and universal design, and how it intersects with accessibility:

• Inclusive Design Methodology & Toolkit (Microsoft)
• Inclusive Design (Institute for Human-Centered Design)
• Accessibility, Usability, and Inclusion (W3C Web Accessibility Initiative)

The Web Content Accessibility Guidelines (WCAG)

The most widely agreed-upon standards for accessibility compliance are the World Wide Web Consortium's Web Accessibility Initiative Web Content Accessibility Guidelines (W3C WAI WCAG).

The W3C is the leading international standards organization for the web. It was founded in 1994 by Tim Berners-Lee, the inventor of the World Wide Web. In addition to accessibility standards, it also provides standards around HTML, CSS, and many other web-related tools and technologies.

WCAG can feel overwhelming at first glance. The current version has 86 success criteria with tons of supplementary materials to comb through. A good place to start is with the four categories that each of the 86 rules fall into —which helpfully use the acronym POUR:

• Perceivable — Rules to help users perceive your web content
• Operable — Rules to help users operate your website
• Understable — Rules to help users understand your web content
• Robust — Rules to help browsers and assistive technologies interpret your website

The next thing to understand is that each of the 86 criteria has a conformance level of A, AA, or AAA (A being the lowest level of support and AAA the highest). AA support is widely recognized as best practice for most web content.

AAA compliance is typically reserved for parts of websites that serve a specialized audience. WCAG 2.2 itself states, "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content."

The guidelines are continuously updated and released as our society and its technological landscape change. The current version of WCAG is v2.2, and WCAG v3.0 is in a "Working Draft" status with a launch date of "a few more years."

Lastly, it's important to remember that WCAG is not the end-all, be-all. It is the best starting point for designing accessible interfaces, but there is no substitute for testing with real people with disabilities.

The Legal Landscape

Many organizations are concerned about their accessibility compliance, especially after several high-profile lawsuits against companies whose websites were not accessible (like H&R Block, Domino's, and the California State Park reservation site).

While I'm not a lawyer, I follow experts like Lainey Feingold and Kris Rivenburgh to stay up to date on shifting requirements.

Here is a high-level overview of the two primary federal laws in the U.S. that relate to website accessibility:

• The Americans with Disabilities Act (ADA) is a civil rights law that prohibits discrimination based on disability. For a long time, the ADA didn't explicitly mention websites. However, the Department of Justice (DOJ) recently updated Title II (for state and local governments) to require that websites meet WCAG 2.1 Level AA standards with deadlines beginning in 2026. For Title III (private businesses), courts and the DOJ still generally treat WCAG as the "gold standard" for compliance, even though the law hasn't yet been updated with specific technical rules.
• The Rehabilitation Act applies to federal agencies and organizations receiving federal funding. Section 508 of the act specifically requires their digital technology to be accessible. While the law is currently tied to WCAG 2.0, aiming for WCAG 2.2 AA is the best way to ensure you are meeting modern user needs and any upcoming federal refreshes.

In addition to federal laws, many states have local anti-discrimination laws that run in parallel to the ADA. Generally, as long as your website conforms to WCAG v2.2 AA, it will likely comply with these local laws as well.

Disclaimer: The information in this section is not legal advice. If you have questions about how these policies apply to your specific situation, please consult legal experts.

The Case for Accessibility

If your organization is having trouble prioritizing accessibility work, there are many compelling reasons for dedicating time and resources to making your website accessible. Prioritizing accessibility helps you and your organization:

• Champion equity and inclusion: For many nonprofits, inclusion is a core value, if not directly tied to their mission. Making your website accessible ensures your digital presence reflects your organizational commitment in a tangible way.
• Improve your search rankings and presence on AI search: Accessibility best practices, such as including alt text on images and transcripts for audio content, make it easier for search engines to crawl and understand your content.
• Spark innovation and improve usability: Designing for accessibility often reveals better ways to solve problems. Much like sidewalk curb-cuts benefit people with strollers or bikes, the same pattern holds true for technology: closed captions, audiobooks, autocomplete text, and voice dictation all began as innovations for people with disabilities before becoming tools billions of people rely on every day.
• Expand your impact: In the U.S. alone, over 70 million people have a disability. Accessibility ensures that your services, advocacy, and resources reach the entire community you aim to serve.
• Minimize legal risk: Proactively addressing accessibility helps reduce legal risk. With new digital accessibility cases surfacing every month, being proactive is a form of responsible risk management.

How to make a website accessible

With proper planning and resources, websites can be designed to work with assistive technology and be perceivable, operable, and understandable by individuals with permanent, temporary, or situational disabilities.

Unfortunately, many sites today are built with accessibility barriers that make them difficult or impossible for people to use. WebAIM's annual accessibility analysis regularly reports that over 90% of the top one million homepages have at least one accessibility-related error.

Whether we are working on a full website redesign or doing ongoing support work, we hold to a few high-level principles to make our websites accessible:

• Shift Left: Accessibility is not just a thing developers need to know about. Designers, content writers, and product owners all need to consider accessibility in their work. We "shift left" and consider accessibility as early as possible in the product lifecycle.
• No exceptions for WCAG 2.2, Level AA: Everything mustadhere to WCAG 2.2, Level AA standards. We go beyond standards when we can, but we don't make exceptions for baseline accessibility standards.
• Partnership: Accessibility is also not something that just falls to us as an agency partner. Maintaining an accessible site requires close partnership with our clients to ensure content editors are trained in accessibility, and accessibility-related features and bug fixes are prioritized during sprints.

While our principles stay the same, our tactics for building an accessible website vary depending on the stage of the project.

Strategy

While accessibility can get lost in the swirl of KPIs, workshops, and research at the start of a project, you need to make sure your team considers the accessibility implications of the decisions you make during this phase.

One of the best ways to do that is to include accessibility within existing activities. For example:

• If you are conducting a series of user interviews to inform your strategy, include people with disabilities in your recruitment plan.
• If you are conducting a landscape analysis of other websites with content or features similar to yours, include a research question related to accessibility. Something like, "How are our competitors making their websites accessible?"
• When reviewing feature ideas, consider how they might affect people with disabilities. How will a person using a screen reader experience the map your team is excited about? How will someone prone to migraines or seizures respond to that animation?

Design

If a designer is not familiar with accessibility best practices, they might present designs that don't meet guidelines, like color contrast or touch target sizes. Or they may present a form or custom UI element that requires lots of development and ARIA roles to make accessible, when a small design change could have saved time and effort later on.

During design, we pay particular close attention to:

• Brand colors: An organization's visual identity might use colors that do not meet WCAG color contrast guidelines (or the new APCA color contrast standards). When this happens, we present our clients with accessible color pairings and clearly communicate which combinations work and which do not.
• Font Choices: While they don't technically "fail" WCAG, many fonts are difficult to read. When selecting fonts, we look for options that match a client's identity while remaining legible and performant. For example, we selected Atkinson Hyperlegible for Easterseals because it features distinctive letterforms (like a slash through the zero to distinguish it from a capital "O").
• Design Patterns: To adhere to WCAG 1.4.1 Use of Color and 1.3.3 Sensory Characteristics, we never rely on a single sensory characteristic, like color or shape, to convey meaning. For example, we don't rely solely on a red border to indicate an error in a donation form. We include an error icon and descriptive text. Similarly, we avoid instructions like "click the square button," as such descriptions aren't helpful for someone using a screen reader.
• Touch Targets: We design buttons and links with a large enough target size to be easily tapped. This is required by WCAG 2.5.8 Target Size to prevent users from accidentally clicking the wrong link.

And many more things that bridge the disciplines of accessibility and usability.

Content

Our clients are the subject matter experts in their work and produce and maintain the bulk of our websites' content. To help content editors produce accessible content, we put in guardrails and provide training.

For guardrails, we include the Editoria11y Accessibility Checker Drupal Module in all our projects. We like this module for a few reasons:

• It only highlights accessibility errors that content editors can fix.
• It functions like a "spellcheck" for accessibility issues and is intuitive for content writers without technical expertise.
• It shows accessibility errors inline while editors are writing.
• It does not modify any content — it only provides tips and advice.

For training, we offer dedicated accessibility-focused training for content editors. These training sessions included guidance from established resources in the accessibility and usability space, such as the Web Accessibility Initiative, Nielsen Norman Group, Yale's Usability & Web Accessibility resources, and The A11y Project. They include activities like:

• How to write in plain language and test for reading level.
• How to avoid common, easy-to-fix accessibility errors, like ordering headings correctly and writing links with sufficient context (avoiding "click here" and "learn more").
• How to provide alt text for images that sufficiently conveys the purpose of the image.
• How to determine when video or audio needs captions, transcripts, or an alternative audio track with audio descriptions.

Development

The front-end is the place where most accessibility errors exist on a website. At Capellic, accessibility is a foundational skill for our front-end team (our team holds certifications from the International Association of Accessibility Professionals and Section 508 Trusted Tester status).

We build front-end components with accessibility at the forefront of our minds. And, as a safety net, we use the a11y addon in Storybook (which uses Deque's axe-core) during development.

Testing

After main-line development ends, all features on the site undergo a dedicated, accessibility-focused quality assurance phase. This work involves running multiple automated accessibility audits (using tools like WAVE, Deque's Axe, and Sa11y), manual checks aligned with WCAG guidelines, and testing with assistive technologies like screen readers, magnification, voice input, and keyboard-only input.

If we are doing a large redesign with thousands of pages, we choose a representative sample of pages to test that covers all unique templates and components. Usually 1-3 pages of each content type.

A strong client-agency partnership is critical to an accessible site. Some areas of accessibility are tied directly to content decisions, which means our clients are the best people to test:

• Rich text content: While we will report any bugs we find in our representative sample of rich content (WYSIWYG fields), our clients are ultimately responsible for ensuring the content they write is accessible.
• Third-party tools and embeds: Our clients are responsible for ensuring that any third-party tools or embeds they include on pages are accessible. These include Canva embeds, map embeds, data visualizations, etc.

There are some subscription-based tools that scan entire websites that can help here. A few of the more popular ones are Siteimprove and Acquia's Optimize. These tools are typically pretty expensive, but they scan every single page on your site and can help you spot patterns. We recommend investing in tools like this if your site has a lot of content and is produced by lots of different people.

User Accessibility Testing

The last thing we do before launching a full site (and arguably the most important accessibility-related activity) is conduct a usability study with people with disabilities and those who use assistive technology (such as screen readers, screen magnifiers, and alternative keyboards) to navigate the web.

We partner with programs that recruit people with disabilities to participate in usability studies (such as Fable, Knowbility, and WeCo) to bring in five people with disabilities and test the site's primary user tasks. We encourage each participant to "think out loud" and share any instances of accessibility-related barriers or frustrations.

No matter how much expert and best practice testing we do beforehand, we always find a number of issues during user testing. This type of individual, real-life testing is a critical step to ensure your site goes beyond standards and automated tools.

Documenting Conformance and Accessibility Statements

When building a new site, we recommend that our clients include an Accessibility Statement page within their global header or footer.

This page should contain:

• Contact information for users to share accessibility-related feedback or request information in a different format
• A description of the methods you took to ensure the site was accessible — ideally, this would include a link to an Accessibility Compliance Report.
• A "known issues" log that lists the things that you know are not accessible
• A statement of commitment to accessibility

Read more about accessibility statements in our post, "Is Your Nonprofit Website Accessible? How to Show Compliance."

How to keep a website accessible

Web content changes daily. You release new features, and you publish new content. To keep your site accessible, ensure that every time something changes, the new code and content are held to the same standards as when you first launched your website.

You can put a few processes in place to help with this effort:

• Listen to your users. When someone reaches out to you via the contact form on your Accessibility Statement page, respond. Identify in advance who is responsible for getting back to people, and commit to responding within a few days.
• Establish checklists. Integrate accessibility checklists into your content production, design, and development workflows. Yale's Checklist for Content Editors and A11Y's Accessibility Checklist are both great starting points.
• Train your team. Train all new staff who touch the website on accessibility best practices. W3C's Introduction to Web Accessibility, University of Illinois's Introduction to Accessibility, The A11Y Project, and plainlanguage.gov are all great sources of asynchronous training.
• Prioritize remediation. When planning sprints, always set aside budget and resources to fix accessibility bugs. We usually recommend that each sprint has ~70% of tickets for new feature development and ~30% for bug fixing (which should include accessibility bug remediation). Establishing and agreeing to a framework like this helps to balance accessibility work with other priorities.
• Automate testing. Integrate a tool that scans and flags accessibility issues across your entire website. Tools like Deque's Axe Monitor, Level Access, Acquia's Optimize, or Siteimprove.
• Schedule deep manual testing. Every few years, bring in both an accessibility expert and people with disabilities to test your site, and create a new Accessibility Compliance Report.

Getting Started

There are a lot of things you can do to improve the accessibility of your website.

To make the work a little lighter, here are the first three steps I recommend you take, depending on if you are about to do a redesign or looking to make incremental improvements to your website.

First 3 steps to make your site more accessible

1. Run a quick accessibility analysis yourself. Identify 3 pages on your website that are critical to your mission and conduct a brief accessibility audit using W3C's Easy Checks – A First Review of Web Accessibility. This shouldn't take you more than 45 minutes. This will be a good bellwether to decide if you need to bring in an outside expert.
2. Add an Accessibility Statement page to your website. Even if all you have is a statement of commitment and a way for users to contact you, that is better than nothing at all.
3. Introduce an accessibility-focused checklist for your content editors prior to publishing their content. Look at Yale's Checklist for Content Editors for inspiration and consider including Sa11y in their workflow.

First 3 steps leading up to a website redesign

1. Include WCAG 2.2 AA as a requirement in your RFP and ask vendors to explain their process to ensure your website will be accessible in their proposal. Extra points if you also ask vendors to share what accessibility-related certifications their team has.
2. Plan to conduct user accessibility testing on the new site. At Capellic, we conduct user accessibility testing right before launch so we have time to fix any critical issues. No matter how much expertise your vendor has, there is no substitute for testing with people with disabilities.
3. Plan for an accessibility-focused training for your content editors. Even if your website is built accessible, a poorly written article can introduce barriers to your users with disabilities.

Accessibility is a journey

If you've had success improving the accessibility of your website, it might be time to look at the accessibility of other things at your organization.

Your organization's hiring practices, your internal tools and software, and non-website communication tools such as presentations, PDFs, and social media posts all deserve the same attention as your website.

Accessibility maturity models (like the ones by Level Access, Microsoft, Stark, and W3C WAI) help you build an accessibility program at your organization. And when you have a strong accessibility program, you increase the chances that accessibility work will continue to live on without your involvement.

Making it happen

Your website is how people access your services, join your cause, and take action. When your site has barriers, you're inadvertently excluding the very people many nonprofits exist to serve.

The good news? You have real control over this. You don't need to wait for a policy change or secure major funding. You need commitment, some focused effort, and the right partners.

The work doesn't end, but it does get easier. Once accessibility is built into how your team works, it stops being a special project and becomes just how you build for the web.