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.

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


The Web Content Accessibility Guidelines are the backbone of any accessibility definition.


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.


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 can take many forms. From simple lists to sprawling spreadsheets, they provide a comforting resolution to accessibility definitions.


Provides a single source of truth and a straightforward gating procedure without requiring mastery of accessibility best practices.


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 to define acceptance criteria for features and stories.


Adding acceptance criteria to stories prior to development will help teams deploy accessible features from the beginning.


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.

Coaching process

Cover these points and avoid creating a bigger problem later.

Download KPIs as a CSV
How to help
Frameworks for discussion
Pitfalls to avoid
If this doesn't work
Download KPIs