Getting "Accessibility Ready" for a Design System

Design systems help teams make more accessible products and services. How do we ensure the components in our design system are as accessible as possible?

We'll use an example to show what "Accessibility Ready" means for components in a design system.

  • What makes a good "Accessibility Ready" guidance document?

  • What are the minimum requirements for release, plus additional internal requirements for quality, to ensure a component is "Accessibility Ready"?

  • Why keep the document short?

Who is this talk for?

This talk is most clearly directly relevant to anyone working on a design system, particularly developers. It’s also relevant to designers and developers who are interested in Quality and/or Accessibility.

What will attendees take away?

• Accessibility isn’t a binary state: there’s a minimum, a starting point, then plenty of room to improve.

• Using an Accessibility Ready document helps the design system team make and keep things accessible.

• Using an Accessibility Ready document helps users of the design system team have confidence in the Design System and make more accessible things using the design system.

Headshot of Steve Barnett - middle-aged white man, bald, brown beard with white bits, in his uniform of shirt and black hoodie.

Steve Barnett

He/him
Digital Accessibility Consultant @ Intopia

Steve is a human-centred front-end developer. He helps software teams make more user-friendly software. He’s been building things for the web professionally since 2005 (and for fun for a while before that). Accessibility has been a part of his work for many years. Now it’s part of his job title too! He makes sites and apps that everyone can use, regardless of their device, the network they’re on, or any disabilities they may have.

LinkedIn