Have you ever come across a component in a library or design system that seems to do… everything? For some stakeholders, these components are magical in their flexibility; for others, frustrating in their maintenance and configuration. It’s easy for a component to become bloated and its purpose increasingly ambiguous. I’ve been working with my brilliant […]
Have you ever come across a component in a library or design system that seems to do… everything? For some stakeholders, these components are magical in their flexibility; for others, frustrating in their maintenance and configuration.
It’s easy for a component to become bloated and its purpose increasingly ambiguous.
I’ve been working with my brilliant teammates on a design system and framework at the BBC for almost two years now, as a senior software engineer and accessibility lead for the department. Alongside contributing to our framework, and collaborating closely with our capability teams, a large part of my role has been focused around improving accessibility across our processes, platform and design system.
We decided early on that reusability of components was a core principle of our system. However, it was only once we hit the mammoth challenge of scalability that we came to understand we needed more guidance on what reusability means for us.
These challenges came to light most recently in a new feature making new demands on the design system. One of our collaborating teams had some new requirements:
“We want to put many types of content in a chronological, editorially curated list. One of the content blocks we want to put in it is a link with some text and an image. We already have a component that looks like it will work, we can just use that.”
A completely reasonable proposal at face value — there’s no reason for anyone involved to doubt that the component won’t (visually) fit their requirements. We will come back to this in a moment.
One of the things I’ve really pushed for in the most recent features is UX accessibility documentation during the design phase.
What does that mean? Well, it means that when we are designing a new feature, we request that our UX designers and architects chat with our developers early and draft a basic semantic HTML structure and any specific accessibility behaviours. Think landmarks, headings, buttons, links, and careful focus management, to name a small selection.
I’ve recently learned via podcast from one of my accessibility heroines, Marcy Sutton, that doing this is considered “shifting accessibility left” — that is, to embed it earlier in the software development cycle instead of making it solely a developer responsibility.
So how did it help with the situation I quoted above?
In the process of creating the accessibility design documentation for that new, shiny, chronologically ordered list of content, one of our UX folks reached out to me for a Zoom catch-up:
“I’ve tried to document the semantic structure of our feature using that well-established component… and something doesn’t seem quite right. We can’t get it to fit.”
So we spent some time trying to force a square peg into that round hole, before it struck me that of course, the peg isn’t going to fit, because it was never designed to.
We took a step back and reconsidered the purpose of the component we were trying to reuse. User-driven discovery in high-density pages of many many links, with the focus being the onward journey.
Compare that to the proposed new feature — a chronologically ordered list, with a heading for each piece of content for easy assistive technology navigation and a timestamp. That content can also contain a link should the user want to access more detail in the form of an onward journey.
To make the component accessible in that context, we’d have to add another configuration prop to the existing ~15 options, and duplicate information by using aria-hidden on some content with styling to visually hide other parts. It would make the experience palatable, but it wouldn’t be our best work, and would further bloat the original component, muddying its core purpose.
Thinking about the problem from the perspective of a good, accessible, semantic experience had highlighted early on that actually, although the original component looked like it would do the job at face value, it wouldn’t actually be as accessible as expected when applied in that new context.
They were simply two very different solutions that deserved their own space in the design system — even if they looked quite similar at first glance.
We are now leaning more heavily towards encouraging collaborating teams to think about the problem they are solving when they want to reuse components, rather than making the decision to reuse because it looks visually suitable at a glance. We’ve added a principle to the design system; “Focus on what components achieve rather than their appearance“.
Having accessibility embedded earlier in our process in that situation saved us from a potentially time-consuming, stressful and messy refactor much closer to a deadline, possibly once the development work was at the review stage. It’s likely that later down the line after several iterations, we would’ve come to a similar conclusion — it would’ve just been significantly more costly at that point.
Thinking about the experience from an accessibility perspective earlier didn’t just help us create a better experience for all, but also positively impacted our design system and component library for future iterations.
Shifting left: how introducing accessibility earlier helps the BBC’s design system was originally published in BBC Design + Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.