-
What are
you doing?Are you designing a UI? Writing a new Web feature? Native app for iOS or Android?
Looking for training on design and dev?
-
Think atomic
Which components are in the feature? Web button? iOS date picker? Android snackbar? Each has its own criteria.
-
Copy / paste
Place acceptance criteria or checklists for each atomic component into your project management system.
-
Everyone gets it
With atomic criteria, designers and developers produce accessible deliverables from the start.
Design
HTML
iOS
Android
Who is this even for?
-
Product owners
Product owners must add acceptance criteria to stories. It's the only way to ensure accessibility is built in.
-
UX & UI Designers
Designers must meet accessibility criteria in their design systems. It's the only way to ensure accessibility is built in.
-
Developers & QA
Software engineers must meet accessibility criteria in their code. It's the only way to ensure accessibility is built in.
Why do teams need acceptance criteria?
-
Self sufficiency
Stuctured plain language rules let teams support their own accessibility design and development work.
-
Definable
More accurate Design, Dev, and QA handoffs happen when acceptance criteria are verifiable across teams.
-
Testable
Concise acceptance criteria make it clear when testing is done and features are completely read to ship.
Wait, where's WCAG?
-
WCAG is great
It's the law for conformance policy, but isn't written in plain language for people who actually make stuff.
-
WCAG isn't agile
Modern software is built using story acceptance criteria. When these criteria are in the story, it gets built right.
-
WCAG isn't clear
Some WCAG rules are vague and open to interpretation and abuse. Acceptance criteria are simple for everyone.