I have written some internal tools that do things in this vein. Open sourcing libs for this is a good idea – I've added it to my list of "stuff i would like to

I have written some internal tools that do things in this vein. Open sourcing libs for this is a good idea – I've added it to my list of "stuff i would like to do at work if i get a minute". You're correct that actually transforming and comparing these color values is technically straightforward. It has some tedious edges, though. If anyone else is interested, here's the hard/annoying stuff: 1) What do you sample, and how do you sample it? We let WCAG tell us what instances to test, easy enough. But actually pulling all the pieces out of the UI? You need to be able to tell what text corresponds to what backgrounds, etc etc. This depends on the UI environment you're testing. Most of these relationships are inferred easily-ish in HTML. Harder in a language where you're doing more basic operations like inserting rects and text objects and arranging them without markup-type nesting. And all that assume that you can actually grab these objects in a form where you can directly ask their properties. You wanna do this for static images? Ouch. 2) You have to have a few kinds of "primitives" or basic object types. Fills, strokes, icons, text – for two reasons. One, it's easier to write case-specific code that reads them from objects rather than generalized tools that pull color from any of the handful of properties that might have color in them. The other is that WCAG has different optimal contrast ratios for different kinds of things. Text has its own guidelines, and the requirements changed based on things like size and boldness, so you need to do a few kinds of tests with varying rubrics. 3) Multiple properties. Some objects have multiple fills assigned, or a fill on multiple properties, where only one of those properties is rendered based on context. Those need to be handled. Say you're supposed to measure the contrast of text on a background. But that background is transparent, so the effective background color of the text is the result of two colors mixing. Your tool needs to know this relationship, which often means traversing waaay up the DOM/element tree in the case of things like page backgrounds. And then it needs to be able to calculate color combinations and test against those. if this relationship includes more than one stacked transparent object – well, first, wtf is your UI – but you've gotta handle all that. 4) How does it get this information? The most automated way is with a scraper. Lots and lots of edge cases to write for. The simpler way is with something that looks more like unit tests. Writing manual tests at the component level. The upside here is that you're able to be more explicit about which properties are targeted, and manually declare the relevant relationships between objects. The downside is that this is hellish to write, worse to maintain – crazy brittle and does not scale at all. Visualizing this info is cool. Overtop the UI is one way, in a big consistent dataset is helpful for other things too. Think AWS status page for the accessibility of everything in your UI library. One of the more popular things in this space, to get a feel for how it might work (ugly but a start): http://wave.webaim.org/extension/ http://wave.webaim.org/extension/