Building an internal design system at my company is an exciting position as it pushes me to dig into the frontend and design decisions history as much as it frees space to reorganise parts of the apps.
Both frontend engineers and product designers work to bridge the gap between today’s users needs and yesterday’s users needs, and the design system is a powerful lever for achieving this.
At my company, the design system started with a set of design tokens. Crafting a cohesive system of tokens is challenging since it must be understood by everyone as clearly and quickly as possible. And each set of tokens comes with its own challenges. For instance when choosing colours for a product, considering the contrast ratio in-between text colours and background colours is essential.
Yesterday’s user and today’s share the need for an accessible experience. Measuring accessibility is tricky, and companies are often more interested in measuring the conformity to a norm. A number of guidelines can be considered : (Globally WCAG 2.2, and in my context the French guidelines RGAA (Référentiel Général d’Amélioration de l’Accessibilité) and the Luxembourgeois guidelines RAAM (Référentiel d’Accessibilité des Applications Mobiles)). These guidelines can be cryptic and asserting the conformity of the hundreds of criteria takes forever.
As far as colour contrast is concerned, each have its own way of assessing the accessibility of text over a background. The ratio itself is (for now, and as far as I know) aligned with WCAG 2.2 AA criteria, but the definition of “large text” varies.
To overcome the complexity of assessing the conformity of a set of colour design tokens to various accessibility guidelines, I built a design tokens contrast checker grid that is available here. This type of tool already exists, but they are very often inaccessible themselves and don’t offer options for alternative validation methods. Also I don’t know if there is a colour contrast grid trend right now but Dave Rupert just created a codepen contrast grid.
The options of the first version of my website are limited, but I plan on adding more tokens import options and more contrast checking mechanisms. A question has kept me up at night (at least one night, reading through github drama). WCAG 3 is being discussed, and I’d like to be up to date with the official contrast verification guidelines. Especially because it will likely include a new method of verification, and it will diverge from the French RGAA to which my company will still need to comply to.
In the WCAG docs another algorithm is mentioned : APCA. It’s a promising method that takes into consideration the non-linearity of human perception when looking at colours. However some people raised concerns regarding the method, and other techniques might be under examination. Yet some people think that APCA it is going to be the WCAG 3 choice for sure. Although the last update in Eric Eggert’s blog post about WCAG 3 states that according to the Accessibility Guidelines Working Group Co-Chair: “APCA is not in the current draft”.
Adding that algorithm to the checker I built could be very useful, regardless of whether it’s included in WCAG 3. But it seem impossible to officially implement an APCA tester without stating what the author wants. I’m not sure I understand the need for an integration compliance document for an algorithm that would be part of an official WCAG. To be continued..