Web Accessibility and Color Doesn't Have to Be Grey

For an endless number of excuses, dealing with or even understanding the importance of color to web accessibility can easily fall low on the priority list. However, it's a very important aspect of web accessibility and, actually, not that difficult to understand and adhere to.

There are 2 main parts related to color in WCAG 2.0 Guideline 1.4 - Distinguishable - use of color and contrast.

Use of Color

Use of color is the more straightforward of the two. Most trivially, there shouldn't be text that reads something like "Click the green button below to accept changes" or "Red messages are errors, yellow messages are warnings" anywhere on your site if there's nothing other than color that distinguishes the green button from other buttons or the errors from the warnings.

Contrast

Contrast is where things might seem a little grey, but again, it's quite simple to be compliant...especially with all the available tools. The level AA color contrast ratio is 4.5:1 and 3:1 for large text. The level AAA ratios are 7:1 and 4.5:1. I use the WebAIM color contrast checker to determine contrast ratio.

Still confused about contrast ratios? Let's take a look at Twitter Bootstrap. Let me start by saying Twitter Bootstrap is an awesome framework, and I tell everyone how awesome it is. I don't believe it makes any claim about following WCAG guidelines, so in no way shape or form am I about to criticize it. Some of Twitter Bootstrap's default styles have accessibility issues. Here are some of their ratios:

class/sample	color	background	ratio	pass/fail
.muted	#999999	#ffffff	2.8:1	fail
.text-warning	#C09853	#ffffff	2.7:1	fail
.text-success	#468847	#ffffff	4.3:1	fail (only passes large AA)
.btn-success	#ffffff	#51a351	3.1:1	fail (only passes large AA)
.label-warning	#ffffff	#f89406	2.3:1	fail
.alert	#C09853	#FCF8E3	2.5:1	fail
.alert-info	#3a87ad	#d9edf7	3.3:1	fail (only passes large AA)

Use the NoCoffee vision simulator Chrome extension to see why contrast is important by maximizing the contrast loss. The samples in the table above should be, if legible at all, more difficult to read than the rest of the text on the page. Also, notice how the larger text is much easier to read, which is why the guideline have different ratios for large text.

If you wish to download Twitter Bootstrap and like the default styles, but would like to tweak them so they're accessible, you can customize the download with more accessible colors at http://twitter.github.io/bootstrap/customize.html.

Further Explanation

Check out the newly added color section in the It's Tired in Here web accessibility page.

Fine Tuning Your JavaScript with jsFiddle and jsPerf

You're bored, want to learn, interested in a new method or API, and/or just need to settle an argument...use jsFiddle along with jsPerf!

If you've been using these tools for seemingly forever...congrats (you may stop reading). Otherwise, start fiddling; and if you're fiddling around with 2 or more functions that do the same thing use jsPerf to test and compare the performance of each one.

My use case started with the need to compare a few different implementations for traversing up a DOM tree using jQuery. First I set up the HTML body in jsFiddle to resemble the DOM used on our site, then I added the 3 different snippets with alerts to verify they all end up with the same result.

Here's the fiddle

The next thing I did was set up the 3 snippets without the alerts in jsPerf to compare the performance.

Here's the jsPerf page

I'd go into more detail here, but it should be pretty self-explanatory once you go to the pages above.

Cool CSS3 Polaroids from ZURB

Although, it's a fairly old post from ZURB at http://zurb.com/playground/css3-polaroids, I thought this was a cool way to display images in the image section of my web accessibility page.  There's no JS and completely using CSS3's transforms with the additional touch of the cool Google font Permanent Marker.

I did have to tweak their implementation a bit by not using CSS generated content in the :after pseudo-element, since many screen readers have problems reading that.

Also, it doesn't look as nice in IE...even IE 10, because it has problems rendering that font.  Not sure who to blame here; I'll dive deeper into this at a later date.

Wikipedia: Beware of the Bot

In an earlier post I mentioned using Wikipedia as way to get traffic to the It's Tired in Here Web Accessibility section.  I've learned a few things since then about Wikipedia.

It worked! I got a lot of traffic from my link on the Web Accessibility Wikipedia Page page...and fast.  It's typically the first result from searching for web accessibility.  It brought in about 200 unique visitors to my site in under a month.

Unfortunately, it didn't last. One day i noticed my link was gone.  I thought maybe someone didn't like the content.  So, I created a Wikipedia user and added it again.  I received an email indicating I had violated the rules for using the external links section, that the url was flagged, and XLinkBot had deleted it.  

Understandably, Wikipedia doesn't like people promoting things, or in general adding a ton of external links.  However, after looking through the Web Accessibility page I saw that aside from the W3C and government/legal specific links, there wasn't much as far as real examples of issues, how to address the issues, and understanding why the guidelines are important.  Some of links also point to very outdated content, a portion of which that aren't even that accessible.

My take on it is that there's a big mess Wikipedia is trying to prevent from growing.  Consequently, they're making it difficult for better content to be added.  The lesson learned is if you're really trying to drive users to your site, you have to be diverse and creative.  Also, beware of the bot!

Testing Responsiveness

Since my analytics data is telling me I've got a decent amount of users using mobile devices viewing my site, a high priority of mine has been responsive design.  Unfortunately, I don't have access to the variety of devices that would represent that of my users.  So, here's how I've been testing things:

• Google Chrome has a great tool set for mimicking devices and their dimensions.  Simply open the developer tools (right click and select Inspect Element) , and click the little tool/gear button in the bottom right.  In the Overrides section you can select from a number of devices and swap dimensions.

• Matt Kersley has a pretty sweet tool @ http://mattkersley.com/responsive/. It's also available on GitHub.  Basically, you enter a URL and the tool will show you what that page will most likely look like in a variety of devices.  The Responsinator is also worth checking out.

I've made a handful of tweaks to http://itstiredinhere.com, specifically the web accessibility page, and in no time with these tools have decent results.