WCAG 2.0, logiciels et applications mobiles : « Pour avancer » (3/3)

13 mars 2015, par Sylvie Duchateau

Dernière partie de la traduction de l’article de blog en anglais de Ken Nakata paru le 2 décembre 2014 sous le titre : WCAG 2.0 Should Not Be Applied to Software and Mobile Apps

Suite et fin de la traduction de l’article WCAG 2.0 Should Not Be Applied to Software and Mobile Apps.

Compte tenu de la longueur de l’article, nous avions décidé de diviser la traduction en trois parties :

  1. WCAG 2.0, logiciels et applications mobiles : « Pourquoi nous avons besoin de normes claires » (publiée le 2 mars)
  2. WCAG 2.0, logiciels et applications mobiles : « C’est encore pire avec le mobile » (publiée le 12 mars)
  3. WCAG 2.0, logiciels et applications mobiles : « Pour avancer » (ci-dessous)

Traduction

Pour avancer

Personnellement, je crois que la norme EN 301-549 est la meilleure spécification d’accessibilité disponible. C’est un document pensé de façon remarquable qui tire profit du meilleur des technologies existantes en encourageant l’innovation. Alors qu’il référence l’application des WCAG 2.0 aux logiciels, il est clairement fait pour faciliter l’harmonisation avec la mise à jour de la norme du paragraphe 508 et pour éliminer la confusion en ne référençant que la norme qui peut réellement être appliquée aux logiciels.

Lorsque j’étais à la réunion du bureau de l’Association Internationale des professionnels de l’accessibilité (IAAP), j’ai soulevé cette question. Certains membres venaient de groupes de défense influents, tandis que d’autres faisaient partie des fabricants de technologies d’assistance. J’ai exposé mes opinions et j’espère pouvoir progressivement en convertir d’autres à cet avis. Espérons qu’un peu plus de discussions réfléchies permettront de changer la donne.

Clarifier de futurs jugements

Lorsque j’ai participé à la conférence Accessing Higher Ground dans le Colorado, en novembre 2014, j’ai pourchassé l’un des avocats qui avait travaillé sur les jugements à propos des applications mobiles. Apparemment, les applications mobiles dans les deux cas des jugements pour HR Block et Peapod étaient des applications « coquille » qui affichaient du contenu web. En d’autres termes, lorsque le jugement disait que les applications mobiles devaient être conformes aux WCAG 2.0 niveau AA, l’objectif était de dire que les contenus web auxquels accédaient les applications mobiles devaient être conformes aux WCAG niveau AA.

Évidemment, cette différence est énorme, en particulier à la lumière du contexte historique que j’ai décrit au début de ce billet. Afin d’éviter le genre de problèmes que j’ai décrits dans ce billet, je souhaiterais proposer que les clauses comme celle du jugement HR Block devraient être scindées en deux clauses différentes.

« L’accusé » devra faire en sorte que ses applications mobiles soient conformes au minimum aux WCAG 2.0 niveau AA.

Proposition :

  1. « L’accusé » devra faire en sorte que les personnes en situation de handicap puissent accéder et utiliser les applications mobiles de manière indépendante, en garantissant que les applications mobiles soient conformes à un ensemble reconnu de normes pour l’accessibilité des logiciels, telles que le paragraphe 11 de la norme EN 301-539
  2. « L’accusé » devra faire en sorte que les contenus web auxquels accèdent les applications mobiles soient conformes, au minimum, au niveau AA des WCAG 2.0.

Je suppose que cette modification mineure éviterait une énorme confusion à l’avenir au sein de la communauté des développeurs.

Commentaires suite à l’article

Note de la traductrice (NDT) : nous avons choisi de traduire le commentaire de Peter Korn parce qu’il apporte la correction suivante à l’article.

Le document WCAG2ICT n’est pas un document de conformité, mais une note du groupe de travail. Rien ne doit donc être conforme au WCAG2ICT.

Comme tu le sais sans doute, le groupe de travail WCAG2ICT a rencontré d’importantes difficultés pour accomplir la tâche qu’on leur a assigné. Limités par le fait qu’ils ne pouvaient pas créer de document de conformité, on leur a essentiellement demandé de trouver un moyen de déterminer comment chacun des critères de succès de niveau A et double AA des WCAG "pouvait être conforme" pour des documents et des logiciels qui n’étaient pas basés sur le web. Cela a été fait avec l’idée que d’anciens documents de conformité devaient prendre cette direction et modifier légèrement les critères de succès des WCAG comme cela a été fait par la norme EN 301-549 (ce qui n’était pas une coïncidence puisque les initiateurs de la norme étaient aussi membres du groupe de travail WCAG2ICT). Je ne peux qu’espérer que la mise à jour du paragraphe 508, lorsqu’elle sera enfin publiée, fasse la même chose que la norme européenne a fait avec nos conseils.

Enfin, pour finir, WCAG2ICT inclut des définitions nouvelles/modifiées de mot-clés car ils s’appliquent à un contexte en dehors du web. Ces définitions sont essentielles pour aider à gérer le contexte des documents/logiciels qui ne font pas partie du web. Voyons par exemple la définition modifiée de "déterminé par un programme informatique" et les nouvelles définitions de WCAG2ICT (plusieurs d’entre elles permettent de clarifier la situation impliquée dans le critère de succès 2.4.5 Accès multiples, annulant ce critère de succès (ce qui explique pourquoi le document EN a choisi de le supprimer pour les logiciels).

NDT : Ken Nakata remercie Peter pour son commentaire et la clarification et ajoute que lors de sa conversation avec des amis qui avaient une perspective différente, on a l’impression que le rapport WCAG2ICT est la preuve que les WCAG 2.0 sont transposables à des logiciels.

Nous sommes d’accord pour dire que rien n’est plus loin de la réalité. Maintenant que la norme EN 301-549 a été publiée, le comité Accessibilité est sous une forte pression pour harmoniser le paragraphe 508 avec la norme EN 301-549 et je pense qu’il est essentiel que chacun rappelle ce fait au comité dans ses commentaires.