Scaling accessibility with a design system
This is a case study about my experience of learning how to design accessible web components, then scale their impact through a design system.
What problem does this solve?
Rather than everyone individually fixing the same accessibility problems, a design system enables an organisation to propagate accessible components at scale. Fixes are multiplied outwards saving time and money for product teams using the system.
I've spent the past 2 years building a design system for Lloyds Banking Group. Our design system currently supports 4 brands; Lloyds, Halifax, Bank of Scotland and MBNA. Any change we make to a component like a button, form field or notification, is pushed out to all brands.
Our design system 'source of truth' is React components, with corresponding Sketch design libraries. Components are served from our website which brings together UX, copy, and guidance for use. The system is currently used by over 30 product teams within the Lloyds Group; our main consumers are designers, developers and POs.
Accessibility is important because 1 in 5 of the UK population report a disability. There are also many temporary and situational scenarios that affect people's access online services. Lloyds conforms to the standards set by the World Content Accessibility Guidelines and undertakes accessibility reviews to make sure products are accessible to and useable by all customers.
Legal and regulatory obligations aside, it's been great to work for a company who have a genuine commitment to making inclusive products. Lloyds has an active Accessibility Guild, tools, testing and clinics that as a designer you are encouraged to take part in.
Getting to grips with WCAG
WCAG stands for Web Content Accessibility Guidelines and is the benchmark for accessibility standards across digital products. If you’ve ever attempted to grapple with WCAG it is initially an overwhelmingly complex set of guidelines.
I realised the only way to engage with WCAG properly was to set aside a whole day and read the guidelines end-to-end. I then read through again, noting all the criteria related to design. The guidelines are ordered by four principles of accessibility. When designing for the web, your content must be:
Each WCAG guideline has a number of success criteria and also a conformance level; these levels are A, AA or AAA. Conformance to a standard means that you meet or satisfy the success criteria. Lloyds Banking Group aims to meet an AA level of conformance. AAA is a lot more difficult to achieve, especially with an old legacy system and brand identity.
When I started my role I volunteered to become an Accessibility Champion - a program run by Lloyds Vulnerable Customers team. Through this I was introduced to the Digital Accessibility Centre. DAC is a not-for-profit who employs a team with a range of disabilities. They are specialists in testing digital products using assistive technology like screen readers, zoom tools and voice recognition software. My team at Lloyds got to met DAC’s testers and learn how they test our web components.
Watching DAC’s Low Vision and Screen Magnification Analyst test our web components made me rethink the way I design. I realised how difficult it was for a person with low vision to see a lightweight grey font and interact with low contrast form components. Observing regular users of assistive tech gives a different perspective on the challenges and advantages of tools like screenreaders. Testing for accessibility in an empathy lab or simulation will never afford you the same experience of chatting through journeys with people who regularly use these tools.
To get an understanding of accessibility outside my organisation I got out into the community and attended several meetups. The most established is Accessibility London which hosts monthly talks at the Sainsburys HQ near Holborn. The speakers offer real insight and if you can't make the event they are lived streamed with closed captions. I met some interesting contacts, including Zeinab Ali from learning platform How Do I who interviewed me for the How Do I blog.
Having established the criteria we needed to meet, I undertook an accessibility audit to measure our existing design components against WCAG 2.1 AA criteria. Laura Kalbag's excellent book Accessibility for Everyone helped me to prioritise. While I measured against all criteria, as a designer these we the areas I could easily impact:
Contrast minimum: WCAG 1.4.3 (AA)
Giving text and objects a strong contrast colour against the background makes it easier for people with moderately low vision to read and interact with it. To conform to WCAG guidelines, contrast ratio should be at least:
4.5:1 for text smaller than 24px, or 19px bold.
3:1 for text larger than 24px, or 19px bold.
These ratios initially scared me (maths!) but contrast ratios are easy to check with a colour contrast app. After shopping around I used the free Colour Contrast Analyser from The Paciello Group and the Stark plugin. I ran through all styling to ensure it met this standard.
Use of Colour: WCAG 1.4.1 (A)
The basis of this principle is simple: don’t rely on colour alone to communicate meaning or to distinguish visual elements. Everyone sees colours differently. Some people are colour blind or have difficulty telling different colours apart. I tested designs using Colour Oracle which shows how people with common colour vision impairments might see our components.
To conform with this standard we added an icon to our error messages, alerts and notifications.
Non-Text Contrast: WCAG 1.4.11 (AA)
This criteria says all components and graphics must have a contrast ratio of at least 3:1 against adjacent colours, unless they are purely decorative. This applies to all elements required to understand the content of a page including buttons, icons, charts and infographics, controls and states like hover or focus.
To comply with this criteria we changed the colour of our form input boxes for 3 of the brands. We also made minor tweaks to alert colours to ensure they reached at least a 3:1 ratio against white.
Meaningful sequence: WCAG 1.3.2 (A)
This criteria ensures that if the order of the content is important, the user accesses the content in this order. A person might be consuming content with the intended visual styling, with CSS styling disabled or listening to it with a screen reader. Thoughtfully structured content allows people with cognitive and learning disabilities to find and prioritise things on the page.
The problem with breaking a design down to individual components is they are viewed out of context. Should a promo box that can be used in various places across different screens lead with an H2, H3 or H4? The heading style in this component might need to be flexible.
I asked designers, developers and content designers who consume our design system for examples where components are being used. I was surprised with different applications of the same component, often used in a way I had not considered.
Text Spacing: WCAG 1.4.12 (AA)
WCAG doesn’t specify a minimum font size because it applies across digital products. What it does specify is that the person can view content with the following line height and paragraph spacing:
Line height: at least 1.5 times the font size
Paragraph spacing: to at least 2 times the font size
When viewing your content with this spacing, you must ensure content does not become cut off or overlap. This criteria helps people with dyslexia who find it easier to read with extra spacing, along with people who use custom fonts.
I did a rework of text styles in our Sketch libraries, pay careful consideration to the line and paragraph spacing applied to text styles. I then worked alongside our developer to reflect this in the code.
It’s tempting to use fixed height containers for components in your design files. These look great in design but don’t accurately describe the experience in code. New smart layout functionality in UI design tools like Sketch 58 finally allows designers to make smart components that are vertically responsive depending on the content.
When our React components were ready, I got some experts in to test the code. We used AbilityNet, a team of specialist accessibility consultants. Our design system is not open-sourced so AbilityNet sat in-house with our team for a fortnight.
We were delighted the review of our components identified 0 high priority issues which would stop people with physical disabilities, cognitive/literacy difficulties, vision loss or hearing difficulties from using our components. It did flag 22 medium and 3 low priority issues. Our developer got on case and made these fixes which were pushed out to the 4 brands.
We can now say our components conform to a WCAG 2.1 AA standard!
Feedback and support
I've learned a lot about accessibility through this journey. While no means an expert, I feel like I now have the knowledge to give sound accessibility advice or know where to look for it. Our work on Constellation has demonstrated the value of a design system to maintain a core set of accessible components across multiple brands.
What feedback has highlighted is that even though the individual components are accessible, they can be used to build a product that is not. Copy and semantic structure come into play here. It's important that individual journeys are accessibility tested before going live. Nathan Curtis wrote a timely piece on this.
Getting ongoing feedback and leveraging results from individual product testing is crucial to keep improving the design system. My team runs a support desk and a weekly drop-in clinic for designers, developers and POs. We are regularly visited by teams with accessibility problems who need some help getting their code to pass testing. It's great to receive this input as fixing something in one instance will help the users of all journeys that use our system, one of the main aims of our product.