Define "accessible"

Help teams grow beyond checklist thinking to an accessible mindset

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.

How things go awry

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 that may already be overextended. Learning when to ask for help is the most important skill the team needs to master.

Emphasizing that 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.

Ways to define accessibility

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 specification that can be met.

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 that doesn’t require mastery of accessibility processes.

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 MagentaA11y.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 that that require thoughtful contextual thinking. That must be established in a more general document.

For example, a perfectly accessible checkbox can appear in a web page that has an empty or nonsensical 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 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 that 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 see this as a non-functional coding standard, rather a functional requirement. In response they’ll ask about the attributes they need to add, thinking that 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 that can be 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.

Your checklist

Download checklist
How to help
Ways to define accessibility
Pitfalls to avoid
If this doesn't work
Download checklist