Product playbook

Help product owners define success beyond checking boxes

How to use this playbook

Mix and match Product owner KPIs to make a plan of action.

These starter plays can help you grow your organization’s commitment to accessibility.

Assumptions made

  • Ample training opportunities have been procured
  • There is an accessibility expert available to answer questions
  • Comprehensive automated testing results are being recorded
  • Some degree of manual accessibility testing capacity is available

Entry level: Require UX annotations

Begin with a singular change fostering greater collaboration between design and development.

One of the simplest ways to begin committing to accessibility is by asking for annotations to be included in UX/UI design deliverables.

When product owners ask for these annotations, it creates a market for the design team to be able to produce artifacts with this requirement.

Start small and simple

Don’t begin with complex interactions. Start with the simplest structures and attributes:

  • Headings
  • Alternative text for images

In time, you can include more complex concepts:

  • Clarify element names with aria-label
  • Custom component roles
  • Landmarks

Stakeholders

  • Product owners
  • Design managers
  • Designers
  • Developers

Skillset required

  • Designers will need an understanding of assistive technology basics
  • Developers will need to know how to interpret the annotations

Product demos

  • End of sprint ceremonies will now include a screen reader demo of the annotations being used
  • Designers are required to attend demos

What gets measured

  • The accessibility team will also attend and monitor demos for compliance
  • If a team is failing to stay committed, investigate the root cause

Write accessibility acceptance criteria

Add a new layer of commitment to your working processes.

Product owners and developers are now aware of what is required to successfully demo the product with a screen reader. This has sparked curiosity and has created a market for learning how components beyond headings and images interact.

Now, it’s time to add accessibility acceptance criteria to stories. This will require even non-technical product owners to climb a steep but manageable learning curve. They must be able to distinguish between components in your design/component library.

For example, they may know the difference between a checkbox and a radio button, but do they know the difference between a text input field and a multiline textarea?

Stakeholders

  • Product owners
  • Dev managers
  • Developers
  • QA testers

Skillsets required

  • Product owners and developers must recognize HTML/native components
  • Developers and QA have access to and understand how to use assistive technology

Product demos

  • End of sprint ceremonies will now include a keyboard and screen reader demo of the product as compared to the acceptance criteria

What gets measured

  • UI stories in your project management system will be monitored for acceptance criteria
  • The accessibility team will also attend and monitor demos for compliance
  • If a team is failing to stay committed, investigate the root cause

Definition of ready, definition of done

This is where accessibility first design and development becomes institutionalized.

By demanding UX annotations and accessibility acceptance criteria in team agreements, accessibility becomes business as usual for your product teams.

Changes in product ownership or turnover of team assets is now less likely to remove gains because the product teams are self regulated.

Stakeholders

  • Product managers
  • Scrum masters
  • Dev managers
  • Developers

Processes affected

When product teams agree on their working processes, the following is part of every teams agreement template:

For a story to be actionable:

  • Design artifacts must include UX annotations
  • The story must include accessibility acceptance criteria

Before a story can be delivered:

  • Accessibility acceptance criteria must be met

What gets measured

  • Scrum team agreements are reviewed to ensure compliance
  • Accessibility compliance is monitored and recorded in the production environment
  • Where issues exist, the accessibility team begins by examining the responsible team’s commitment metrics (i.e. Did they have/follow definition of ready/done?)