Accessibility audit
Demo Store (sample) · http://localhost:8077 · scanned 2026-06-10 · 2 pages
This is a starting baseline, not a grade — most e-commerce sites we scan begin in the 35–65 range. The number is here to track your climb; your free retest after fixes will show it move.
Why this matters
Since 28 June 2025 the European Accessibility Act requires e-commerce and consumer-facing service websites in the EU to be accessible, broadly per WCAG 2.1 AA / EN 301 549. Enforcement is beginning to move: national authorities in several member states (e.g. Sweden, the Netherlands) have opened inspections, and EU courts are now ruling on e-commerce accessibility — in June 2026 a French court ordered a major retailer to make its site and app accessible within six months. The issues in this report are the kind automated checks and complaint-driven audits surface first — and fixing them measurably improves checkout completion for all customers.
Pages audited
| Page | Status | Issue categories |
|---|---|---|
| http://localhost:8077/index.html | audited | 8 |
| http://localhost:8077/products.html | audited | 6 |
| http://localhost:8077/contact.html | HTTP 404 | — |
| http://localhost:8077/cart.html | HTTP 404 | — |
Prioritized findings
Ordered by user impact and breadth; work top-to-bottom. critical (blocks core tasks for affected users), serious (major barrier, likely audit flag), moderate (degrades the experience), minor (polish).
1. Images must have alternative text
Images are missing text alternatives. Screen-reader users hear "image" or the file name instead of what the image shows — for product photos this means the product is effectively invisible to them.
Who this affects: Blind and low-vision users with screen readers; users on failed/slow connections.
How to fix: Add an alt attribute to every <img>: describe the content ("Blue ceramic vase, 20cm") for informative images, alt="" for purely decorative ones. For product images, include the product name.
Evidence (3 examples)
<img src="logo.png" width="90" height="28">
<img src="cart-icon.png" width="22" height="22">
<img src="vase.jpg" width="180" height="120">
Pages: http://localhost:8077/index.html
2. Select element must have an accessible name
Dropdown selects have no label, so users are not told what they are choosing (country, size, quantity…).
Who this affects: Screen-reader users; voice-control users.
How to fix: Associate a <label> with each <select>, or add aria-label.
Evidence (1 example)
<select><option>All</option><option>Ceramics</option></select>
Pages: http://localhost:8077/products.html
3. Elements must meet minimum color contrast ratio thresholds
Text does not have enough contrast against its background to be readable for many users — prices, buttons and body copy can be illegible in sunlight or for anyone with reduced vision.
Who this affects: Low-vision users, older users, anyone on a screen in bright light (~1 in 12 men also have some color-vision deficiency).
How to fix: Adjust text or background colors to reach a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Usually a small darkening of grays fixes most instances site-wide via CSS variables.
Evidence (3 examples)
<a href="/products.html">Shop</a>
<a href="/contact.html">Contact</a>
<p>Handmade ceramics and textiles from northern makers.</p>
Pages: http://localhost:8077/index.html · http://localhost:8077/products.html
4. Links must have discernible text
Links have no accessible name — typically icon-only links (cart, search, social). Screen readers announce them as just "link", so users cannot tell where they lead.
Who this affects: Screen-reader users; voice-control users who navigate by speaking link names.
How to fix: Add an aria-label ("View cart") or visually-hidden text inside the link. If the link wraps only an image, the image’s alt text becomes the link name — set it.
Evidence (2 examples)
<a href="/index.html"><img src="logo.png" width="90" height="28"></a>
<a href="/cart.html"><img src="cart-icon.png" width="22" height="22"></a>
Pages: http://localhost:8077/index.html
5. <html> element must have a lang attribute
The page does not declare its language, so screen readers may read the content with the wrong pronunciation engine (e.g., Dutch text read with English phonetics — nearly unintelligible).
Who this affects: Screen-reader users; translation tools.
How to fix: Add lang to the <html> element, e.g. <html lang="nl">. One-line fix in the site template.
Evidence (1 example)
<html>
Pages: http://localhost:8077/index.html
6. Elements should not have tabindex greater than zero
Elements use positive tabindex values, which hijack keyboard navigation order — keyboard users get bounced around the page in a confusing sequence.
Who this affects: Keyboard-only users (motor impairments, power users); screen-reader users.
How to fix: Remove positive tabindex values; use tabindex="0" only to make custom widgets focusable and fix order via DOM structure.
Evidence (1 example)
<div tabindex="3">Featured: new spring collection</div>
Pages: http://localhost:8077/products.html
7. Zooming and scaling must not be disabled
The page blocks pinch-to-zoom on mobile (user-scalable=no or maximum-scale=1). Users who need to enlarge text cannot.
Who this affects: Low-vision users on mobile — and it is one of the most common reasons EU auditors flag e-commerce sites.
How to fix: Remove user-scalable=no and any maximum-scale below 5 from the viewport meta tag. One-line fix.
Evidence (1 example)
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
Pages: http://localhost:8077/index.html
8. All page content should be contained by landmarks
Content sits outside landmark regions (header/nav/main/footer), weakening quick navigation for assistive tech.
Who this affects: Screen-reader users.
How to fix: Structure the page with header, nav, main, footer elements (or ARIA landmark roles).
Evidence (3 examples)
<h3>Quiet design for loud lives</h3>
<p>Handmade ceramics and textiles from northern makers.</p>
<div class="grid">
Pages: http://localhost:8077/index.html · http://localhost:8077/products.html
9. Document should have one main landmark
Pages have no <main> landmark, so assistive tech cannot jump straight to the content and must wade through navigation every time.
Who this affects: Screen-reader and keyboard users.
How to fix: Wrap primary content in <main>; one per page.
Evidence (1 example)
<html>
Pages: http://localhost:8077/index.html · http://localhost:8077/products.html
10. Page should contain a level-one heading
Pages lack a top-level <h1>, removing the main anchor of the page outline.
Who this affects: Screen-reader users.
How to fix: Give each page exactly one <h1> describing its main content.
Evidence (1 example)
<html>
Pages: http://localhost:8077/index.html
11. Heading levels should only increase by one
Heading levels skip (e.g., h1 → h4). Screen-reader users navigate by heading structure; skips make the page outline confusing.
Who this affects: Screen-reader users (heading navigation is their primary scanning method).
How to fix: Use heading levels hierarchically; style size with CSS, not by picking a smaller heading tag.
Evidence (1 example)
<h4>Filter</h4>
Pages: http://localhost:8077/products.html
Appendix: draft accessibility statement
The EAA (and most national transpositions) require service providers to publish
an accessibility statement. Below is a draft based on this audit, for your legal review —
fill the bracketed fields and publish at /accessibility.
Accessibility statement for Demo Store (sample)
[Company legal name] is committed to making its website accessible in accordance with the European Accessibility Act as transposed in [country/law reference].
Compliance status: This website is partially compliant with WCAG 2.1 level AA / EN 301 549. An automated audit on 2026-06-10 identified 6 high-priority issue categories which we are remediating. [Update as fixes land.]
Known limitations: [Summarize the findings from this report that remain open.]
Preparation: This statement was prepared on [date] based on an automated expert-reviewed audit of 2 representative pages, and will be reviewed [annually / on significant site changes].
Feedback and contact: If you encounter accessibility barriers on this site, contact us at [email/phone/address]. We aim to respond within [X] working days.
Enforcement: If unsatisfied with our response, you may contact [national market-surveillance / enforcement body for your country].
Methodology & honest limits
This audit ran automated WCAG 2.1 A/AA and EN 301 549 checks (axe-core engine — the same engine inside Chrome Lighthouse) across 2 representative pages, with expert review of findings, prioritization and remediation guidance. Automated testing detects roughly 30–57% of possible accessibility issues; full conformance also requires manual checks (keyboard walkthroughs, screen-reader testing, media review). This report is a prioritized starting point and progress record — it is not a certification of compliance and not legal advice. Questions? hello@trybarrierscan.com