Design system team weeknotes: Issue 5

The design system team is part of one web following our overarching vision of:

Coherent and cost-effective user experiences for Co-op.

The design system team provide the solid foundational tools, resources and standards to enable other teams to work fast — with quality baked in from the start.

Show and tell

We’re almost ready to test our user journey (level 2) accessibility testing framework

  • level 1 — that assesses the components in the design system — currently 515/548 tests pass giving us a 94% pass rate
  • level 2 — the user journey level testing we’re developing now

The goal of the level 2 framework is to make accessibility testing in key user journeys as simple as possible for product teams. We’ll also begin to assess how well we’re doing as an organisation with regards to digital accessibility.

This is something we can then report on and improve over time.

What we’ve done

We did this with the team and the Dave Cunningham (leading the accessibility work across digital) by working through our Miro board of issue areas and ranking them by:

  1. Critical issues — things that will stop someone from using our products or services.
  2. Major issues — things that will make it very difficult for somebody to use our products and services.
  3. Minor issues — things that will make it frustrating for somebody to use our products or services.
Minor and Critical accessibility issues on an online whiteboard
Minor and Critical accessibility issues on an online whiteboard

We also introduced a horizontal line. Below the line are the issues that anecdotally we rarely see in Co-op products or are likely to be handled by the component (level 1) testing — assuming they pass.

This left us with 7 critical issues every team should spend time testing. These are:

  • making all functionality available from a keyboard
  • allowing people to resize the content
  • making sure videos can be understood with no sound
  • checking that all the parts of each form have text labels
  • not using hovers to reveal extra information
  • if something changes on a page, it must be described to screen reader users
  • the use of semantics, ARIA landmarks and roles

The last one — HTML mark-up semantics is a big topic. It means using the right HTML tags and attributes to describe the content of the page to machines — the browser or screenreader. Further work is required to break this one down into things that are absolute requirements and things that are less important, as well as ways to easily test.

From this we’ll create a spreadsheet similar to the component (level 1) testing framework but grouped according to our filtered issues.

The testing framework level 2 spreadsheet
The testing framework level 2 spreadsheet

Along side this framework we’ll include information on how to test as well as a plain English guide to what standards we support and what they mean for users.

Making component development easier and better documented

This will also give us a place to host internal documentation — rather than relying on adding too much technical information to the design system website — which we expect to become more user friendly for a range of colleagues.

It’s really, really early on its lifecycle, but it’s an exciting starting point for the journey ahead… watch this space!

What’s next

Our roadmap and walls

Onward and upward.

The design system team

Service and interaction design. Product, team management and front-end engineering.