Is your website ready for accessibility rules?
Type in your web address and get a clear report on the most common barriers that keep people with disabilities from using your site, the same barriers that trigger ADA complaints. What looks good, what needs attention, and why each piece matters, all in plain English. No account, no tricks, nothing stored.
This score measures accessibility readiness: how your homepage handles the barriers an automated scan can see. It is not a legal compliance certification, and no score guarantees protection from complaints or lawsuits. Full WCAG conformance also requires human testing.
Structure and navigation
32 of 50 points
The page declares its language.
- The <html> tag carries lang="en".
Screen readers speak your page out loud, and they need to know which language to pronounce. When the page does not declare one, software guesses, and text read with the wrong pronunciation rules can be hard to follow. This maps to WCAG 2.1 rule 3.1.1 (Language of Page).
The page has a descriptive title.
- Page title: "Example Bakery | Fresh bread in Sacramento"
The page title is the first thing a screen reader announces when the page loads, and it labels the browser tab. A clear title tells visitors where they are before anything else is read. This maps to WCAG 2.1 rule 2.4.2 (Page Titled).
Headings exist but the outline has rough spots.
- Headings found: 2 h1, 3 h2, 1 h4.
- Main heading: "Fresh bread, baked every morning"
- 1 place where the heading levels skip (for example an h2 followed directly by an h4).
- 2 h1 headings found; screen reader users expect one main heading.
People using screen readers often jump from heading to heading to skim a page, the way sighted visitors skim by eye. That only works when there is one main heading and the levels step down in order, like an outline. Skipped levels or a missing main heading make the page feel like a book with shuffled chapters. This maps to WCAG 2.1 rules 1.3.1 and 2.4.6.
The page marks its regions for screen readers.
- Found: main content region (<main>), navigation region (<nav>), header region (<header>), footer region (<footer>).
Landmarks are invisible signposts that divide a page into regions: the main content, the navigation menu, the header, the footer. Screen reader users jump straight between them instead of listening to the whole page from the top. Without them, every visit starts from the very beginning of the page. This maps to WCAG 2.1 rules 1.3.1 and 2.4.1.
No skip link and no marked main content region.
- No link matching a skip pattern was found among the first in-page links.
- No <main> region exists as an alternative way to bypass the menu.
Someone navigating by keyboard presses Tab to move through every link in order. Without a skip link, they must tab through your entire menu on every single page before reaching the content, which quickly becomes exhausting enough that people give up. This maps to WCAG 2.1 rule 2.4.1 (Bypass Blocks).
Pinch zoom is switched off.
- Viewport setting: content="width=device-width, initial-scale=1, user-scalable=no"
- user-scalable is set to no, which blocks pinch zoom on many phones.
Many people with low vision pinch to zoom on their phone to read text. Page code can switch that off, and blocked zoom is one of the most common accessibility complaints because visitors notice it immediately. The standard expects text to be enlargeable to at least double size. This maps to WCAG 2.1 rule 1.4.4 (Resize Text).
Nothing overrides the natural keyboard order.
- No elements with a positive tabindex value were found.
People who cannot use a mouse press Tab to move through a page, and they expect the order to follow the layout. A positive tabindex value forces an element to jump the queue, which scrambles that order in ways that are very hard to predict. This maps to WCAG 2.1 rule 2.4.3 (Focus Order).
Your site is secure, and the insecure address forwards visitors to it.
- HTTPS request succeeded (HTTP 200).
- http:// redirected to https:// with status 301.
This is the padlock visitors see in their browser. A secure connection protects everyone, and assistive technology users are hit hardest by browser security warnings, which can be confusing or impossible to get past with a screen reader. Your site should also forward anyone who types the old http:// address to the secure version.
Content and forms
30 of 50 points
Most images are described, but some need attention.
- 14 images: 10 with descriptive alt text, 1 marked decorative (alt=""), 1 with placeholder-style alt text, 2 missing the alt attribute entirely.
- Images missing alt text include: hero-banner.jpg, IMG_2041.jpg.
- Placeholder-style alt text found: "image".
Alt text is a short written description attached to each image. It is how a blind visitor's screen reader knows what a picture shows; without it, the visitor may hear a file name or nothing at all. Missing alt text is the single most common finding in accessibility complaints and demand letters. This maps to WCAG 2.1 rule 1.1.1 (Non-text Content).
Some links or buttons have no name a screen reader can announce.
- 42 links and buttons checked: 3 with no name at all, 2 with generic text.
- Unnamed: <a href="https://facebook.com/examplebakery"> with no text and no label; <a href="https://instagram.com/examplebakery"> with no text and no label; <button> with no text and no label.
- Generic link text: "read more", "click here".
A screen reader can list every link on a page so the visitor can pick one. That list is useless if links are unnamed icons or all say "click here": the visitor hears a series of blanks and has no idea where anything leads. This maps to WCAG 2.1 rules 2.4.4 (Link Purpose) and 4.1.2 (Name, Role, Value).
Some fields rely on placeholder text instead of a real label.
- 3 form fields: 1 properly labeled, 2 with only placeholder text, 0 with no label at all.
- Placeholder-only fields include: placeholder "Your email", placeholder "Your message".
When a screen reader lands on a form field, it announces the field's label so the visitor knows what to type. A field with no label is announced as just "edit text", which is a dead end. Placeholder text inside the field is not a substitute: it disappears the moment someone starts typing. This maps to WCAG 2.1 rules 1.3.1, 3.3.2 (Labels or Instructions), and 4.1.2.
No ARIA problems were found.
- 18 elements use ARIA attributes and none showed the problems this check looks for.
ARIA attributes are extra hints in the page code written specifically for screen readers. Used well, they make custom menus and widgets understandable. Used wrong, they actively mislead: a misspelled role is ignored, a label that points to a missing element announces nothing, and hiding a focusable button from screen readers leaves keyboard users focused on something that does not exist for them. This maps to WCAG 2.1 rules 4.1.2 and 1.3.1.
Some embedded frames have no name.
- 2 embedded frames: 1 with a title, 1 without.
- Untitled frames load from: https://www.google.com/maps/embed?pb=...
Maps, videos, booking widgets, and payment forms are often embedded from other services in a frame. A screen reader announces each frame by its title. Without one, the visitor hears only "frame" and has to guess whether it is worth entering, which matters most when the frame is how customers book or pay. This maps to WCAG 2.1 rule 4.1.2.
No data tables were found on the page.
- 0 data tables found. Nothing to check.
When a table has proper header cells, a screen reader can announce which column and row each number belongs to as the visitor moves around, like a spreadsheet. Without headers, the visitor hears bare numbers with no context, so prices, hours, and comparisons become meaningless. This maps to WCAG 2.1 rule 1.3.1.
Nothing plays or moves without the visitor asking.
- 1 audio or video element found, none set to autoplay.
Sound that starts on its own talks over a screen reader, making the page impossible to hear. Motion that cannot be paused is a barrier for people with attention or vestibular conditions, and for some it makes the page physically uncomfortable to look at. This maps to WCAG 2.1 rules 1.4.2 (Audio Control) and 2.2.2 (Pause, Stop, Hide).
Optional extras
not scored
These are optional extras and honest notes about what an automated scan cannot see. They never change your score. Think of them as pointers for a fuller review, not homework.
No link to an accessibility statement was found.
- No homepage link mentions accessibility. This is optional and does not affect the score.
An accessibility statement is a page where you say what you have done to make your site usable for people with disabilities and how to reach you if something is not working. It is not legally required for most businesses, but it shows good faith, gives visitors a way to report problems to you instead of to a lawyer, and is often the first thing reviewed when a complaint is filed.
No reduce motion rule was found in the page HTML.
- No prefers-reduced-motion rule appears in the page's inline styles. It may live in a stylesheet file this scan does not download, so this is an observation, not a verdict.
Phones and computers have a system setting where people who get dizzy or distracted by animation can ask sites to calm down. Some sites honor it and most never notice it exists. Supporting it is a courtesy, not a scored requirement here, because this scan cannot see every place your styling lives.
Contrast is not scored here because it needs a browser to measure reliably.
- This scan reads the page's HTML only, so it cannot compute the final colors your visitors see.
- This row is a reminder, not a finding. It appears on every report.
Text needs to stand out clearly from its background, or people with low vision simply cannot read it. WCAG 2.1 rule 1.4.3 sets exact contrast ratios, and low contrast is one of the most common findings in accessibility lawsuits. Measuring it reliably requires rendering the page in a real browser with all of its styling, which this scan deliberately does not do. An accessibility review can measure it properly.
Every check ends one of three ways: good earns full points, needs attention earns half, and needs fixing earns none. The checks add up to 100 points, and your percentage is simply that total. Letter grades follow the school pattern: A is 90 or above, B is 80 to 89, C is 70 to 79, D is 60 to 69, and F is anything below.
Each check maps to a rule in WCAG 2.1 level AA, the accessibility standard referenced by the Department of Justice and most courts. The exact rule is named inside each check's explanation.
The checks and their weights
| Check | Points |
|---|---|
| Structure and navigation (50) | |
| Page language is declared (lang attribute) | 6 |
| Page has a descriptive title | 6 |
| Headings are organized in order | 8 |
| Page regions are marked for screen readers (landmarks) | 7 |
| A "skip to content" link exists | 6 |
| Visitors can zoom the page on phones | 8 |
| Keyboard order is not overridden (positive tabindex) | 4 |
| Secure connection (HTTPS) | 5 |
| Content and forms (50) | |
| Text descriptions for images (alt text) | 10 |
| Links and buttons say where they go | 9 |
| Form fields have labels | 9 |
| Screen reader hints are used correctly (ARIA) | 7 |
| Embedded content is named (iframe titles) | 5 |
| Data tables have header rows | 4 |
| Media does not play by itself | 6 |
Optional extras never count against you
The accessibility statement, reduce motion support, and the color contrast note carry zero points on purpose. They are context for a fuller review, and not having them cannot lower your score.
What this tool looks at on your site
- Your homepage, over the secure connection
- One request to the insecure address, to see if it forwards visitors
That is the whole list: two requests. Requests identify themselves honestly as AccessLensBot/1.0 (+site-review; contact hello@brenro.com), give up after a few seconds, and stop reading after 2.5 MB. Nothing is stored: your report exists only in your browser.
Limits worth knowing
The tool reads the page code your server sends. It cannot measure color contrast, watch keyboard focus move, or listen to a screen reader, and it checks your homepage rather than every page. Automated checks like these catch only a portion of WCAG issues. A clean score here is a strong start, not a finish line, and it is not a legal compliance certification.
Further reading
ADA.gov: the web accessibility rule explained is the government's own plain-language guide, and the WCAG 2.1 quick reference lists every rule this tool's checks map to.
Why this matters now
Website accessibility has moved from a nice idea to a legal expectation. A few facts, stated plainly:
- The U.S. Department of Justice finalized a rule requiring state and local government websites to meet the WCAG 2.1 AA accessibility standard, with deadlines in April 2027 and April 2028 depending on the size of the government.
- For private businesses, courts have repeatedly treated websites as places of public accommodation under Title III of the ADA, and thousands of website accessibility lawsuits are filed every year.
- In California, the Unruh Civil Rights Act sets a statutory minimum of $4,000 per violation plus attorney's fees, which is why California produces more of these lawsuits than any other state.
- A pending California bill, AB 1757, would make WCAG conformance the explicit standard for websites serving California consumers.
None of this requires perfection today. It requires showing you have started. The most commonly cited barriers, like missing image descriptions and unlabeled buttons, are exactly what this scan looks for.
Fix it once, stay covered
The check above is free and always will be. When you are ready to act, there are exactly two offers: a one-time audit and fix, and ongoing monitoring to keep you covered after it. Both are for websites with up to 30,000 visits per month.
- most popular
ADA Audit + Fix
$750 one-time
For websites with up to 30,000 visits/month
We find every barrier, fix the ones that matter, and prove it.
- Full manual + automated WCAG 2.1 AA accessibility audit
- Prioritized issue report (critical, moderate, advisory)
- Hands-on remediation of critical issues: real code fixes, not an overlay widget
- Post-fix verification scan
- Accessibility statement for your website
Compliance Monitoring
$150/mo
For websites with up to 30,000 visits/month
Stay compliant after your fix.
- Ongoing automated compliance scans
- Monthly compliance report
- Fixes for new issues as content changes
- Alerts when new WCAG issues appear
- Keeps you covered as standards evolve (WCAG updates, DOJ rules)
Over 30,000 visits/month? Contact us for custom pricing.
Real code fixes by humans, not an accessibility overlay widget. Overlays do not fix your code and are increasingly targeted in lawsuits.