Archive for the 'accessibility web standards' Category

Reading List 244

The 4 minute business case for accessible online shopping

Accessibility made the UK national TV news yesterday, hot on the heels of a report The business case for inclusive design by the UK disability charity Scope, which shows that around 50% of disabled people couldn’t buy something online that they wanted.

An accessible site is therefore a huge business opportunity, given that the latest Purple Pound estimate is £274 billion. (The Purple Pound a proxy for the purchasing power of the disabled community.)

Here’s a 4 minute interview on Channel 5 News to help persuade your bosses/ colleagues of the business case for accessibility.

Most of the problems that Glen talks about are easy to diagnose and solve. In fact, last week I wrote a handy Checklist to avoid the most common accessibility errors. Use it and make more money while being a better person.

Free online course!

If you want to learn more, as it’s International Day of Persons with Disabilities, W3C launched an Introduction to Web Accessibility free online course in cooperation with UNESCO. Enrol from today; the course starts 28 January 2020.

Checklist to avoid the most common accessibility errors

Last week I was moaning about the fact that 63% of developers surveyed don’t test accessibility. And I was banging on about editing a ‘learn HTML’ book which was riddled with basic accessibility errors, when Frederik replied in order to shut my whining and make me do something about it:

This isn’t a comprehensive guide to accessibility, but we’ll look at ways to avoid the most common accessibility errors identified by the WebAIM accessibility analysis of the top 1,000,000 home pages, and the HTTPArchive 2019 Web Almanac analysis of 5.8 million pages. I’m not going to get philosophical; if you’re reading this, I assume you care about why, and just want some tips on how. (But if you need to convince someone else, here’s the 4 minute business case for accessibility.)

Insufficient colour contrast

83% of homepages have low colour contrast. There are several ways to check this. I personally use Ada Rose Cannon’s handy Contrast Checker Widget, which sits in my bookmarks bar like a useful Clippy and goes through the current tab and highlights where there isn’t enough contrast. Or you can use Firefox’s Accessibility Inspector in the devtools to check and tweak the CSS until you get a pass. To check a particular combination of colours, contrastchecker will give you AA and AAA ratings. whocanuse.com will tell you which particular types of visual impairments may have difficulty with your chosen colours.

Missing alternative text for images

A whopping 68% of homepages had missing alt text (NOT alt tags). Every <img> must have alternate text. Here are basic rules:

  1. If the image is purely decorative, it must have empty alt text: alt="". But it should probably be in CSS, anyway.
  2. If an image is described in body text it should have empty alt alt="", to avoid repetition. But be careful if it’s an <img> in a <figure> (hat-tip to Mallory).
  3. If an image is the content of a link (for example, your organisation’s logo can be clicked to go to the homepage) the alternate text should describe the destination of the link. For example, alt="home page".

Heydon Pickering’s revenge.css bookmarklet does a quick and easy test to diagnose these, although I feel some of its other warnings are now outdated – I’ve filed an issue.

Empty links, empty buttons

I don’t know why anyone would do this, but apparently 58% of homepages tested had empty links, and 25% had empty buttons. I’m assuming this means they were empty of text, and contained only an image or an image of text. In the case of buttons, HTTPArchive Almanac says “often the reason this confusion occurs is due to the lack of a textual label. For example, a button displaying a left-pointing arrow icon to signify it’s the “Back” button, but containing no actual text”. (They found 75% of pages do this.) If that’s the case, the image needs alternate text that describes the function of the button or destination of the link. And don’t use icon fonts.

Use Heydon’s revenge.css bookmarklet to diagnose these.

Missing form input labels

52% of homepages had missing form labels. I prefer to wrap the label around its input like this:


<label>Email adddress: 
  <input type="email" />
</label>

I find it’s more robust than associating a form with a label using the for="id" pattern. If you can’t use an HTML label element, you can label an input for assistive technology using aria-label="useful instruction" or (less useful) a title attribute on the input. Use Heydon’s revenge.css bookmarklet to test these. WebAIM has more advanced form labelling techniques.

Missing document language

23% if homepages didn’t declare the human language of the document. This matters because (for instance) the word “six” is pronounced by a French screen reader very differently from an English screen reader. It’s simple to do: <html lang="en"> tells assistive tech that the main language of this page is English. The codes are defined in BCP47.

Missing <main> elements

The HTTPArchive study of 5.8million pages shows that only 26% of pages have a <main> element and 8.06% of pages erroneously contained more than one main landmark, leaving these users guessing which landmark contains the actual main content.

Solution: wrap your main content, that is, stuff that isn’t header, primary navigation or footer, in a <main> element. All browsers allow you to style it, and assistive technologies know what to do with it.

Happily, more than 50% of pages use <nav> <footer> and <header>. In my opinion, <nav> should go around only your primary navigation (and can be nested inside <header> if that suits you). In its survey of screen reader users, WebAIM found that 26% of screen reader users frequently or always use these landmarks when navigating a page.

Here’s a YouTube video of blind screenreader user Leonie Watson talking through how she navigates this site using the HTML semantics we’ve discussed.

YouTube video

There’s lots more to accessibility, especially if you have lots of JavaScript widgets and single-page application architecture. But my list will help you to avoid the most common accessibility errors and become a web superhero adored by millions. Moritz Gießmann has a nice single-page Accessibility Cheatsheet.

You can also make tagged accessible PDFs from your pages using Prince—it’s free for non-commercial use. If you’re one of the React Kool-Kidz™, I recommend using Tenon-UI: Tenon’s accessible React components library.

Buy me a pint when you see me next. xxx

Dive deeper?

The single source of truth is Web Content Accessibility Guidelines (WCAG) 2.1 from W3C. UK’s Government Digital Service has a good readable Understanding WCAG 2.1 guide. For advanced applications requiring ARIA, I find W3C’s Using ARIA invaluable.

You want tools? The BBC has open-sourced its BBC Accessibility Standards Checker. Google Lighthouse and Tenon.io are also very good. Please note that no automated tool can be completely reliable, as the fun article Building the most inaccessible site possible with a perfect Lighthouse score demonstrates.

If you want a self-paced course, on International Day of Persons with Disabilities, W3C launched an Introduction to Web Accessibility free online course in cooperation with UNESCO. Enrol now; the course starts 28 January 2020.

Reading List 243

It’s been a busy week for one of the projects I’m involved with, along with my old chum Håkon Wium Lie (co-creator of CSS). Prince is a software package that produces beautiful, accessible PDFs from HTML, SVG and CSS. On Tuesday we released Prince 13 with support for CSS variables (aka custom properties), lots of goodies for non-Latin scripts like Arabic & Indic, & support for fragmenting single-column/row flex containers across multiple pages. Give it a whirl if you need to produce PDFs – it’s free for non-commercial use.

Then the next day, we open-sourced our Allsorts font parser, shaping engine, & subsetter for OpenType, WOFF, and WOFF2 under the Apache 2.0 license so everyone can have better Chinese, Japanese, Korean, and Indic scripts in PDF. Allsorts was extracted from Prince and is implemented in Rust.

Reading List 242

Reading List 241

Reading List 240

Hello, you kawaii kumquat! Here’s this week’s lovely list ‘o’ links for your reading pleasure. It’s been a while because I’ve been gallivanting around Japan, Romania and the Netherlands, so this is a bumper edition.

There won’t be a reading list next week as I’m going off the grid to read books and record music in a 400 year old farmhouse in the countryside, far from WiFi and the bleeps and bloops of notifications. Until next time, hang loose and stay groovy.

Reading List 239

Hello, you cheeky strawberry! Here’s this week’s lovely list ‘o’ links for your reading pleasure.

There won’t be a reading lost for a few weeks as I’m writing this from a train to London, commencing a 3 week jaunt around conferences in Japan and Europe. Until next time, hang loose and stay groovy.

Making Mailchimp for WordPress more accessible

I use the free version of the excellent Mailchimp for WP plugin to allow visitors to this site to sign up for my Magical Brucie Mail and get my Reading List delivered to their inboxes.

When I did my regular accessibility check-up (a FastPass with the splendid Accessibility Insights for Web Chromium plugin by Microsoft) I noticed that the Mailchimp signup form fails two WCAG guidelines:

label: Form elements must have labels (1) WCAG 1.3.1, WCAG 3.3.2

This is because the out-of-the-box default form doesn’t associate its email input with a label:


<p>
	<label>Email address:</label>
	<input type="email" name="EMAIL"  required />	
</p>

I’ve raised an issue on GitHub. Update, 6 Sept: the change was turned down.

Luckily, the plugin allows you to customise the default form. So I’ve configured the plugin to associate the label and input by nesting the input inside the label. (This is more robust than using the IDref way because it’s not susceptible to Metadata partial copy-paste necrosis. (I also killed the placeholder attribute because I think it’s worthless on a single-input form.)

You can do this by choosing “Mailchimp for WP” in your WordPress dashboard’s sidebar, choosing “Form” and then over-riding the default with this:


<p>
	<label>Email address: 
	<input type="email" name="EMAIL"  required />
	</label>
</p>

<p>
	<input type="submit" value="Sign up" />
</p>

And, yay!

Reading List 238

Bit of a plug: I’m co-curating and MCing JSCamp – a one-day JavaScript conference in Bucharest, Romania on 24th of September. It’s the conference I want to attend – not full of frameworks and shinies, but full of funny, thought-provoking talks about making the Web better. The speaker line-up is cosmic, maaaan. Bucharest is a lovely city, based on Paris, accommodation and food is cheap and it’s and very easy to get to from anywhere in Europe. Come along, or tell your friends! Or both! (And no, I’m not on a percentage!)

Want my reading lists sent straight to your inbox? Sign up and Mr Mailchimp will send it your way.