Making the world a better place for the colorblind
wearecolorblind.com
wearecolorblind.com
Funny anecdote. At the DMV years ago to take my colorblindness test. Guy in front of me looks at test colors and says "red, green, red, blue." I promptly stepped up when it was my turn and said "red, green, red, blue." I passed.
Certainly would be nice to see more of this in the design thought process.
I'm not knowledgeable about the subject, but things like these
https://github.com/MaPePeR/jsColorblindSimulator
https://www.toptal.com/designers/colorfilter
even if they're probably never exact, maybe could be (made) good enough so they could be used for some kind of automatic testing..?
By that I mean, measure the contrast of each pixel with neighbouring pixels as they appear "normally", and then compare that with the neighbour contrast it would have for a type of color blindness: if there is a lot of contrast normally, but not with color blindness, add that up for a "problem score" and/or mark it in the image visually. Optionally, only care about images and text, but not decorations. And more things like not just taking direct neighbours into account, etc. I'm a total noob when it comes to all that, but I've seen enough to think this might be easy in the big scale of things. The trickiest part is probably good models for how things look to colorblind people (on a perfectly calibrated monitor..)
Personally, even though I am not colorblind, I would love to at least try how my own things would come out under the lens of such a tool(suite). Just like think working with grayscale is interesting in its own right, making pretty things that discernible for all types of colorblindness, and still look okay in full color, sounds like what might be a cool challenge, who knows what could make with that kind restriction (e.g. that colorblind mode for Trello looks sweet, I would enable that in a heartbeat). And even if I find there's some compromises I just don't want to make all the time, then at least it would be an informed and conscious decision.
In addition to greyscale, there are colourblindness filters for red-green (green weak), red-green (red weak), and blue-yellow.
I've been using it for database application interfaces for a long time.
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/
Also interesting: If you want to optimize text for readability on colored background, you should always choose black or white. Not an inverted color or anything. The threshold for choosing either is actually a bit dependent on the device the text is displayed on, but there are some rules that work decently for the general case.
Here are some examples:
https://www.r-bloggers.com/tol-color-schemes/
I think the 'sunset'-palette is a good choice for color blindness, but you should ask someone who is affected if that is a good choice.
If you just use raw HTML without any CSS, the documents will be pretty easy to read for anyone. Yes, it's not necessarily pretty, but if the user has some issue, such as blindness, they can pretty easily configure their browser to give them the information in a meaningful way. That is to say, the user has control over how the information is presented.
Enter 2019, and users have ceded all control of the presentation layer of the web to website owners. Now it's no longer possible to use many sites using a screen reader. And indeed it's not just the visually impaired who suffer from this: it's prohibitively difficult to extract meaningful data from websites. This gives website owners immense power: by coupling their data to its presentation, they make the data useless when separated from that presentation, thereby vendor-locking users into that presentation which they control. As users we don't have the ability to view even our own data formatted the way we want. Not only can careless CSS make screen readers useless, but it can make things invisible to the colorblind, mangled for all but the most popular few browsers, and allow reordering of content that allows the underlying data to become fragmented and therefore less parsable.
This would arguably be less of a problem if we had ceded that control to benevolent overlords, but the fact is that the people who control the presentation of data aren't even malicious, they're just absent on this issue: most website owners don't have the funding to present data in a way that's meaningful to any but the lowest common denominator. I've done a good amount of research into accessibility, but despite requesting it a number of times over the years, I've never been given budget to implement accessibility. There are some good tools out there, but only a handful of companies have the budget to use them, and even fewer actually do.
The answer, I think, is to return more to schemas for different document formats, and leave presentation to the client software which the user controls. But there's strong incentives against that, so I don't think it will happen.
I don’t think designers don’t care — most are just not aware. Also: often designers have to do things they aren’t remotely okay with, so even if they are aware it might not be their decision to take.
Contact those with inaccessible websites. They might not change it immidiately, but enough of these contacts and they surely will not forget
Second anecdote I was working as a consultant for a media company and our designer was nearly blind without his glasses and with his glasses had better than 20/20, I could never get him to take those glasses off and his designs were not especially suited to anyone with vision problems. I think after 2 years I did start making some inroads though, so it isn't always a lost cause.
For example, I'd like to be able to "read" interesting web pages when I'm out running or grocery shopping, as if listening to a podcast. Instead of "mobile first", if we went even further and built "screenless first", we could start with page design that was carefully built with sequential text sections, hierarchical landmarks, and standard voice controls that everyone could navigate in a fairly standard way. ("list main sections...stop. section 2, list items...stop. item 3, 150% speed...stop. next item...skip. next item...") Web devs could specially mark certain items with a keyword for direct access, but users could do it themselves with keyword macros for their favorite sites, so pretty soon a word or two takes you to a favorite site and does what you want, while you shop for pickles.
Of course, this would need to be a web standard, so devs only had one target and users only had to learn it once for all audio browsers and all sites built for it. Building at least certain categories of sites to support screenless access for the general public would make the marginal cost of making it accessible (in certain ways) free. Then you add your CSS to the screenless code.
Is there one <header> tag per page, or can each <section> have a <header>? If so, does the <header> go inside the <section> or before it, with some indication of which <header> corresponds to which <section>? What about <h1>/<h2>/etc. tags with regard to <section> tags? If you have a <nav>, does that go inside the <header>, or after it? What the heck is a <section> anyway?
"Semantic" means that the tags have meaning, and the meaning of these supposedly-semantic tags isn't specified enough to provide any meaning.
There are two separate color correction modes, on the most recent version of Android named "Color correction" (under Accessibility) and "Simulate color spaces" (under Developer Options). The former would ideally improve things, while the latter would almost certainly make things worse.
While it's good that the option exists, adding an optional "color blind mode" is the wrong way of thinking. Designs that include multiple distinguishing cues - color, shape, size, symbols - are easier to use for all users.
A site like this should push for a higher standard. I'd rate this app a C - passable, but not ideal. If they would just set the "color blind" mode on by default, it would be worthy of the full grade.