When I started looking at accessibility and using the aXe accessibility testing tool, one of the first things that it reported was insufficient colour contrast. So, I started looking into it. The page I tested had quite a few different shades of grey (not 50, before anyone else says it) so this seemed like a good place to start.
How light can grey text be against a white background, or flipped around, how dark does a grey background need to be for white text to be clear?
And the same with black. How dark can grey text go on a black background and how light does a grey background need to be for black text to be easily legible?
The results are shown in the embedded pens below. Please share if you find this useful. :)
See the Pen Accessibility – Colour Contrast with White by Chris Smith (@chris22smith) on CodePen.dark
See the Pen Accessibility – Colour Contrast with Black by Chris Smith (@chris22smith) on CodePen.dark
The next task is to find the acceptable contrast blacks and whites for pale greys, like #EEE or #F7F7F7, and dark greys, like #222.
I’ve done this quick run-through of things I’ve learned in the last 12 months for a few years now. It’s great to reassure myself that I’m still learning and every time it surprises me how much new stuff I’ve picked up in a short space of time.
For a while I’ve known that you have to use tables and inline styles rather than CSS. Actually there’s a lot more to it and you can use CSS and even media queries. You just have to be prepared for when they’re not supported with nice fallbacks. There’s an excellent course on CodeSchool called Unmasking HTML Emails.
I put this one in last year too but I think it’s fair as I’ve learned more this year. It’s surprising how under-used this is considering how easy it is now to make web graphics. I recommend Chris Coyier’s Practical SVG book.
We all know we should do more but ironically it’s a bit “out of sight, out of mind”. I’ve started to actually do something about it. As I build new screens or components I just run them through some basic checks. There’s a great Chrome extension called aXe, which you run in the dev tools. It lists accessibility violations for your page and even quotes the WCAG docs to show you exactly where you’re causing an issue. It then provides tips on how to resolve the issue, often just adding an aria attribute, title or alt text. I’ve also started checking colours to ensure they have adequate contrast for users with visual impairments but it also just makes it that little bit easier for all users. Contrast Checker is a great tool for this and let’s you build up your own palettes and export to PDF.
This is an odd one. I’ve stumbled across it and think it’s a really neat idea but I’m not convinced anyone else is using it. Please let me know if you are. It’s basically using a fixed pattern of markup (HTML and classes) to represent a common use case for greater consistency. The example I’ve used is marking up an address with lines for street address, town, county, postcode/ZIP, etc. the theory is that if we use a recognisable format then machines, like browsers, can pick them up and use them intelligently. So, if you add your addresses in this prescriptive format then a phone might offer the user the option of adding it to their contact list. Not sure it it’ll be adopted but it takes a lot of the thinking and naming away. The official docs are at microformats2. From the blog it does sound pretty active.
I’m not sure if this is the right name for them but basically being able to type shorthand code and hit the TAB key writes out proper HTML. For example, in Visual Studio or Codepen, the 2 main tools I use, you can type table>tbody>tr*5>td*3 and hit TAB and you get all the HTML for a table with 5 rows and 3 columns. If you type img and hit TAB you get a self closed image tag with the src and alt attributes inserted. It saves loads of time. Probably the best discovery of the year. Is this the right name for them? Let me know if not.
More in the next part…