I had been using some of my 10% time to work on a set of ideas about accessibility tools we can build directly into Webflow. After this set of docs and prototypes had been collecting digital dust for a while, I used our annual hack week to sync up with an awesome engineer and we built the whole thing in less than a week.
Webflow
Webflow is an all-in-one design platform that is pretty special. If we could visualize a scale where 0 is Paint and 10 is Photoshop, Webflow is quite up there in relation to other web design tools. Unlike Squarespace, Wix, etc., Webflow let’s designers create from a blank canvas using HTML-ish primitives and native CSS styling that follows the logic behind actual CSS, to the point where inspector labels always use their names from real CSS.
Text accessibility: a good starting point
Illegible text caused by poor contrast between the foreground and background colors is an interesting pattern around the web and UI in general. Theoretically, it’s extremely easy to avoid since it all boils down to a formula that could be downgraded to even a binary “Passes/Doesn’t pass” statement. So why is it still so prevalent?
It’s interesting to observe that authoring/design environments don’t have strong ways of ensuring color contrast is sufficient if you don’t install a separate plugin. So if a well sighted designer is picking foreground and background colors they can easily see, they don’t get any notice about this not being the case for everyone else.
What if we could solve this simple yet massive accessibility problem directly in Webflow? Given how many sites are designed on Webflow’s canvas every day, the effect multiplier of such improvement would be growing every day. I knew I wanted to find a way to improve this.
How do we inform designers their color choices could be better?
Showing the concept in a GUI
From the start, I was certain I wanted to have a simple color distinction between “what works” and “what doesn’t”. Green if it works, red if it doesn’t. This was one of those things you’re just sure about from the start. But that wasn’t enough.
Progressively on top of that, we showed the distinction between AAA and AA, minding everything inside the formula: font-size, font-weight, computed color values for each element.
The last layer of fidelity I came up with (aka saw in Google Chrome’s inspector) is the visual curve. A duo of separating lines that splits the color picker into AAA, AA and Fail "areas" that smoothly animate between their states as the hue is changed.
Determining the right levels of the cascade
Given how Webflow (and the web overall) works, determining the correct color combination on the node itself isn't always good enough. In cases when users are doing absolute positioning or some other more elaborate layout, a text element might render on top of something else, especially when it has a transparent background. To ensure everything works correctly, we established a pattern of traversing the DOM and cascade to figure out how things render more closely to reality.
Signalling problematic states without “yelling”
One of my constant fears was that this feature might be too loud, signalling a good message in the wrong way. We wanted it to be educational and signal the best positive intentions, like something that is useful first, even without explaining itself. This modest approach guarantees proper usage in my mind, because making it even a bit louder might result in designers ignoring it altogether after finding it annoying.
In an earlier version of the UI, I untegrated the indicator in the icon, but after some testing with team mates I realized this wasn't ideal.
I find the combination of a small but bright red/green token in the color picker UI to be a good balance between easy to notice and unobtrusive when everything is alright.
What I learned
I've always been fascinated by the math behind digital color and how it affects accessibility. I'm just a hobbyist when it comes to deep diving into color libraries in JS, but I learned so much while working with the amazing engineer I paired with.
I truly enjoyed shipping an end-to-end feature in the span of a bit less than a week. During hackweek, the engineer I worked with and I both took project management, design and code tasks and worked together to build something wholistic. I switched from Figma, to Visual Code, to Slack, to Dropbox Paper and all the way back over the span of a few exciting and hectic days, and next week, after some polish and writing some tests, the feature was in production.