Design systems are without a doubt useful and, after initial investment, effective ways of building (larger) digital products. When they are accessible I must add.
If design system includes inaccessible components that are sometimes using so called composition (basically a component made from other components, often used in React and other JavaScript frameworks) we get quite a lot of accessibility debt built into our products. Now, often we can fix such problems in a central location and the fix is then distributed automatically through whole product, which is a giant advantage of centralized design systems.
But there are cases where design system architecture doesn’t allow centralized component usage and we need to basically copy and paste a component. Extremely ineffective and impractical by default, but sometimes we are forced to do it. Example is when design system is made in framework A and a part of product requires framework B. It is beyond the scope of this post to go into the discussion of why maybe design systems should use framework agnostic code, but it would sometimes benefit in such scenarios. Nevertheless – copy pasting is sometimes still required and when design system is not centralized we really need to make sure it was done with accessibility in mind.
Sometimes simple accessibility fixes take long(er) time
Just recently I encountered an accessibility issue in an accordion component that was very easy to fix at first glance – changing aria-hidden to way to inert. It seemed that such a simple fix would take very little time.
But then I discovered that the fix needed to be applied to four different components based on same accordion pattern with different markups and same JavaScript and CSS and at the same time I also needed to go back to the original source in the React design system (as components were copied from there). All of the components also had a CMS (content management system) differences – always expanded state in the CMS.
It immediately exploded my original estimate for the fix as I was not aware that design system was actually a separate system. I was therefore required to fix the components twice, with two different technologies. Once again – a centralized design system would not require this, but I was asked to audit the accessibility before I got the whole picture of the situation.
So – sometimes even trivial accessibility fixes take time to get fixed. Being both accessibility specialist and the front-end engineer that is going to fix this it made me think that estimates made in isolation are not very realistic. Gaps in understanding the complexity of the system can make things look too simple and we need to respect also the people that will need to fix such issues.
Common respect and understanding is needed for accessibility to succeed.
Design and development needs to plan for accessibility
This problem could be avoided if design and development would plan for accessibility. If accordion is only used to toggle static elements like text, it was fine as it was. But as soon as it was used for more content with interactive elements it was a big problem. Adding the sub-optimal scenario of different architectures for design system and the product in this case, and the CMS difference only added to the list of problems.
In a retrospective – as somebody needed the accordion to animate they used height:0px and aria-hidden to make the accordion. Which is fine until expandable content needs to have interactive elements like links. It’s a giant problem when aria-hidden includes interactive elements as they are invisible to screen-readers until people tab to them. To fix this issue without breaking the animation possibilities I reached out to HTML inert attribute and replaced aria-hidden logic with it instead.
Once again – a simple assumption that accordion will sooner or later be used to toggle interactive elements and awareness of problems with aria-hidden would make the whole thing optimal from the very beginning.
Design systems need to have accessibility incorporated. Sometimes it’s not so easy as we can have situations where we do not know all of the scenarios but planning for worst cases is smart. Like in this example of mine – an accordion can have, theoretically, a whole site inside, so make sure it supports that from the start. Now there is another question if accordion should really have a whole site inside, but we can leave that for a future post.
