So when are they going to change traffic colors lights? I have missed a few. Especially troubling in large cities at night since they blend in with all the other lights.
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.
Traffic signal green is already optimized for colorblindness: the green looks white, so it is unambiguously distinguished from red and yellow. What do you propose as better?
This is actually more of a problem. The green blends in with the street lights. Red and yellow look the same, but they do indeed look different than green. I suggest adding shape -- much like we do with signage.
I am red-green colorblind, and I’ve always just accepted that I’ll have a hard time with certain UI’s. I’ve never really thought it worth the time to design for the colorblind. Although recently I noticed Trello has a colorblind mode where you can use patterns as well as colors to denote labels...that is a simple yet effective way and has helped me a lot!
Certainly would be nice to see more of this in the design thought process.
Just anecdata, but I work on business software and a lot of effort is spent by UX and Engineering addressing color blindness / visual impairment. All color palettes are chosen with this in mind, screen readers require lots of work across disparate stacks, TTS engines, etc. Just wanted to relay that there are those who try to make a difference!
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.
Windows 10 has global colour filters that make this super easy. Windows key + Ctrl + C toggles it on and off, and you can change which filter to use in Settings → Ease of Access → Colour Filters.
In addition to greyscale, there are colourblindness filters for red-green (green weak), red-green (red weak), and blue-yellow.
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/
Some games just let you change specific meaningful UI colors arbitrarily (maybe with some presets for common forms of color blindness). I feel like that's probably the best route for the color side of things.
I would recommend looking into Tol-palettes. Some of these are optimized for color-blindness. I use them regularly and have small utility functions to generate some palettes for n-different colors. That way you have a maximized contrast and I think the palettes look aesthetically pleasing.
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.
It's my opinion at this point that CSS is one of the things turning the web from a user-centric tool to a means for companies to control people's data.
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.
As a occasional web desiger I think it is entirely possible to make websites that work for the visual impaired by using html the way it was meant to be used and still having a modern design that looks flawless.
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
2 anecdotes - one time about 4 years ago I was interviewing at a medium big publisher site with a bunch of online properties focused on interior design and so forth and when I brought up accessibility the very young CTO said they didn't have any users with accessibility problems - I wouldn't say I lost my temper but my tone did get sort of sharpish because really, the market was definitely middle aged and up. anyway I didn't get the job.
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.
I think some practical solutions could come via adding features, not taking away, in a way that brought most people into the "needs special help" category.
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.
Semantic HTML tags don't exist. The HTML tags that are being passed off as semantic don't have any standard layout to make them useful in any way.
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.
Google phones (maybe all android?) have a colorblind mode, and it's really bad. I have red-green and I actually find it harder to distinguish colors in the colorblind mode.
Extremely likely that you already know this and the answer is no, but just in case - is there any chance you're using the wrong setting?
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.
I'm using "Color Correction" (well, not anymore, obviously), and it made everything look super weird and made it harder to distinguish reds and greens.
I'm not sure I'm a fan of their app rating system. The first review on the page, for the FODMAP Diet app, shows a screenshot that using practically indistinguishable shades of red and green but shows a rating of "Works for the Color Blind". Turns out that's only because there is an "Color Blindness Assistance" buried within the settings.
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.
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.