Pillar 1 of 4
Accessibility that doesn't hide behind a green checkmark
We run the same axe-core engine that powers Deque's commercial tooling — and we tell you the truth about what automated testing can and can't find.
Why automated scanning is necessary but not sufficient
Accessibility lawsuits in the US increased every year from 2018 to 2024. The vast majority cited issues that an automated scanner would have caught: missing alt text, contrast failures, form labels, broken focus order. Catching those issues early — and continuously — is non-negotiable. But here's the part most vendors won't tell you: axe-core, the engine behind every credible automated accessibility scanner including ours, catches roughly 50–60% of WCAG issues. The rest require a human. We surface that limit clearly. If a vendor claims 100% coverage or an AAA badge from automated testing alone, walk away.
How findings reach your team
Every violation comes with the rule ID, severity, the offending DOM node's outerHTML, the CSS selector, and a short failure summary that tells your engineer what to change. We link to Deque's rule documentation so the developer doesn't have to context-switch. Findings are stored as JSON. You can export them, diff them between scans, or pipe them into a future GitHub Action that fails the build on regressions.
Score interpretation
Each violation is weighted by axe-core impact: critical = 10, serious = 5, moderate = 2, minor = 1. We subtract the total from 100 for the per-page score, floored at zero. A score of 90+ usually means a small handful of minor issues. 70–89 means a real backlog. Below 70 means the page has structural problems and needs a focused remediation pass.
Exemples de constats
Les éléments de formulaire doivent avoir des labels
Le formulaire de login sur /signin contient un champ email sans <label> associé et sans aria-label. Les lecteurs d’écran annoncent le champ comme « edit text » sans contexte, et les users avec des handicaps cognitifs qui s’appuient sur le texte de placeholder perdent l’indice pendant la saisie.
<input type="email" placeholder="Email" class="form-input" /> Fix: add <label for="email">Email</label> or aria-label="Email".
Contraste des couleurs insuffisant
Le texte du corps sur /pricing utilise #9CA3AF sur #FFFFFF — un ratio de 2,84:1. WCAG 2.1 AA exige 4,5:1 pour le texte de corps. Les users malvoyants, les écrans plus anciens ou le reflet du soleil auront du mal à le lire ; certains ne verront même pas le texte.
Element : <p class="text-slate-400">Most popular plan</p> Foreground : #9CA3AF Background : #FFFFFF Ratio : 2.84:1 (need 4.5:1) Fix : darken to #6B7280 (5.85:1) or larger font weight 700+ at 18.66px+ (large-text rule).
La hiérarchie des headings saute un niveau
La page /blog/post-template passe de <h1> directement à <h3>, en sautant <h2>. Les lecteurs d’écran exposent la structure de la page via les niveaux de headings, et les écarts déconcertent les users qui naviguent par H-key. Les crawlers des moteurs de recherche utilisent aussi la hiérarchie pour évaluer la pertinence des sections.
Page outline:
H1: Article title
H3: Section heading ← skipped H2
H4: Subsection
Fix: change <h3> to <h2>, or insert a wrapping <h2> if the H3 is genuinely a sub-section.Scannez votre site en 60 secondes
25 credits gratuits. Pas de carte bancaire. Des constats réels sur la page qui vous intéresse.