| name | cro-accessibility-as-conversion |
| description | CRO lens — are real users excluded from converting by contrast, target size, focus, or semantics? Surveyed by the Analyst. |
| license | Apache-2.0 |
| metadata | {"version":"1.1.0"} |
Accessibility as Conversion
Lens question: Is anyone being prevented from completing the action — low
contrast, tiny tap targets, keyboard traps, missing labels — such that fixing
access is a conversion lift, not just compliance?
Signal of the gap (DOM/RUM):
- DOM: contrast below WCAG AA on the CTA (
a.button), target < 44px, action
reachable only by mouse, unlabeled controls, broken heading hierarchy in the
block's decorated DOM, images missing alt text — the same items the EDS
code-review checklist flags.
- RUM: disproportionate drop-off on mobile / touch; conversion gap that tracks with
small-viewport or assistive-tech segments.
Variant kind it implies: CSS-only for contrast, target size, focus-visible
styling. Mixed if semantics/ARIA need repair inside the block's decorate path.
This lens is also a guardrail — a variant from another lens must never regress it
(the block manifest carries an accessibility guardrail the Validator enforces).
Related Skills
- code-review: the EDS accessibility checklist (heading hierarchy, alt text, ARIA, contrast) this lens's signals mirror.
- testing-blocks: multi-viewport browser validation that catches target-size and contrast regressions.