Hacker News Reader

Comment by agentgt | Hacker News Reader

I am surprised the tool doesn't do any color blind checking (ie putting red and green next to each other is generally not a good idea).

View on HN

I wonder how hard it would be to cover all types of color blindness - red and green is only one possible issue with deuteranopia - there are other potential color combinations within that, and two other types of color blindness as well.

Hmm you could integrate some information about the prevalence of different types of color blindness.

"This color combination causes mild problems for 15% of people and severe problems for 5%. Consider X and Y to reduce impact to 3%"

Creator here!

I've heard of some ways to visualize this with SVG filters - so this will be coming soon.

Still thinking of creative ways to find and label the errors, rather than just showing the user how the page will look under a certain type of color-blindess.

Can I ask you something...

So it is complaining that we have a link (A tag) with an image within it. The image has an alt tag. But the addon is claiming the A tag is "empty" and that I should add "screen reader text."

Some googling around suggests that adding "screen reader text" is unreliable since many unrendered texts aren't rendered by screen readers either, and on top of that it can cause element positioning issues.

So why is the alt text unacceptable "text" for within an A tag for when the image isn't rendered? Isn't that the entire point of the alt tag, to provide text for a non-rendered image?

You are absolutely correct in assuming that having alt-text on the image inside the link is accessible.

This is a known bug (https://github.com/Khan/tota11y/issues/1) that comes from upstream (https://github.com/GoogleChrome/accessibility-developer-tool...) and will hopefully be fixed soon.

As for your notes on screen-reader text: you can "hide" it by not actually hiding it, but placing it off the side of the page. This will be picked up by screen-readers and will not cause any positioning issues.

We use the following snippet all over Khan Academy. Bootstrap 3 uses it as well.

    .sr-only {
        border: 0;
        clip: rect(0,0,0,0);
        height: 1px;
        margin: -1px;
        overflow: hidden;
        padding: 0;
        position: absolute;
        width: 1px;
    }

So I'd like to assure you that your image link is good to go (assuming the alt-text is good!). Sorry for the troubles.

Thanks for the reply. I'll add that to our CSS in case we need it elsewhere and ignore the warning about an empty A tag for now.

aria-label is well-supported enough that it's probably better to use that, rather than offscreen text, for most purposes.

Out of curiosity, are there reasons why this shouldn't be solved at the browser or even OS level? The only reason I can think of is that solutions at the app level makes it possible for people to refer to a blue line, red bar, and whatnot and it means the same for everybody. But if we need many color profiles anyway because there are many kinds of color blindness, perhaps we should just make the labels pop out or have fewer series per graph (so that we can just refer to these graphs instead of individual series in them).

Does the contrast checking catch that?

The problem is that you'd need to run the contrast test after applying the transform for various types of color blindness because they're fairly different and some seemingly high-contrast color combinations end up fairly similar:

http://www.color-blindness.com/2008/10/02/color-blindness-si...

If you want to test this on your own, http://colororacle.org/ acts as a screen overlay so you can load any sort of application, web page, etc. and hit a hot-key to see what it looks like with each of the different types of color blindness.

WCAG contrast calculations are designed to account for this: "Color deficiencies can affect luminance contrast somewhat. Therefore, in the recommendation, the contrast is calculated in such a way that color is not a key factor so that people who have a color vision deficit will also have adequate contrast between the text and the background."

http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contr...

So if you pass WCAG color contrast checks, you'll be accessible to users with color deficiency as well as low vision.

Good point – unfortunately, it doesn't look like htat's what the plugin here does:

https://github.com/Khan/tota11y/blob/952427485a49bde0f498e9d...

https://github.com/GoogleChrome/accessibility-developer-tool...

Definitely a good feature request

Reply on news.ycombinator.com