WCAG 2.1 AA on a Practice Website: The Failures We Find Most

Most articles listing common WCAG failures are transcriptions of the specification with the success criteria renumbered as bullet points. That is a reading of the standard rather than a description of the world, and it is unhelpful because the standard has dozens of criteria while practice websites fail the same small handful over and over.

What follows is ranked by what actually appears when you scan medical practice sites, with the specific components that produce each one. It includes our own site, which scores 80 out of 100 on our own engine, because publishing that is more useful than pretending otherwise.

The common WCAG failures, ranked by what we find

Contrast dominates every scan we have run, and it is almost never a page-level problem. It is one or two colour tokens used in a shared header, footer or button style. On our own site, a single faint-text token used for breadcrumbs, footer legal notes and footer links produces nine instances per page across every page, which is the entire gap between our 80 and a considerably better number.

Frames without an accessible name is second and is almost entirely third-party embeds. Reviews widgets, maps, scheduling tools and chat boxes arrive as iframes, and an iframe with no title attribute is announced by a screen reader as simply "frame". The visitor is told something exists and not what it is.

Links with no discernible text covers icon-only links and image links with no alternative text. A social icon row, a phone icon in a header, and an embedded map link are the usual sources. On one real practice site the finding was an unnamed map link on the contact page, which is exactly where a patient trying to find you would be.

ARIA roles without required children is the page-builder signature, and the relevant criterion is 1.3.1 Info and Relationships. A carousel widget declares a list role on a container, then its script rewrites the DOM on initialisation so the children are no longer list items. The markup now claims a structure it does not have, which is worse than claiming nothing.

Why these particular failures cluster on practice sites

The distribution is not random. It follows from how these sites get built, and understanding the causal chain is what turns a list of findings into a short list of decisions.

Practice websites are template-driven, assembled in a page builder, and heavily dependent on third-party embeds for the things that make them commercially useful: reviews, maps, scheduling, chat. That combination produces exactly the ranking above. Contrast comes from the design system, frame names come from the embeds, and ARIA violations come from the builder's own widgets.

The multiplier is why instance counts are a poor measure of how much work is involved. Two sites can report identical totals where one needs a single variable changed and the other needs two hundred individual images given alternative text. Any report that gives you a number without telling you how many distinct causes produced it is not telling you what you need to know.

Which common WCAG failures automation can and cannot catch

Being precise about this matters, because both overstating and understating what a scanner does causes problems.

Automation is reliable for contrast ratios, missing accessible names, missing form labels, ARIA structure violations, duplicate element identifiers and document language. These are computable properties of a rendered page, and a good engine reports the measured value and the exact elements involved.

Automation cannot judge whether alternative text describes the image usefully, whether a heading structure reflects the actual document, whether link text makes sense out of context, or whether a multi-step process can be completed by keyboard alone. An image with the alternative text "image1" passes an automated check for the presence of alternative text and fails the point of the criterion entirely.

Two technical notes for anyone running their own scans, learned the hard way. First, the order of operations matters: if you simulate interaction to trigger lazily-loaded content, do the accessibility pass on the strict pre-interaction DOM first, because carousel scripts rewrite their own roles on initialisation and a post-interaction scan will silently erase a real finding. We hit exactly that and it moved a site from 70 to 81 while deleting a genuine ARIA violation. Second, some reporting modes drop the measured detail, so a contrast finding arrives without the ratio or the hex pair, which makes it unactionable.

The honest summary is that automation finds most of the volume and a person is needed for most of the judgment. A report claiming full coverage is overselling, and a report dismissed because it is automated is throwing away the cheapest available signal.

It is worth being clear about what a scan is evidence of, too. A scan reporting no common WCAG failures is evidence that the automated checks found nothing on the pages it opened, which is a narrower claim than the site being accessible. Two of the three qualifiers in that sentence matter: the checks it ran, and the pages it opened. We have written elsewhere about the second, having produced a falsely reassuring grade A on a real site purely because page discovery never reached the consultation path.

Where to start

Four steps, in the order that removes the most instances per unit of effort. Working through the common WCAG failures in this sequence means an unfinished project still leaves the site materially better, which a page-by-page approach does not.

Fix the shared tokens. Contrast in the header, footer, buttons and any muted-text style. This is usually a handful of values and typically resolves the majority of the instance count.

Name every frame. Add a title attribute to every iframe describing what it is: "Appointment scheduling", "Patient reviews", "Practice location map". Small edits, immediate effect, and it converts "frame" into a useful announcement.

Give icon links accessible names. Any link whose content is only an icon or image needs text a screen reader can announce. The WCAG quick reference lists the accepted techniques for each of these.

Then walk the conversion path with a keyboard. Tab from the top of a treatment page through to submitting a consultation form, without touching the mouse. This is the test automation cannot do and the one that most directly reflects whether a patient can book.

Do all four and re-scan, because the fourth frequently surfaces things the first three hid. Which pages to scan matters as much as what you scan for, a point covered in the rule with a date on it, and what these findings sound like to an actual user is in what a screen reader actually announces. What none of this needs is an overlay widget, for reasons set out in why overlays don't fix it.

A note on how to read your own numbers over time, because the trajectory matters more than any single figure. Scores move for two reasons: because something was fixed, and because something new was added. A practice that remediates thoroughly in March and publishes four campaign landing pages in April will see the number fall, and nothing has regressed in the work that was done. This is why a single point-in-time score is close to meaningless as a management metric, and why the useful question is whether new pages arrive at the same standard as remediated ones. If they do not, the site is on a treadmill and the remediation budget is being spent on the same defects repeatedly.

The mechanism that breaks the treadmill is not more scanning. It is fixing the templates that new pages are built from, so that a page created next month inherits the corrected tokens rather than the original ones. That is the same reason the first item in the list above is first.

The recurring theme across this and the tracking side of our work is the same: the useful artefact is a dated record of what was true, produced repeatedly rather than once. That is what accessibility monitoring produces here, and what consent gating produces on the tracking side.