Seve B.
- 12 juin 2018
- 5 min de lecture

WEB ACCESSIBILITY BASICS

Web accessibility means that people with disabilities can use the Web.

More specifically, it means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.

The UN Convention on the Rights of Persons with Disabilities recognizes access to information and communications technologies, including the Web, as a basic human right.

4 ACCESSIBILITY PRINCIPLES

Perceivable information and user interface. (providing text alternative for images, providing captions or transcripts for video and audio, and providing sufficient color contrast between text and background)
Operable user interface and navigation. (enabling navigation using only a keyboard, providing meaningful hyperlinks, and allowing enough time for users to complete a task)
Understandable information and user interface. (making content readable, providing predictable functionality, and helping users avoid and correct mistakes)
Robust content and reliable interpretation. (maximizing compatibility with current and future tools (web browsers, assistive technologies, etc.

ACCESSIBILITY IN PRACTICE

Declare the language
Alternative text for images
Colour contrast
DOM structure & semantics
Headers structre
Adjustable fontsize
Tables
Separation HTML|CSS|JS

Declare the language

See WCAG 3.1.1

Immediately following the doctype declaration should be the <html> tag with attributes declaring the language of the document.

Ex :

HTML

XHTML

Language declaration is important for accessibility because it allows braille translation software to substitute control codes for accented characters.

If you are just indicating a language change on a phrase or word use a <span> or <div> tag with the lang attribute.

Ex : <span lang="es" xml:lang="es">Espanol</span>

Alternative Text for images

SEE WCAG 1.1

All img tags require an alt attribute, without exception.

If the image is important, because it is part of an a tag, for example, it has to have meaningful text.

If the image is unimportant, purely decorative, then you should leave the alt empty: alt=””.

Describe the image briefly, but avoid the phrase “image of” or “graphic of”.

It also applies to

- SVG graphics

- the picture element

Also, avoid images of text as much as possible.

Colour Contrast

See WCAG 1.4.1

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: Hide full description

Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Low contrast ratios lead to bad readability in bright light situations and for the aging or low-vision users.

Even if you’re not auditing for WCAG compliance, adhering to this rule of thumb is still a good idea for your own eyes as well as everyone else’s.

Use semantics

Most web content that doesn’t need special widgets will most probably be over 90% accessible by just using proper semantics.

Only if you need to use widgets that are not provided by HTML, will you really have to dig deeper and dive into standards like WAI-ARIA.

Give structure & meaning to your content using HTML5 markups.

<section>, <article>, <aside>, <main>, <time>, <address> ...

Be careful; elements hidden with a display:none or visibility:hidden are none included in the accessibility tree !

Headers structure

There is a six level heading structure, from h1 to h6, to denote a main heading, secondary sub headings, and sub headings to those for sub sections.

You need to use them correctly to give your document a logical, easy to follow structure.

The h1 through h6 elements are unambiguous in telling screen readers, search engines and other technologies what the structure of your document is.

DON'T USE A DIV WITH A CLASS OF HEADING 1 OR H1, screen readers, search engines, and other technologies won't know what to do with these.

Adjustable fontsize

See WCAG 1.4.4

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Forms & labels

Most input elements, as well as the select and textarea elements, need an associated label element that states the purpose.

The one exception are those that produce a button, like the types of button, reset, and submit do. But every other, be it text, checkbox, password, radio (button), search etc. require a label element to be present.

Tables

First, it is about time to stop using tables for layout ! I still see it at work and it drives me nuts. We have wonderful tools today, such as flexbox and css grids, so why ?

The table element is a very useful element for creating data representations. Product detail listings, price lists etc. Also, shopping carts with quantities, sub totals and totals, and many other structured data collections can, and should, be put into data tables.

But you need to think about the people with disabilities, especially for complex tables.

So here's what you need to do

- Use scope="row" or scope="column" in your th

- Add a caption element to give the table a proper heading or summary

- If a table gets too complex or has multiple sections that don’t necessarily have to be in one table, split them up into several data tables.

Keyboard Accessible

See WCAG 2.1.1

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

This is the strict minimum (level A).

Separation between HTML | CSS | JS

HTML defines your content structure. It is what screen readers and other assistive technologies use to represent your content to their users.

CSS defines how that content looks visually. Its positioning, indentation, padding, margins usually have no bearing on what screen readers render to the user, with one exception: If display: none; or visibility: hidden; styles are used, that content will also not be available to assistive technologies. Put CSS in their own files, don’t embed it in the HTML.

JavaScript adds dynamic functionality. Its output must be proper HTML and CSS, too, if it manipulates the DOM.

JavaScript dynamics in itself are no problem to accessibility, only some specific behaviors can be, like losing keyboard focus.

Put JS modules in their files and don’t embed JS code in your HTML, either.

The clearer you separate the three, the more maintainable your code will be.