Two readers will visit your nonprofit's website and never see the design. One is a person using a screen reader, software that reads a page aloud for blind and low-vision users. The other is an AI crawler, the program that tools like ChatGPT and Perplexity send out to fetch and read web pages before they answer a question about your organization.
Both of them skip the layout, the photography, and the brand colors entirely, because both are reading the same thing: your raw HTML, the code underneath the page.
That overlap changes the math on accessibility. For years the case for it had two legs, legal compliance and mission values. There is now a third, and it costs nothing extra, because the same fixes that serve assistive technology also make your organization readable to AI assistants. The rest of this article goes through where that overlap holds, where it doesn't, and how to check your own site.
Two readers, zero pixels
A screen reader doesn't look at the rendered page. It walks the code, announcing headings, links, labels, and text in order, and its user navigates by that structure, jumping from heading to heading or pulling up a list of every link on the page to find the one that matters.
An AI crawler works the same way. It fetches your code, extracts the structure and the text, and that extraction becomes the version of your organization the AI knows. When a donor asks ChatGPT to recommend a food bank in your county, the answer is assembled from what crawlers could read, not from what a sighted visitor would see in a browser.
Neither reader gets your hero image, and neither notices the typography you agonized over. If the substance of your site lives in the visuals rather than the code, both of them end up with a thin, scrambled version of your work.
Where the overlap gets concrete
This isn't a loose analogy. The specific items on an accessibility punch list map onto AI readability almost one for one.
Heading hierarchy. Screen reader users navigate by headings, so a page needs one clear H1 and logically nested H2s and H3s underneath it. Crawlers infer your page's structure from the same tags. A page whose "headings" are just bolded, enlarged text has no skeleton that either reader can use.
Alt text. The written description attached to an image is what a screen reader announces in place of the photo, and it is also the only version of that image an AI ever receives. An impact photo with empty alt text is a blank space to both.
Descriptive link text. A screen reader user scanning a list of links hears "click here, click here, click here" with no way to tell them apart, and a crawler learns nothing about where any of those links lead. "Read our 2025 impact report" works for both.
Form labels. Properly coded labels tell assistive technology what each field is: name, email, gift amount. They also tell a machine that your donation form is a donation form rather than an anonymous cluster of boxes.
Transcripts and captions. A transcript is how a deaf visitor gets your video's content, and it is how an AI gets it too, because crawlers don't watch video. The founder story that only exists as footage is effectively unavailable to both audiences.
Content that doesn't depend on JavaScript. JavaScript is the code that assembles many modern pages inside the browser. Most AI crawlers don't execute it; they read the page as delivered, before any scripts run. Some assistive technology struggles with heavily scripted pages too. If your programs and mission only appear after JavaScript fires, a large share of your non-visual readers get something close to a blank page.
What we keep seeing in Scorecard runs
We run AI Visibility Scorecard checks on nonprofit sites all the time, and one pattern comes up constantly: visually excellent sites, often recent redesigns with strong brands and beautiful photography, whose raw HTML is nearly empty. View the source and the mission statement isn't in it, and neither are the program descriptions. The page was built to be looked at, not to be read.
Those organizations are invisible to AI and hostile to assistive technology at the same time, and they usually have no idea, because the site looks great in a browser. Nobody on staff has any reason to open the code until a supporter using a screen reader gives up on the donation form, or until an AI assistant recommends a peer organization instead.
The uncomfortable part is that these are often the sites that cost the most. The budget went into visual polish, and visual polish is the only one of these qualities that shows up in a design review.
Where the overlap ends
So, does web accessibility help AI visibility? For most of the punch list above, yes. But the overlap is large rather than total, and it's worth being clear about where the two audiences part ways.
Some accessibility work is purely for humans. Color contrast, keyboard navigation, and visible focus states (the outline showing which element is selected as you tab through a page) matter enormously to real users and mean nothing to a crawler. They're required by WCAG, the Web Content Accessibility Guidelines, which is the standard courts and auditors reference, and no AI benefit will ever show up from doing them, but they need doing anyway. Our guide to ADA compliance for nonprofit websites covers what that standard actually asks of you.
And some machine-readability work does nothing for humans. Schema markup, which is structured data you add to your code that explicitly labels your organization's name, programs, events, and locations for machines, helps crawlers identify you precisely, but a screen reader user never encounters it. We've written a full walkthrough of schema markup for nonprofits if you want that half.
Because the overlap isn't complete, an honest audit has to look at both sides rather than assuming one covers the other.
The case to bring to your board
If you've struggled to get accessibility funded, this overlap gives you a more useful framing for the conversation. Boards hesitate on "accessibility remediation" when it sounds like a compliance tax, money spent to make a lawsuit less likely with nothing to show donors. The overlap changes that calculation, because the same work that retires legal risk and serves people with disabilities also determines whether AI assistants can find, understand, and recommend you. It becomes a single budget line that addresses the legal exposure, honors the mission, and opens up the new front door supporters are increasingly using, and two of those three are things your board already says it cares about.
A 15-minute self-check
You don't need a developer to get a first read. Try these five checks this afternoon:
- View your source. On your homepage, right-click the page and choose "View Page Source," then search the code for a phrase from your mission statement. If it isn't there, your content is locked behind JavaScript, which makes it unreadable to most crawlers and fragile for assistive tech.
- Tab through your donation form. Put the mouse down and use only the Tab key. Can you reach every field, see where you are, and submit? If you get lost, so does anyone navigating by keyboard.
- Check your heading order. In that same source view, search for "h1" and "h2". You want one H1 per page, headings nested in order, and none skipped for visual effect.
- Check alt text on impact photos. Search the source for your key images and look for meaningful alt attributes, meaning a real description rather than "IMG_4032" or nothing at all.
- Hunt your "click here" links. Search the page for "click here" and "learn more." Every one you find is a link that tells both audiences nothing.
If you want to go deeper than fifteen minutes, our nonprofit website accessibility audit guide walks through the full process.
Check both halves
The machine half takes about a minute. Run the AI Visibility Scorecard and look at your AI Readability grade, which answers, with a letter, the question this whole article has been circling: whether the non-visual readers can actually read you.
The human half deserves human judgment. Book a free accessibility consultation and we'll walk your donation flow the way an assistive-tech user experiences it, then tell you honestly what to fix first and what can wait.
