Accessibility work on a website usually arrives as a legal problem. A letter shows up, or an insurer asks a question, and the reflex is to buy a widget, drop it in the footer, and move on. That reflex is understandable, and it also misses something useful: a large share of the technical work that makes a page usable with a screen reader is the same work that makes a page legible to a search crawler. Both are consumers of your markup that never see your design.
This matters more for behavioral health and treatment providers than for most businesses. People arriving on those sites are often doing so under stress, on a phone, sometimes with a disability that is part of why they are seeking care. A contact form that cannot be completed without a mouse is not only a conformance failure. It is an admissions call that never happens.
A crawler and a screen reader read the same document
A screen reader does not read pixels. It builds an accessibility tree from the browser’s DOM — elements, their roles, their accessible names, their relationships to one another — and speaks that tree. Googlebot works from the same underlying material: it fetches the HTML, renders the page, and parses the resulting DOM, a sequence Google lays out in its in-depth guide to how Google Search works.
The practical consequence is that meaning carried only by visual presentation is invisible to both. A button that is understood as a button because it is a blue rectangle in the top right, with no accessible name and no button semantics, is a div to a screen reader and a div to a crawler. A step in a form flow that is communicated purely by which item is bold is communicated to nobody who is not looking at it. We wrote previously about what Googlebot actually sees on a JavaScript-heavy site, and the accessibility version of that question has the same answer: whatever ends up in the rendered DOM, and nothing else.
Headings are structure, not type sizes
WCAG 2.2, the current W3C Recommendation, requires under success criterion 1.3.1 that information and relationships conveyed through presentation also be programmatically determinable. Headings are the clearest case. A screen reader user navigating an unfamiliar page will frequently pull up a list of headings and jump, the same way a sighted visitor scans down the page. If your levels are chosen because an h4 happened to be the right size, that list becomes noise.
Search engines use the same markup to understand how a page is organized. One h1 that states what the page is, h2s that mark real sections, no level skipping, and no headings used on text that is not a section label. This is one of the rare cases where the SEO advice and the accessibility requirement are not merely compatible but identical.
Alt text, and the privacy wrinkle in healthcare
Success criterion 1.1.1 requires a text alternative for non-text content. Google’s Google Images documentation asks for descriptive alt text on the same images for a different reason. Write what the image conveys in context; leave alt empty for purely decorative images so assistive technology skips them rather than announcing a filename.
Treatment centers have an additional constraint here that general small business advice does not cover. Alt text describing who is in a photograph is text on a public page, and it is indexed. Describe the setting, not the people, and be careful that a caption or file name does not identify a client. We covered the wider version of this in our post on photos on treatment center websites.
Link text that survives being read out of context
Success criterion 2.4.4, Link Purpose (In Context), exists because of a specific behavior: screen reader users often list every link on a page to find the one they want. A page whose links are eleven instances of “Learn more” and four of “Click here” is unusable in that mode. It is also a wasted signal, because anchor text is one of the things search engines use to understand what the destination page is about. “Verify your insurance benefits” does both jobs. “Click here” does neither.
Contrast, and text baked into images
Criterion 1.4.3 sets a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text; 1.4.11 sets 3:1 for the visual boundaries of interface components and meaningful graphics. These are measurable, which makes them among the easier things to fix on a redesign rather than after one.
The related failure is putting real content into a graphic. A phone number, an admissions hours line, or a facility address rendered as part of a hero image is unavailable to a screen reader and unavailable to a crawler, which means it also cannot be matched against a query, quoted in a search result, or copied by a visitor. Text should be text.
Forms are the conversion path, and the most common failure point
Criteria 3.3.2 and 1.3.1 require that form inputs have programmatically associated labels. A placeholder is not a label: it disappears on focus, it is not reliably exposed as an accessible name, and it fails anyone who needs to re-check what they typed. Criterion 3.3.1 requires that errors be identified in text, not signaled only by turning a field border red. Criterion 4.1.2 requires that custom controls expose a name, a role, and their current value.
For a provider, this is the highest-stakes area on the site, because the form is where inquiries are captured. A validation error that is announced only in color, on a field a keyboard user cannot reach, ends the visit. It is worth testing the primary conversion path with the mouse unplugged before testing anything else.
Keyboard access and visible focus
Criterion 2.1.1 requires that all functionality be operable from a keyboard, and 2.4.7 requires that the keyboard focus indicator be visible. The usual offenders are custom components — accordions, tabbed content, modal dialogs, and dropdown menus built from divs with click handlers, which a mouse can operate and a keyboard cannot. A related pattern matters for search too: content that only enters the DOM after an interaction the crawler does not perform may simply not be indexed. Hiding your treatment descriptions inside an accordion is fine; building that accordion so the content only exists after a click event is not.
What this does and does not do for rankings
Being accurate matters here. Google has not announced WCAG conformance as a ranking factor, and no one should sell accessibility remediation on the promise of higher positions. What semantic, keyboard-operable, properly labeled markup actually does is remove obstacles between your content and every machine that reads it — crawlers, assistive technology, and increasingly the systems generating AI answers, which extract from structured content rather than from layout. That overlap is a large part of why the groundwork for answer engine optimization looks so much like accessibility work.
A note on overlay widgets
Accessibility overlays are scripts that load on top of a site and adjust its presentation at runtime. They do not change the underlying markup, which means the heading structure, the unlabeled inputs, and the div-based buttons are all still there once the script is removed or fails to load — and they remain what a crawler parses. Overlays have drawn sustained criticism from accessibility practitioners for that reason. Treat one as, at most, a temporary layer over work that still needs doing.
Where to start
Run a keyboard-only pass on your highest-value path first: home page to service page to contact form to submitted. Then check the heading outline on your main templates, then alt text, then form labels. Automated checkers are worth running, but the W3C is direct in its guidance on evaluating accessibility that automated tools cannot detect every issue and human evaluation is required — a clean scan is a starting point, not a result. The full criteria are published as WCAG 2.2 at the W3C, with a plain-language overview in the WAI standards documentation.
Legal exposure around web accessibility varies by the type of organization and by jurisdiction, and healthcare providers may have obligations from more than one direction; that question belongs with your attorney rather than your marketing agency. The build question does not. If a redesign is on the table, specifying conformance up front costs far less than retrofitting, and it is a reasonable thing to ask for in a web design scope. The reading machines and the readers want the same thing.
