Accessibility steps

Par Élie Sloïm, le 14 mai 2012, dans .

Last year, Aurélien Levy, CEO at Temesis reported us two facts.

  1. “Front-end integrators ask me if there are any Accessibility instructions somewhere to learn how to code accessible html/css/js page”.
  2. “As an accessibility expert I often have to check webpages that do not comply with accessibility basics requirements. Half of the things I have to say after a quick check are problems that could have been detected before by automated tools”.

Regarding the first point, we can answer that WCAG2.0 could bring a solution, but some issues are well known :

  • WCAG 2.0 are non-technical principles
  • WCAG 2.0 techniques are a huge list of non-normative and complex tests, for sure there aren’t easy and clear coding instructions.
  • Front end integrators don’t care about which WCAG 2.0 guidelines they don’t fulfill, they want to know what they can use or not while coding.

As for the second point, we can define a list of 100% sure accessibility errors and alerts that need to be fixed before calling an accessibility expert (if you don’t have an alt attribute on an image element, don’t ask me what to put in it).

So to cover both of these needs, after a bit of brain twisting, Aurelien came up with the idea of providing a quick list of instructions. Following these instructions wouldn’t guarantee that your html/css/js is accessible, it would just guarantee that you have carried out the bases before starting to work on the “real accessibility issues”.

That’s what we’ve been working on for an entire year, with the help of many people at Temesis, ParisWeb and Opquast (Open quality standards) and after many workshops in real life and online, we’re re very glad to announce that the English translation of the two instructions lists “Accessibility Steps” is now available.

  • The first step has 81 instructions. It’s called “Error detection”. If you don’t comply with those instructions, it’s not a good investment to call an accessibility expert, because that’s what he will tell you to correct beforehand.
  • The second step has 49 instructions: it’s called “Risk detection”. If you don’t comply with some of the instructions, it’s doesn’t mean you have errors on your pages. It means that your content might not be accessible if you don’t do some sort of extra work.

The translation has been achieved by Stephane Deschamps, founder and former president of ParisWeb conferences, and one of the best accessibility experts in France. Praise him for his help.

You can access the accessibility steps instructions list in French and in English and you can download it and use it as you see fit, as it is creative commons BY-SA licensed. Furthermore, you can already check if you comply with these instructions through Opquast Reporting.

2 commentaire(s)

  1. Par Deltev, le 15 mai 2012 à 18 h 05 min :

    Hi,
    I think it is certainly useful to provide checklists for coders. Have only looked at the first steps doc so far.

    I think in some cases you have built unnecessary redundancy: instead of repeating “if you use hn, do not leave it empty” six times (actually seven times, since it is listed twice for h1) one could just say “If you use semantic elements such as h1-h6, p, li, etc, do not leave them empty”. The coder/developer would probably get the point, and you save about ten steps…

    Some instructions such as ” Don’t use a caption element in a table element containing only td elements” seem a bit obscure – I think you are probably referring to layout tables but there may be simple data tables (think of a two column price list for drinks, content is obvious and doesn’t really need headers) where a caption “price list” would be suitable.

    So, several of your instructions strike me as a bit arcane and sometimes over-prescriptive.

    I think it would help to boil down the list to fewer recommendations, cutting redundancy, and maybe even adding an example here or there (fold-out content so it doesn’t bloat the list?) So whenever coders / designers are not sure what kind of use case the recommendation aims at, the example will help.

    Actually, having said that – leaving aside the obvious a11y problem for blind and visually impaired users just for a moment, coders would probably appreciate the screenshot of a horribly coded page with all the issues circled in red felt pen and annotated by hand. A bit like in http://theoatmeal.com/comics/shoppi… .
    That would link advice and example quite nicely. Difficult to write a meaningful alternative text for that though…

    All the best – may comment again after looking at the second one.
    Detlev

  2. Par levy, le 16 mai 2012 à 10 h 00 min :

    Hi Detlev thanks for your comment, we choose to separate each rules because reason, solution and impact on user can be different. For example an empty li as not the same effect than an empty hx. Furthermore as you can see on the pdf document we also have an element category which allow us to get all the rules for one element

    on the data table instructions there is two reason why we do that. People that doesn’t know anything about accessibility (and they are our first audiance) doesn’t know the caption element and use table for presentation most of the time. If he know the caption and use it in a table without th we will report and alert, then he can check why and read :
    https://checklists.opquast.com/fr/a
    (not translated for now) and then choose if want to correct something or not. But maybe we can choose to put this rule on the second step (risk) list I agree.

    As you may see with the previous link we already have example and generic solution but not translated for the moment.

    Anyway thanks again for all your comments

Les commentaires sont fermés.