The tool
.png)
Inputs:
- Screen type (selector): form, data table, navigation, modal, media, dashboard
- Conformance target (selector): WCAG 2.1 A, AA
Output: A checklist of relevant WCAG 2.1 success criteria for that screen type, grouped by principle (perceivable, operable, understandable, robust), with plain-language explanations. Exportable.
Behavior: Generates instantly in-browser, no login. Items are checkable and exportable.
WCAG is broad; your screen is specific
The full WCAG spec is long enough that teams either skim it or ignore it. The honest truth is that most screens do not need every criterion, a static marketing page and an interactive data table have very different risks. The trick is knowing which subset applies to the thing in front of you.
This tool generates the relevant criteria for a given screen type, in plain language, so accessibility becomes a concrete checklist instead of a wall of standards. For context on building this in rather than bolting it on, see tools that check product UI for accessibility using AI and the foundations in essential UX interface design principles and good interface design.
How it works
1. Choose the screen type. Forms, tables, and modals each have different accessibility risks.
2. Set the target. Choose WCAG 2.1 A or AA.
3. Generate the checklist. Get the criteria that apply, explained simply.
4. Check and document. Work through each item and note status.
A worked example
For a form, the checklist surfaces the criteria forms actually fail: are inputs labeled for screen readers, is the focus order logical, are errors announced and not signaled by color alone, is every field reachable by keyboard. For a data table, it shifts to header associations and keyboard navigation instead. Same standard, different screen, different list, which is what makes the check usa
A worked example
For a form, the checklist surfaces the criteria forms actually fail: are inputs labeled for screen readers, is the focus order logical, are errors announced and not signaled by color alone, is every field reachable by keyboard. For a data table, it shifts to header associations and keyboard navigation instead. Same standard, different screen, different list, which is what makes the check usable rather than theoretical.
From checklist to accessible design, with Figr
This checklist helps you verify a screen against WCAG criteria. It is a guide, not a guarantee of compliance, and real conformance needs testing with assistive technology and often an expert audit. Where Figr helps is upstream: as an AI product designer that works from your product context and design system, it can produce screens with labeled, structured, consistent components, so there is less to fix later. Pair this with the color contrast checker for the contrast criteria and the design review checklist to fold a11y into your pre-dev gate.
Who this is for
This is for teams that have to take accessibility seriously, including enterprise software teams where conformance is a procurement and legal requirement, not a nice-to-have.
What this tool is not
The tool does not certify compliance, and neither does Figr. It is a checking aid that helps you cover the right criteria for a screen. Legal conformance requires testing with real assistive technology and, usually, a qualified audit. It is also a free, standalone tool, not a Figr product feature.
FAQ
Is the accessibility checklist generator free?
Yes, free and no sign-up.
Does this guarantee my product is WCAG compliant?
No. It helps you check against WCAG 2.1 criteria for a given screen type. Full compliance requires testing with real assistive technology and, often, an expert audit.
Which WCAG version does it use?
WCAG 2.1, at A or AA, which is the common target for most teams and regulations.
Can I export the checklist?
Yes, as a checkable, shareable list.
How is this different from Figr the product?
This is a free checklist tool. Figr the product is an AI product designer that turns product context into UX decisions and Figma-ready design.