What a Screen Reader Actually Announces on a Practice Website

Accessibility reports are written for engineers. A finding reads something like "4.1.2 Name, Role, Value: frame element has no accessible name," which is precise, correct, and does almost nothing to convey why anyone should care. Rewrite it as what a screen reader announces to a real person and the same finding becomes impossible to ignore.

So here is the same information written differently. What a screen reader announces, in the words a person actually hears, taken from real findings on real medical practice sites. The translation costs nothing and changes how the work gets prioritised, because one version is a rule and the other is a person stuck.

What a screen reader announces on a typical practice site

Three announcements account for most of what goes wrong on a practice website, and each of them is a single word or short phrase sitting where a full sentence should have been.

"Frame." An iframe with no title attribute. The user is told something exists and nothing about what. On a practice site the unnamed frame is very often the appointment scheduler, the reviews widget or the map, which is to say the three things a prospective patient is most likely to be looking for.

"Link." A link whose only content is an icon or an image with no alternative text. We found this on a real practice contact page, on the link to directions. A person navigating by links hears a list of destinations, and one of them is called "link". Screen readers offer a way to list every link on a page and jump to one, which is fast and useful right up to the point where several entries in that list are indistinguishable from each other.

"Edit, blank." A text input with no programmatically associated label. The visitor knows there is a field, knows it is empty, and does not know what it wants. On a consultation form with six fields, several of them unlabelled, the interaction becomes guesswork.

The consultation page, line by line

Put those together on the page that matters most and you can follow the experience end to end.

A visitor arrives on a treatment page and navigates by headings, which is how most experienced screen reader users move through a document. If the headings are in the right order they get an outline of the page in about ten seconds. If a page builder has produced a heading order driven by visual size rather than document structure, they get a jumbled outline and have to read linearly instead.

That distinction is worth understanding because it is so easy to introduce. In a page builder, heading levels are frequently chosen from a dropdown that also controls type size, so a designer wanting a smaller subheading picks a lower level and a designer wanting emphasis picks a higher one. The visual result is exactly right and the document structure now says something false about how the content is organised. Reading linearly instead of by outline turns a ten-second orientation into several minutes of listening, on every page.

They reach the booking section. The scheduler is an embed, so they hear "frame". Nothing indicates whether entering it is worthwhile, so they enter it, because the alternative is missing the only booking mechanism on the page.

Inside, they tab through the fields. Labelled ones announce properly. Unlabelled ones announce "edit, blank". Where a field is required and the validation message appears visually in red text without being programmatically associated, submitting produces a form that has silently failed with no announcement of why.

That last one deserves emphasis because it is invisible from the practice's side. Nobody sees an abandoned booking. There is no error log, no support ticket, and no way to distinguish it from someone who changed their mind. The failure is completely silent in both directions.

Why "frame" is the most common word

Unnamed frames rank second in every scan we run, and the reason is structural rather than careless.

Practice sites depend on third-party embeds for the commercially important features: scheduling, reviews, maps, chat. Each arrives as a snippet the vendor supplies, pasted in as given. Vendors frequently omit a title attribute from their sample code, and there is no reason a practice would add one, because the page looks correct.

That last clause is the general explanation for most of this. Accessibility defects are almost never visible to the person who introduced them, because they are defects in information the browser exposes to assistive technology rather than in anything drawn on screen. A missing frame title, an unlabelled input and a heading marked up for its size rather than its rank all render identically to a correct version. The page passes every check a sighted person performs simply by looking at it, which is why these problems persist on sites that are otherwise carefully maintained by people who care.

Understanding that changes how you should read a scan report. It is not a list of things somebody got wrong through inattention. It is a list of things that are invisible unless you specifically go and measure them, which is the argument for measuring them on a schedule rather than relying on anyone noticing.

The fix is a single attribute on an element you already have, and it takes about a minute per embed. It is the highest ratio of benefit to effort anywhere in accessibility work, which is why it sits second in the priority list in the WCAG failures we find most.

What a screen reader announces once it is fixed

The improvement is not subtle, and that is the argument for doing it.

It is worth being clear that the goal here is not a remarkable experience. It is an ordinary one. A well-labelled form is not delightful to use with a screen reader; it is simply usable, in the way a form is usable with a mouse. The bar being cleared is low, which is exactly why failing to clear it is hard to justify once someone has heard the difference.

The same page, with frames titled and fields labelled, announces "Appointment scheduling, frame", then "Preferred appointment date, edit, blank", then "Reason for visit, edit, blank, required". Every step now tells the user what is being asked. Nothing about the visual design changed, no visitor without assistive technology would notice any difference, and the page went from unusable to ordinary.

This is also why an injected widget cannot do it. Supplying those strings requires knowing what the field is for, which is a fact about your practice rather than a property of the markup, and that argument is made fully in why overlays don't fix it.

How to hear it yourself

You do not need to install anything, though you can. Both major desktop operating systems ship a screen reader, and a fifteen-minute session on your own consultation page is more persuasive than any report.

If that feels like too much, do the keyboard version instead. Put the mouse away, load a treatment page, and tab from the top through to submitting a consultation request. Count how many presses it takes to reach the main content, notice whether you can always see where focus is, and check whether any modal traps you. Those three failures are among the most common reasons a booking is abandoned and none of them is visible when using a mouse.

Then, whichever you do, write down what you found and re-check it after your next site change, because these regress quietly through plugin updates and new campaign pages. The value of scheduled scanning is that it notices the regression rather than the original defect, which is the same reason the consent side of our work keeps a dated record rather than a one-time configuration note. Both are about knowing what was true and when, and the specific standard behind each announcement above is set out in WCAG 2.1 with techniques listed in the quick reference.