Djangocon: Web accessibility is not optional - Xavier Dutreilh¶

Tags: django, djangocon

(One of the summaries of a talk at the 2015 Djangocon EU conference).

Xavier Dutreilh says the web played a big part in our lives. It shaped us. For the most part we’re happy with the web and we don’t see any real problem with it.

But there are problems. An important problem is because we design websites for non-disabled people. So we exclude lots of people with disabilities. It might sound harsh, but it is the simple truth.

What is web accessibility? It is the inclusive practice to remove barriers from websites. It ensures everyone has equal access to the information.

What is a disability? It is an impairment, either present from birth or acquired later. Either due to an accident, sickness or a genetic condition, for instance. An impairment can be eigher progressive or non-progressive. There are four main categories:

• Visual. Blindness, low vision or color-blindness. Technically, when you have to wear glasses, you fall into the low vision category.

• Hearing. Deafness or hard-of-hearing.

• Motor. Limited dexterity or loss of limbs.

• Cognitive. Learning issues or memory loss, for instance.

So, how do you do web accessibility?

• The first thing is to provide appropriate alternative text for non-text context. Like descriptions of photos. But watch out with the length of the descriptions, as it can make it very slow for screen readers.

  If what happens in a photo is important, put that in the description. Like “Xavier giving a talk”.

• Provide appropriate document structure with semantic tags. Mark the header and footer of your site as navigation. Use heading tags appropriately. Use lists properly.

  For tables, provide proper headers. So a <thead> with <th> tags.

  For forms, add proper labels. Django forms do this OK by default.

  And… don’t name your link “click here”. Give it a proper name. So no more <a href="/somewhere/">click here</a>. Describe it. <a href="/somewhere/">article list</a>, for instance.

• Provide transcripts for audio and video material. Add captions.

• Ensure accessibility of PDF files and other non-HTML content. PDF or word files: just follow the same guidelines as for web. Proper use of headings, for instance.

• Allow users to skip repetitive elements on the page. For instance a link right at the top of the page to skip over the navigation elements to the main content.

• Don’t rely on color alone to convey information. So <span class="label green"></span> is bad. <span class="label green">OK</span> is better.

• Make sure content is clearly written and easy to read. You have to be explicit about what you say. The reader might not understand your culture or the kinds of words you use.

  Good advice: write explicit, clear, simple and positive sentences.

• Use clear fonts, relative units and strong contrasts. Some fonts might look nice, but they might also be hard to read. And make headings bigger than the regular text. And no dark gray text on light gray…

• No blinking or moving text. Three flashes within a second could trigger an epileptic attack…

• Make browser-side javascript code accessible. Note that many screen readers can nowadays handle quite a lot of javascript. Just avoiid device-dependent event handlers. If some piece of javascript only reacts to a mouse and nothing else, you run into problems.

• Design to standards to avoid hacks and inaccessible pages.

Where do we go from here? If you implement the guidelines above, most people will be able to use your website. For many developers, it would be good to look up some documentation on disabilities. You have to read up a bit to get a better feel for the problems. You can also read guidelines like WCAG, ATAG, UUAG and ARIA.

What also helps is talking to people with disabilities.

And try accessibility tools on your computer or your smartphone. Modern operating systems include a lot of tools. Try them out and look at your websites with those tools enabled.

Validate your web applications with WAVE. And you can also audit your pages with the Chrome disability tools.

(See the WAVE report page for this very page )