What’s happening:
After introducing a team to accessibility, someone (often a product owner) asks you to “define accessible.”
Why this question matters
It’s a very fair question because product owners write acceptance criteria by which they determine if a story is complete.
Why this question is dangerous
This question can also become unhelpful and devolve into, “Just give us the checklist.” as though accessibility is another legal compliance requirement.
How to help
Teams must grow beyond checklists and into an accessible mindset.
Establish a single source of acceptance criteria
Teams cannot have different ways to define accessibility. While checklist thinking is not the best outcome, teams do still need a single source of technical requirements for testing.
Whether your testing procedures use WCAG itself, checklists or acceptance criteria, your role is to help them apply it to their processes.
Emphasize alertness over mastery
This question may come from a fear of mastering new skills for a team already be overextended. Learning when to ask for help is the most important skill the team needs to master.
Emphasizing coaches are available to help the team achieve targets will go a long way to building a good working relationship.
Determine team accessibility targets
A team may be asking for definitions because they want to know how visible the situation is to leadership. Providing assessments and targets for compliance helps express leadership’s involvement.
Frameworks for discussion
Rather than handing teams checklists open for interpretation and prioritization, spend time building a relationship that fosters discussion and broader thinking.
Do be prepared to describe accessibility in measurable (and thus manageable) terms, but do so recognizing the team may be asking from a place of malicious compliance.
Accessibility is UX
It’s easy for teams of designers and developers to see accessibility as a cumbersome requirement outside their typical performance goals. A variety of attitudes and practices exist making it easy to ignore, doubt or avoid accessibility.
- They may see UX as only UI design, and rarely use the words “user experience” when considering their priorities and choices.
- Many designers see their only deliverable as a mockup for developers to sort out the technical bits.
- Many developer teams believe when they deliver an application that looks like the mockup they are finished.
You may need to walk them through their commitments by role which includes:
- Living your organization’s values
- Accessibility as a tool for innovation
- Competitive advantage
- Avoiding legal risk
WCAG
The Web Content Accessibility Guidelines are the backbone of any accessibility definition.
Pros
WCAG is the law in the United States, providing a universal pass/fail specification.
WCAG also offers the POUR principles: Perceivable, Operable, Understandable and Robust. This is helpful as a tool for analyzing any feature or component.
Cons
While WCAG is a powerful technical spec, it does not define how components like a checkbox or accordion expander should actually work. It’s unreasonable to expect a product team will quickly master its dozens of success criterion.
Checklists
Checklists can take many forms. From simple lists to sprawling spreadsheets, they provide a comforting resolution to accessibility definitions.
Pros
Provides a single source of truth and a straightforward gating procedure without requiring mastery of accessibility best practices.
Cons
While it’s possible to define accessibility in an all encompassing checklist, the checklist will necessarily be superfluous to every situation and cumbersome to apply to every release.
Checklists can lead to abuse of standards if approached as purely a technical requirement. For example, the checklist could require alternative text for images, but a content author could write nonsense filler for the alt attribute.
Acceptance criteria
Use AtomicA11y.com to define acceptance criteria for features and stories.
Pros
Adding acceptance criteria to stories prior to development will help teams deploy accessible features from the beginning.
Cons
Story level acceptance criteria don’t cover page level testing procedures requiring thoughtful contextual thinkin which must be established in a more general document.
For example, a perfectly accessible checkbox can appear in a web page with an empty or nonsensical page <title> attribute, meaning the checkbox loses context.
Pitfalls to avoid
Be aware some people will ask this question because they are seeking ways to do the bare minimum or avoid requirements altogether.
Avoid giving a bare minimum
Sometimes, by asking for a singular definition of what is/isn’t accessible, teams are hoping to find a way to dodge responsibility.
It’s tempting to give a bare minimum definition, but teams seek bare minimums for a reason. Essentially, they hope if accessibility is a minimal or soft definition, they can argue or obfuscate compliance and continue on with business as usual.
Don’t explain it as a coding standard
Developers may (actively try to) see this as a non-functional syntax formatting standard, rather than a functional requirement with user experience impact.
In response they’ll ask about the attributes they need to add, thinking this is just about adding ARIA and tabindex to their code.
Moving the goalposts
If you’re helping a team with remediation, be sure they have access to full testing criteria for everything they’re fixing. This is especially necessary for remediation.
Common example
- An assessment might find a custom checkbox is not focusable with the keyboard.
- Because it wasn’t focusable, there’s no mention of ensuing screen reader issues.
- The team adds tabindex to the component making it focusable.
- However, it lacks an accessible name, role and state for the screen reader and doesn’t activate with the spacebar.
- Now the team is upset because it wasn’t spelled out for them in the assessment.
- They may complain they’ve “fixed the issue” and you’ve “moved the goalposts”.
This can be avoided with a set of comprehensive testing acceptance criteria referenced in the assessment.
If this doesn’t work
As always, don’t be the police.
If a team continues to push back on requirements, follow your team’s escalation procedures and leverage leadership to define priorities.