Rapid Accessibility Diagnostic · Sample

Homepage diagnostic: French flash-sales fashion retailer

A genuine example of what an Able diagnostic delivers, built from a real July 2026 scan. The client's identity is withheld; everything else is exactly as reported. A purchased diagnostic covers your five highest-value journeys at this same depth.

• 6violation types found
• 2critical, blocking screen-reader users from core actions
• 4serious
• 13page elements affected
• 2-4developer-days estimated to fix everything

Scope shown here

Homepage extract from the public site. No login, no customer data.

Standard

WCAG 2.2 AA, mapped to EN 301 549 (the harmonised standard referenced by the European Accessibility Act).

Method

Automated engine (axe-core) + AI triage + human review. Every finding carries evidence, severity, confidence and a human-review flag. Automated analysis catches roughly a third of real-world barriers; findings here are the certain floor, not the full picture.

Executive summary

Six violation types affecting 13 page elements, including 2 critical failures that block screen-reader users from core shopping actions. Notably, the site pays for a third-party accessibility overlay widget, yet the overlay's own link fails WCAG 2.2 touch-target requirements. Priority order below reflects user impact first, legal exposure second.

Findings

1. Images without alternative text critical

• WCAG 1.1.1 (Level A). 3 elements, including the main promotional banner image inside its linked container.
• Who is blocked: screen-reader users receive silence where the primary offer is announced; the banner's purpose is invisible to them.
• Evidence: element a[data-testid="banner-link-…"] > picture > img (fallback image, no alt attribute). Screenshot ref: fig 1.
• Fix: populate alt with the offer text (e.g. alt="Summer sale, up to 70% off"); decorative images get alt="".
• Confidence: high (deterministic rule). Human-reviewed: yes.

2. Buttons without discernible text critical

• WCAG 4.1.2 (Level A). 1 element: an icon-only button exposed to assistive tech with no name.
• Who is blocked: screen-reader and voice-control users cannot identify or invoke the control ("button" is all they hear).
• Evidence: styled-component button .sc-fHCFno. Screenshot ref: fig 2.
• Fix: add aria-label describing the action, or visually hidden text.
• Confidence: high. Human-reviewed: yes.

3. Insufficient colour contrast serious

• WCAG 1.4.3 (Level AA). 4 text elements below the 4.5:1 minimum ratio.
• Who is affected: low-vision users and anyone on a phone in sunlight; contrast failures on price and promo text depress conversion for everyone, not only disabled users.
• Fix: darken the affected text tokens in the design system (a single-token change covers all 4 instances).
• Confidence: high (computed ratios). Human-reviewed: yes.

4. Links without discernible text serious

• WCAG 2.4.4 / 4.1.2 (Level A). 1 icon-only link with no accessible name.
• Fix: aria-label on the link.
• Confidence: high. Human-reviewed: yes.

5. Prohibited ARIA attributes serious

• WCAG 4.1.2 (Level A). 3 banner links carry ARIA attributes not permitted on their role, producing unreliable announcements across screen readers.
• Fix: remove the offending attributes; the links already have valid names via their content once finding 1 is fixed.
• Confidence: high. Human-reviewed: yes.

6. Touch target below minimum size serious

• WCAG 2.5.8 (Level AA, new in 2.2). 1 element: the link to the site's own third-party accessibility-overlay service is smaller than 24 by 24 pixels.
• Note: this is why we do not sell overlays. A widget cannot make a site conform, and here the widget's own entry point is a violation.
• Fix: increase the target size or its spacing.
• Confidence: high. Human-reviewed: yes.

90-day remediation plan

• Weeks 1-2 (critical, ~1 dev-day): findings 1 and 2. Immediate screen-reader unblocking; largest legal-exposure reduction.
• Weeks 3-4 (~1 dev-day): findings 4 and 5 together (same components), then 6.
• Weeks 5-6 (design-token change + QA): finding 3.
• Week 7 onwards: re-test (included in the Full Audit), extend to the checkout journey, add automated regression checks to your CI so fixes stay fixed (our Monitoring product does exactly this).

What this sample is not

Not legal advice; not a full-site audit; not a substitute for testing with disabled users (recommended once the floor is fixed). Appeals: any finding challenged within 30 days is re-reviewed within 48 hours; incorrect findings are corrected publicly in the report's changelog.