InDev logo
InDev Innovation Lab

AccessLens.

Find accessibility issues before they become code.

AccessLens gives design and delivery teams a standardized, visual assessment of how well a user interface aligns with Section 508 accessibility requirements — while it is still a design.

Rather than waiting for a built interface and a manual audit, AccessLens analyzes mockups, design exports, or live pages against criteria drawn from Section 508 / WCAG 2.1 AA and identifies what to address now and what to verify during build.

design_assessment 1 flag · 2 build checks
Contrast — 4.8:1Pass
Form label identifiedPass
Color dependencyFlag
Keyboard / focusBuild check
Image alt textBuild check
PStrong
OChecks
UStrong
RChecks
Illustrative representation of an AccessLens assessment.
The Differentiator

Accessibility Before Development, Not After.

Most accessibility tooling scans finished, running code — so defects are found only after developers have already built the interface, when remediation is more expensive and more visible to the customer. AccessLens moves the assessment upstream.

Traditional Accessibility Review
01
Design
Accessibility may be considered, but assessment is largely manual.
02
Development
The interface is built.
03
Accessibility testing
Automated and manual testing identifies issues in the running application.
04
Remediation
Design and development work may need to be revisited.
Issues discovered downstream
→
AccessLens
01
Design intake
Assess the mockup, prototype, design export, or existing page.
02
Criteria-based evaluation
Evaluate measurable design characteristics against a consistent criteria set.
03
Visual assessment
Identify issues by screen and show where they occur.
04
Build guidance
Carry forward checks for behavior that cannot be assessed until development.
Accessibility considered before build
The Process

How AccessLens Works.

One assessment from design artifact to actionable accessibility guidance. Select a stage to see what it produces.

Stage 01

Input

design_intake18 screens
01–06Benefits portal — PowerPoint, one mockup per slidePPTX
07–12Case review flow — Figma Make design exportFigma
13–18Existing public pages — live page addressesURL
Screens are assessed in the order provided, so a whole user flow is reviewed as a flow.
Outcomes

Design Accessibly. Build With Confidence.

Find issues earlier

Spot accessibility defects while they are still changes to a mockup rather than changes to shipped code — before remediation becomes costly and visible.

Give developers a blueprint

A screen-by-screen view of what developers carry into implementation — and what must be verified once the interface is functional.

Assessed at design P·O·U·R
2 principles need build checks

Apply a consistent standard

Assess designs against a defined, versioned criteria set drawn from Section 508 / WCAG 2.1 AA so reviews are repeatable and traceable.

AccessLens knows what it can know
Measured from the design
Verified during build
Sample Assessment

What AccessLens Can Reveal.

Illustrative representation
Grant Application Review — Design v4.2 18 screens assessed
P · Strong O · Build checks U · Strong R · Build checks
The screen under assessment — select a marker
Assessment by criterion
Assessment matrix — criterion × screen Pass Flag Build check N/A
Findings on this screen
Carried into development
+Visible focus state and logical tab order
+Screen-reader labels, announcements, reading order
+Motion and animation behavior
In Practice

Built for Accessible Delivery From the Start.

With AccessLens

InDev Innovation Lab

Accessibility shouldn't start at testing.

AccessLens brings accessibility assessment into the design process, helping teams identify issues earlier and carry clear accessibility guidance into development.

6
Criteria groups assessed
Design
Phase the assessment happens in
ilab@indev.com
Start the conversation