Most accessibility conversations start, quite rightly, with people. Someone using a screen reader because they are blind. Someone who cannot use a mouse. Someone who needs captions, or plain language, or more time. That is the reason the work exists, and it is reason enough. But there is a second answer to the question who else cannot see your website? that almost never comes up in a marketing meeting, and it changes the business case entirely.
Google cannot see your website. Neither can ChatGPT, Perplexity, Copilot or Gemini. Neither can the browsing agent your customer just pointed at your booking form. Neither can Alexa, a Google Nest Hub, Siri, a car dashboard, a smart speaker, a kiosk in screen reader mode, or the procurement system quietly ingesting your PDF. None of them have eyes. Every one of them reads the same thing a screen reader reads: structure.
So if you are spending money on SEO, content, campaigns and discoverability while shipping interfaces and documents with no structure underneath them, you are not just excluding disabled customers. You are hiding from the machines you are paying to be found by.
First, the people. That part has not changed
Accessibility exists so that people can use things. That includes people with vision impairment, cognitive and learning disabilities, physical and motor disabilities, deafness and hearing loss, and speech disabilities. It also covers a much larger group most organisations forget to count: older people, neurodivergent users, people with temporary impairments such as a broken wrist or an eye infection, and anyone under a situational limitation, which is a polite way of saying bright sunlight, a moving train, one hand on a pram, or a very bad day.
We have written the full version of that argument in understanding digital accessibility for disabilities and why web accessibility matters. Nothing in this post replaces it. What follows is the part that tends to unlock budget.
Search engines have never had eyes
A crawler does not look at your page. It parses it. It builds a model of your content from the markup, and the quality of that model is set almost entirely by decisions that also happen to be accessibility decisions:
- Headings are the outline. A screen reader user jumps between headings to understand a page. A crawler does the same thing to work out what the page is about and how it is organised. A page styled with big bold text instead of real
h1toh3elements has no outline for either of them. - Alternative text is the only description of an image that exists. Nothing on the page tells a machine what a photograph, chart or infographic contains except the alt text you wrote. Leave it blank and that content is simply absent.
- Link text is the map. Screen reader users pull up a list of links to navigate. Search engines use link text as a relevance signal. Twenty links all reading "read more" damage both.
- Landmarks and semantics separate content from furniture. Proper
header,nav,mainandfooterelements tell assistive technology what to skip and tell a crawler which part of the page is the actual content. - Tables need headers. A data table with real header cells can be read cell by cell by a screen reader and understood as a dataset by a machine. A table built from styled divs is a picture of a table.
- Captions and transcripts are the only text version of your video. Audio and video are opaque to indexing. The transcript is what gets read, quoted and found.
None of this is an SEO trick. It is WCAG. If you want to see how directly the overlap runs, our WCAG criteria search and WCAG 2.2 quick reference let you look up the exact success criteria behind each of the points above.
Answer engines read structure, then decide whether to quote you
Traditional search sent people to your page. Answer engines increasingly read your page and give the answer directly, with or without a link. That shifts what "being findable" means. To be used as a source, your content has to be extractable: a machine has to be able to lift a complete, correct, attributable chunk out of it.
The things that make content extractable are almost identical to the things that make it cognitively accessible:
- A clear question or claim in a heading, answered immediately underneath it, rather than buried six paragraphs later.
- Short, declarative sentences with the key fact stated in full, not resolved by a pronoun three sentences back.
- Plain language and expanded acronyms on first use, which is WCAG at Level AAA and also how a model disambiguates your topic.
- Genuine lists and tables rather than paragraphs pretending to be lists.
- Structured data such as FAQ, article and organisation schema, giving machines an explicit statement of what the page contains.
- Defined terms in one authoritative place, which is exactly why we built our accessibility glossary.
An organisation that writes clearly, marks up honestly and defines its terms is easier for a person with a cognitive disability to read and easier for an answer engine to quote. The same edit improves both. That is not a coincidence, it is what happens when meaning is encoded in the page rather than implied by the styling.
Agents are the newest users, and they navigate like a screen reader
This is the part moving fastest. Browsing and computer use agents now book, buy, compare and fill in forms on behalf of real people. They do not look at your interface. They operate on the DOM and the accessibility tree, the same machine readable representation of your interface that assistive technology consumes. Which means the failures that stop a screen reader user stop an agent, one for one:
- A button that is only an icon, with no accessible name, is an unlabelled control to both. Neither can tell you what it does.
- A form field whose label is only visually adjacent, never programmatically associated, cannot be filled reliably by either.
- A custom dropdown, date picker or modal dialog built from divs with no roles, states or focus management is unusable to both.
- A single page application that swaps content without announcing it leaves both stranded on a page that has silently changed.
- An error message shown only in red text, with no programmatic association to the field, is invisible to both.
The commercial framing is blunt. If an agent cannot complete your checkout, that is not an accessibility issue you can defer to next quarter. It is a customer who bought elsewhere. Every organisation currently asking how to be "AI ready" already has the answer in a standard it was supposed to meet anyway. We made the general version of this case in accessibility isn't a button or an add on, and Apple's Accessibility Nutrition Labels are an early sign of the same pressure arriving in app stores.
The hardware with no screen at all
Screens are becoming optional. A growing share of interactions happen on devices that never render your interface visually to anyone:
- Voice assistants and smart speakers. Alexa on an Amazon Echo, Google Assistant on a Google Home or Nest Hub, Siri on a HomePod. The entire interaction is spoken. What gets read out is your text content and its structure, or nothing.
- Cars. Apple CarPlay, Android Auto, and the systems Google builds straight into Volvo and Polestar dashboards deliberately restrict visual complexity and read content aloud, because the driver is doing something more important. This is situational limitation designed into the hardware.
- Wearables and small displays. Content gets reflowed, truncated and summarised, which punishes layouts that carry meaning in position and colour rather than in markup.
- Kiosks, ATMs and self service terminals. Many run a built in screen reader mode with headphones, exactly as required in accessible procurement.
- Machine to machine pipelines. Data extraction, monitoring, RSS, aggregation and archiving all consume structure, never pixels.
Every one of these consumes the accessibility layer. Build it once, properly, and all of them work. Skip it and you are betting your reach on the shrinking assumption that a human with good vision is looking at a large screen.
Documents are the biggest blind spot of all
Websites at least get attention. Documents rarely do, and they are where organisations lose the most machine readable content. A scanned PDF is a photograph of information. An untagged PDF has no headings, no reading order, no table structure and no alternative text, so a screen reader cannot navigate it, a search engine cannot index it meaningfully, and an AI system ingesting your policy library gets a soup of positioned characters.
Your annual report, tender response, product specification and price list are often the most valuable content you publish, and frequently the least readable to anything without eyes. Fixing that is ordinary, well understood work: correct styles and reading order in Word and PowerPoint, proper tagging in Acrobat and InDesign, and alternative formats where they are needed. Our document accessibility guide covers the method, and you can test a real file in minutes with our free document and page checker.
Where the overlap ends, and why that matters
We should be precise, because overstating this is how accessibility gets sold badly. Accessibility is not an SEO tactic, and treating it as one will lead you to do the wrong half of the work.
Plenty of accessibility requirements do nothing at all for machines. Colour contrast, visible focus indicators, target size, reduced motion, time limits, consistent help and error prevention exist purely so that human beings can perceive and operate the interface. No crawler benefits from a 4.5:1 contrast ratio. People do, and that is the point. Equally, plenty of SEO activity does nothing for accessibility, and some of it actively harms clarity.
The honest position is this: the structural layer serves everyone, human and machine, and it is the layer most teams skip. The perceptual and interaction layers serve people only, and they are not optional. You need both. A JavaScript overlay delivers neither, because it paints over the interface without ever fixing the underlying structure that all of these audiences depend on. And as we argued in anyone can buy an ice chisel, a scanner will tell you a page has issues, but it will not tell you whether a person or an agent can actually finish the task.
What to do with this
If you want the short, practical version:
- Audit the structure first. Headings, landmarks, names, roles, labels, reading order and focus. This is the layer with the widest return, because it serves disabled users, search, answer engines, agents and voice at once. An accessibility audit is the fastest way to find out where you stand.
- Test with real assistive technology, not only scanners. Automation catches roughly a third of issues. See manual versus automated testing and screen readers compared for what each method actually finds.
- Fix your documents. They are usually the largest volume of unreadable content you own, and the easiest win once a process is in place. Document remediation handles the backlog; training stops it refilling.
- Write for extraction and comprehension. Question shaped headings, answers stated immediately, plain language, defined terms, honest markup.
- Make it repeatable. One clean up is a project. A standard that survives your next redesign is a capability, which is the shift we describe in from reactive to resilient.
The framing we keep coming back to with clients is simple. You are already paying for discoverability. You are already paying for content. Accessibility is not a tax on that investment, it is the thing that lets any of it be read, by the customer using a screen reader, by the crawler indexing you tonight, by the answer engine deciding whether to cite you tomorrow, and by the agent that will try to buy from you next year.
None of them can see. All of them can read, if you give them something to read.
If you want to know how much of your site, app or document library is currently legible to any of them, that is exactly what we assess.