Not A Hypothetical

We checked a real eyecare website this month. Here's what 478 pages were hiding.

An eyecare group with several locations. Built by a well-known vendor in this industry. Live, and taking appointments every day. Nothing looks broken if you glance at it from the waiting room. We checked every page we could reach. Every number below is something we saw, not something we estimated.

Four people at home — on a phone, a desktop computer, a tablet and a laptop — each looking at a health care website.
She finds the problems before any scanner does. 478 pages checked, 65 found.
Short answer

What does a website check like this actually look at?

We run 244 separate checks across 13 areas on every page we can reach. That covers all 55 rules in the WCAG 2.2 AA accessibility standard, how the site handles security and patient privacy, how fast it loads, and whether it gives AI assistants anything to repeat. Anything a scan cannot settle on its own gets marked as needing a person to look at it. We never write it down as a pass.

Run My Free Audit (opens in a new tab)
  • 244 checks across 13 areas, each scored on its own
  • All 55 rules in the accessibility standard, checked or named
  • Run with the same testing tools the industry uses, all named in our notes
  • One real check: 478 pages, 65 problems, 15 of them serious
65separate findings
15serious — either it blocks a patient or it opens a security hole
4,600separate times those problems appear across the site
478pages checked
All 65 problems, area by area
Disability access

What a blind patient's software runs into.

  • 1,005 of 5,401 images had nothing written to describe them. That is 19% of everything a blind patient needs read aloud.
  • 135 of 182 form fields had no name attached. A blind patient hears an unnamed box and has to guess what goes in it.
  • One page shipped with no title at all — so the browser tab was blank, and so was what a blind patient heard.
  • 1,940 forms could not tell a browser what to fill in automatically. That is the feature patients with tremor or memory trouble rely on.
  • 464 pages told phones to turn off pinch-to-zoom.
  • 5 patient-education videos came back with no captions listed. We held that for a person to confirm rather than count it as a failure.
Security & patient privacy

What the patient's browser was never told to block.

  • Three core security headers missing — these are the settings that let a patient's browser stop bad code and hijacked clicks before they reach the page.
  • No consent platform on pages that take appointment requests, even though Google's tracking tools were running there.
  • The server announced its framework and version every time someone loaded a page. That hands an attacker a free map of what to try.
  • 5 staff email addresses sitting on the public web — a ready-made target list for scam emails aimed at people with chart access.
  • Two analytics cookies were set without the protection that keeps them from traveling unencrypted. We saw this in the browser ourselves.
Found & Cited

What Google and AI had nothing to work with.

  • A service page carried a "noindex" tag. That tells Google not to list the page at all. Patients searching for that service find a competitor instead.
  • 100 pages had no search-result summary, so Google grabs whatever text it happens to find instead of the description you would have written.
  • 18 pages shared one title — and that shared title was a blank space.
  • Half the service pages carried no question-and-answer content — so there was nothing for ChatGPT or Google's AI to repeat back to a patient.
  • 3 of 14 recommended healthcare directories were linked from the site's own code.
  • Two links led to pages that no longer exist — and one of those broken links sat on more than 300 pages.
A second exposure most owners have never been told about

The ADA is not the only law that reaches your website. HIPAA, the patient privacy law, can too. That site ran Google's tracking tools on its appointment pages with nothing asking the patient's permission first. Health and Human Services has said booking pages can hand patient health details straight to tracking companies. It has also said a cookie banner is not the kind of permission HIPAA asks for. Whether that breaks the rules is a question for your lawyer, not a scanner. Most practices have never been asked it. Every OptiSite site is set up from day one so nothing tracks a patient until they say it can.

Two things we won’t overstate about this audit

Two things we won't overstate.

The scan covered 40 of that site's 159 page layouts. So 65 is the low end, not the total. Any check a scan cannot settle gets marked as needing a person to look at it. We never print it as a pass. That is why our report does not hand you a comforting green score.

And here is the part that should stop you: that practice was paying for a well-known accessibility button on every single page.

Run My Free Audit → (opens in a new tab)
The Compliance Myth

That little accessibility button? It isn't protection.

You have seen the floating accessibility button in the corner of a lot of websites. It sits on top of the site and tries to patch problems as the page loads. It feels like protection. It is not, and courts have been blunt about that.

From the audit above. That practice was paying for one of these buttons on all 478 pages. Underneath it, our scan still found 16 accessibility rules failing. Pictures with no description. Text too faint to read. Form boxes with no name. A page with no title. The button was there. So were the failures. The Federal Trade Commission fined a major seller of these buttons $1 million for selling that gap as protection.

See a contrast failure the way a patient sees it
Stop Reading About It

This is a contrast failure. Press the button.

Every report prints something like "contrast — fail," and it means nothing until you see it. Press the button. That is roughly how an ordinary practice homepage looks to a patient with moderate vision loss.

This is an illustration, not a clinical model. No screen can reproduce one person's vision. The point still stands: text that looks fine on your monitor can be unreadable to the patient it was written for.

Welcome to our practice

Comprehensive eye exams, contact lenses and designer frames for the whole family. Walk-ins welcome.

Book an appointmentCall the office
Mon–Fri 8:00–5:30 · Sat 9:00–1:00
Most vision plans accepted · New patients welcome
What "We Check It" Actually Means

244 checks, in 13 areas, on every page we can reach.

Not a score out of a hundred with nothing behind it. The same scan runs on the site you have now, on the new one, and every month after that.

Split image: a phone showing a Google search for eyecare beside a monitor where an AI assistant answers the same question.
Thirteen areas, and two of them are about being findable at all — on Google, and in an AI answer.
The 244 checks, area by area
62Disability accessAll 55 rules in the accessibility standard, plus 7 more the ADA reaches
  • 1.1.1Images have text descriptions (alt text)
  • 1.3.1Headings & structure read correctly to screen readers
  • 1.4.1Meaning isn’t conveyed by color alone
  • 1.4.3Text has enough contrast to read
  • 1.4.13Pop-ups on hover can be dismissed
  • 2.4.2Every page has a descriptive title
  • 2.4.4Link text says where the link goes
  • 3.3.2Form fields have labels or instructions
  • 4.1.2Controls work with assistive technology
  • 1.3.5Form fields declare what they collect (autofill)
  • 1.4.4Text can be enlarged without breaking
  • 2.2.2Moving/auto-updating content can be paused
  • 2.4.1A “skip to content” link is available
  • 2.4.6Headings and labels are descriptive
  • Patient intake forms offered as HTML, not PDF-only
  • New-tab links announce that they open a new window
  • 1.2.1Audio/video has a text alternative
  • 1.3.4Works in both portrait and landscape
  • 1.2.2Videos have captions
  • 1.4.2Auto-playing audio can be turned off
  • 1.2.3Videos have an audio description
  • 1.4.5Real text is used instead of pictures of text
  • 1.2.4Live video has live captions
  • 1.4.10Page reflows on small screens without side-scroll
  • 1.2.5Recorded video has audio description
  • 1.4.11Buttons & form borders have enough contrast
  • 1.3.2Content is read in a sensible order
  • 1.4.12Layout survives increased text spacing
  • 1.3.3Instructions don’t rely on shape or position alone
  • 2.1.1Everything works with a keyboard
  • 2.4.11Focused items aren’t hidden behind other content
  • 2.1.2Keyboard focus never gets stuck
  • 2.5.1Complex gestures have a simple alternative
  • 2.1.4Single-key shortcuts can be turned off
  • 2.5.2Taps can be cancelled before they fire
  • 2.2.1Time limits can be extended
  • 2.5.3Buttons’ visible text matches their spoken name
  • 2.3.1Nothing flashes in a way that risks seizures
  • 2.5.4Motion-based actions have a button alternative
  • 2.4.3Keyboard focus moves in a logical order
  • 2.5.7Drag actions have a non-drag alternative
  • 2.4.5More than one way to find pages (menu, search)
  • 2.5.8Tap targets are big enough on mobile
  • 2.4.7You can see where the keyboard focus is
  • 3.1.1Page declares its language for screen readers
  • 3.2.2Changing a field doesn’t cause surprises
  • 3.1.2Passages in another language are marked
  • 3.2.3Navigation is consistent across pages
  • 3.2.1Focusing an item doesn’t cause surprises
  • 3.2.4Same things are labeled the same way
  • 3.2.6Help/contact is in a consistent place
  • 3.3.1Form errors are clearly identified
  • 3.3.3Form errors suggest how to fix them
  • 3.3.4Important submissions can be reviewed/undone
  • 3.3.7You’re not asked to re-enter the same info
  • 3.3.8Login doesn’t rely on memory puzzles
  • 4.1.3Status updates are announced to screen readers
  • Accessibility statement and barrier-reporting contact
  • Linked PDF documents are tagged and readable by assistive technology
  • Accessibility policy claims match what the audit found
  • Password fields allow paste
  • Accessibility engine (axe-core) completes on every crawled page
37Security & patient privacyIs the site encrypted, locked down, and asking permission before tracking
  • Standard browser-security response headers present
  • Cookies set with HttpOnly, Secure and SameSite flags
  • CDN-hosted third-party scripts declare Subresource Integrity (integrity="sha...")
  • Session, authentication or CSRF cookies carry HttpOnly and Secure
  • Cookies with SameSite=None also carry the Secure flag
  • Framework/version headers (X-Powered-By, X-AspNet-Version, X-Runtime) suppressed
  • Server software version disclosed in response headers
  • Staff email addresses exposed in the page source (phishing vector)
  • HSTS response header enforces HTTPS on repeat visits (Strict- Transport-Security)
  • TLS certificate and protocol grade (Qualys SSL Labs)
  • SPF DNS record authenticates outbound email (RFC 7208)
  • New-tab links declare rel="noopener" (legacy hardening)
  • DMARC DNS record ties SPF+DKIM and enforces spoofing policy (RFC 7489)
  • CAA DNS record constrains which CAs can issue certificates (RFC
  • DKIM DNS record signs outbound email (RFC 6376) — probed common selectors
  • URL variants reach canonical in a single hop
  • DNSSEC signs DNS responses so a resolver can verify authenticity (RFC 4033)
  • Homepage resolves in a short, terminating redirect chain (no loops, no excess hops)
  • Every URL variant (http/https × www) redirects to the canonical
  • Common exposed-file paths (.env, .git/config, backup.zip, wp- config.php.bak) return non-200 from the origin
  • URL canonicalization uses 301 (permanent), not 302/307
  • Healthcare tracking-data flow and consent/BAA posture
  • URL variants redirect UP to HTTPS, never down to HTTP
  • Advertising pixels present alongside booking or portal surfaces
  • All URL variants serve identical practice identity content (phone, name, city)
  • Site is served over HTTPS
  • Insecure http:// resource references on an HTTPS page (mixed content)
  • Only the canonical hostname responds — legacy hosts (staging, blog, prior-brand) are decommissioned
  • Forms collecting patient information post over HTTPS
  • Legacy hosts set HSTS, X-Content-Type-Options, X-Frame-Options
  • Privacy / HIPAA notice near any patient-information form
  • Legacy host cookies carry Secure, HttpOnly, SameSite flags
  • Content-Security-Policy script sources — wildcard, 'unsafe-inline' or 'unsafe-eval' — NOT APPLICABLE THIS SCAN
  • JavaScript libraries loaded on the site are not at versions with known public vulnerabilities
  • Content-Security-Policy form-action directive — NOT APPLICABLE
  • Homepage redirect chain preserves HTTPS transport end-to-end (no https→http downgrade)
  • Legacy X-XSS-Protection header not sent (browsers ignore it; some misuse harms)
21Getting found on GoogleCan Google find, read and list every page
  • Service-content URLs are not noindexed
  • Open Graph social-share preview tags
  • Exactly one top-level heading (H1) per page
  • Every page has its own search-result summary (meta description)
  • Pages beyond the homepage are not hidden from search unintentionally
  • URLs the Internet Archive shows as previously live still respond
  • Historical URLs redirect to their moved content, not the homepage
  • Historical URLs that still serve content are reachable from the sitemap
  • Practice ranks in Google’s top 10 for its brand + specialty query
  • Service / condition page coverage depth
  • Internal linking density between pages
  • Canonical tag present
  • Canonical target matches the domain under review
  • Homepage is indexable (no noindex directive)
  • Pages returning HTTP 200 carry real content, not a soft 404
  • Homepage X-Robots-Tag response header does not declare noindex
  • Sitemap URLs are not also marked noindex
  • Sitemap URLs declare themselves canonical
  • Valuable indexable pages the crawler reached appear in the sitemap
  • URL slugs do not contain unresolved template placeholders
  • Every page is reachable by clicking from the homepage (no orphans)
21Local presence & reviewsName, address, phone, hours and map all agreeing everywhere
  • Practice hours on Google match hours published on the site
  • Body prose city mentions agree with the schema-declared address city
  • Provider names on team pages have corresponding Person/Physician schema entries
  • LocalBusiness / MedicalBusiness schema present
  • Patient reviews or testimonials surfaced on the site
  • Review schema markup follows Google review-snippet eligibility rules
  • Embedded map or Google Business Profile link
  • Name, address and phone (NAP) consistent across pages
  • Practice phone on Google Business Profile matches the site’s canonical footers
  • Practice address on Google Business Profile matches the site’s canonical footers
  • Business hours published as readable text or schema
  • Business hours published as machine-readable data
  • Social media profiles linked from the site
  • Breadth of social platforms linked
  • One-tap “Get directions” link to each office
  • “Get directions” links parse cleanly in non-Chrome clients
  • ZIP codes on the site match USPS records for their state
  • Body-content addresses agree with the canonical footer address
  • City names on the site match USPS records for their ZIP
  • Practice schema carries geo coordinates and areaServed
  • Each physical office maps to a single indexable location page
20Content & trustHow easy it reads, doctor bios, the disclaimers you need
  • Visible page text is free of template placeholders and filler copy (Lorem ipsum)
  • Content reading level suits a general patient audience
  • Dedicated pages for each core service and condition
  • Page titles are distinct from one another
  • FAQ section present
  • Privacy policy link present
  • After-hours / eye-emergency guidance published
  • Terms of service link present
  • Languages-spoken information published
  • HIPAA Notice of Privacy Practices published
  • Blog freshness (recency of the newest post found)
  • Medical disclaimer present on clinical content
  • Blog posts structured for search-engine featuring
  • Trust signals surfaced on the homepage
  • Blog posts lead readers toward booking
  • Doctor / provider bio page present
  • Footer copyright year is current
  • Provider bio depth: credentials and photo
  • Doctor school names in structured data match canonical form (no truncation)
  • Provider bios meet Google's health-content (E-E-A-T) bar
20Booking & getting patients to actHow easy it is to book, and whether insurance is spelled out
  • Disability-specific premises access stated per location
  • Patient portal link routes to your tenant sign-in, not the vendor generic landing
  • Analytics firing order relative to cookie consent — NOT APPLICABLE THIS SCAN
  • Content aimed at first-time patients
  • Website analytics or conversion tracking installed
  • Online contact-lens reorder path
  • Booking form field count kept low enough to complete
  • Per-plan coverage detail, not just a carrier list
  • Appointment forms ask only for what is needed to schedule (DOB/SSN move to intake)
  • Vision-plan vs medical-insurance billing explained
  • Payment options beyond insurance (financing, HSA/FSA, self-pay)
  • Accepted-insurance / vision-plan information published
  • Telehealth disclosures where telehealth is offered
  • Specific insurance carriers named, not just "most plans"
  • A booking channel beyond phone and form (chat or text)
  • Cancellation / rescheduling policy published
  • Coverage of the core booking signals (CTA, form, hours, phone)
  • Contact or appointment-request form present
  • Every enumerated call-to-action URL resolves (HEAD/GET, first- party only)
  • Patient portal or sign-in link present
19AI assistant visibilityWhether AI assistants can read your site and are allowed to
  • Summarization metadata for AI assistants (Open Graph + meta description)
  • Service pages carry question-and-answer content
  • Recommended off-site directories linked from the site’s own markup
  • Medical articles carry per-article E-E-A-T attribution
  • Site publishes machine-readable business data (structured data)
  • Recommended schema types present
  • Visible Q&A content carries FAQPage / Question markup
  • Name, address and phone present on every crawled page
  • Doctors described in structured data (Physician / Person schema)
  • Practice name spelled consistently across the site
  • robots.txt does not block AI crawlers (GPTBot, PerplexityBot, Google-Extended, ClaudeBot)
  • AI-readiness file (llms.txt) present
  • Entity-linking (sameAs) present in structured data
  • Question-form headings and FAQ text across the crawled corpus
  • Health content carries doctor attribution (Google E-E-A-T)
  • Structured data parses without errors
  • Clinical-term headings paired with patient-phrased questions
  • Condition pages cover symptoms, causes, treatment and cost
  • Practice name matches the registered domain
11Speed & loadingHow fast pages load for real visitors, not in a lab
  • Images use lazy-loading (site-wide)
  • Cumulative Layout Shift (CLS) vs Google “Good” threshold
  • Images use lazy-loading (homepage above-the-fold)
  • Time to First Byte (TTFB) vs Google “Good” threshold
  • Render-blocking inline scripts in <head>
  • First Contentful Paint (FCP) vs Google “Good” threshold
  • Every page template hits Google’s “Good” LCP threshold on mobile
  • Total Blocking Time (TBT) vs Google “Good” threshold
  • Speed measured separately per page template (service, location, booking) — MANUAL REVIEW
  • Largest Contentful Paint (LCP) vs Google “Good” threshold
  • Interaction to Next Paint (INP) vs Google “Good” threshold
11Behind-the-scenes code qualityIs the code clean, with no duplicate or broken pages
  • Content images across the site have descriptive alt text
  • Distinct URLs return distinct content (no cross-URL duplication)
  • Homepage title tag present
  • Title tag length within search-result display limits
  • Homepage meta description present
  • Favicon (site icon) present
  • robots.txt does not block the whole site from search engines
  • robots.txt present
  • robots.txt references the sitemap
  • Character encoding declared
  • Markup avoids obsolete or deprecated HTML elements
8Mobile experienceDoes it work on a small phone, with buttons big enough to tap
  • Responsive viewport meta tag present (homepage)
  • Phone number is tap-to-call on a phone (tel: link)
  • Responsive viewport meta tag present (every crawled page)
  • Layout adapts to a phone screen (deep-battery re-check)
  • Page content fits the phone viewport without horizontal scroll
  • Page regions locked to a fixed desktop width
  • Body text size comfortable on a phone
  • Page reflows at a phone viewport width (headless-browser check at 320px)
7Ease of useEasy menus, a clear next step, nothing playing on its own
  • Background video auto-play behaviour
  • Online appointment-booking path present
  • Phone number rendered as a tappable tel: link (homepage)
  • Media does not auto-play with sound on load
  • Primary navigation remains reachable while scrolling
  • Phone number reachable in one tap (share of crawled pages)
  • Clear primary call-to-action above the fold
6First impressionWhat a patient sees before they scroll at all
  • Viewport tag does not disable pinch-to-zoom
  • Hero imagery does not push all content below the fold
  • First screen carries a heading and a clear next step
  • Phone / contact visible without scrolling
  • Headline or practice name visible in the first screen
  • Body text set at a comfortable reading size
1Trust & credibilityPhone in content agrees with the footer
  • Phone number in page content agrees with the footer
244checks registered
13areas, scored separately
55accessibility rules, each listed once
0passes we print without actually seeing one
Why there is no reassuring green score

The number that isn't there is the point.

A check a scan can’t settle — does a signed agreement exist, does a keyboard journey complete — is reported as needing a person. A check we don’t attempt is named as out of scope. You get the shortfall along with the findings.

Questions, Answered

More on this page’s topic

What did the real audit find on a live eyecare website?
We read 478 pages. We found 65 separate problems, showing up 4,600 times. 1,005 of 5,401 images had no text description, 1,940 forms could not tell a browser what to autofill, and 464 pages switched off pinch-to-zoom. The site already had a name-brand accessibility widget running on every page.
Does an accessibility widget make a website compliant?
No. That button sits on top of the page. It cannot fix the code underneath, and practices paying for one have still been sued. The practice we checked was running a well-known one on all 478 pages, and underneath it our scan still found 16 accessibility rules failing. The Federal Trade Commission fined a major seller of these buttons $1 million for selling that gap as protection. OptiSite fixes the code itself — alt text, contrast, labels, headings and focus order — so the page is conformant with the widget removed.
Do you audit every page of a website?
Every page the scanner can reach. On the check shown here, it read 40 of the site’s 159 page layouts. So 65 problems is the low end, not the total. Coverage limits are stated wherever they apply.
Now Do The Same For Yours

That was somebody else’s site. Run yours.

Free, evidence-based, every finding independently verifiable · no signup, no card

Book A 30-Minute Call or audit your site first at WebReady360 → (opens in a new tab)