Discussion :

[Christian Olivier]

USA : la Cour suprême permet aux personnes aveugles de poursuivre les détaillants en justice
Si leurs sites Web ne sont pas accessibles aux personnes malvoyantes

Il y a trois ans, un Américain du nom de Guillermo Robles a entrepris de commander une pizza en ligne en utilisant les services de la société Domino’s Pizza. Il avait tenté de le faire via le site Internet du groupe, mais sans succès. Il faut préciser Robles est aveugle et utilise un narrateur – un logiciel de lecture d’écran qui utilise une voix artificielle pour lire à voix haute ce qui est affiché sur le moniteur – pour naviguer sur Internet. Déçu par son expérience, il a porté plainte contre Domino’s, alléguant que Domino’s violait l’ADA (Americans with Disabilities Act), la loi américaine qui protège les citoyens en situation de handicap contre les discriminations. Elle exige notamment des entreprises qu’elles déploient l’ensemble des solutions nécessaires à l’accommodation des personnes handicapées.

Pour les avocats de Domino’s, la disposition ne s’appliquait pas à ses points de vente physiques, mais pas à son site Web. Robles, de son côté, estimait que ce règlement s’appliquait aussi aux sites Web. Une cour d’appel fédérale lui avait donné raison, confirmant que le site Web de Domino’s se devait d’être accessible aux aveugles, comme n’importe quel restaurant ou magasin physique : « L’ADA exige que les lieux publics, comme ceux de Domino’s, fournissent des aides ainsi que des services auxiliaires pour mettre du matériel visuel à la disposition des personnes aveugles », a déclaré la cour d’appel en janvier.

Domino’s Pizza avait renvoyé l’affaire devant la Cour suprême des États-Unis dans un ultime effort pour faire annuler le jugement précédent en faveur de Robles. Mais, c’était peine perdue puisque ce lundi, la Cour suprême des États-Unis a donné définitivement raison à Guillermo Robles. Elle a, par la même occasion, autorisé les personnes malvoyantes à poursuivre les entreprises comme Domino’s Pizza si leurs sites Web ne leur étaient pas accessibles, une décision d’une portée considérable qui pourrait potentiellement révolutionner l’accessibilité au Web.

Si la législation à l’échelle mondiale semble en général très claire sur les critères qui permettent de définir un bâtiment qu'on peut considérer comme accessible aux non-voyants, de telles directives n’existent pas forcément pour Internet. Ce cas qui fait apparemment jurisprudence implique que toutes les entreprises américaines doivent désormais se dépêcher de modifier leurs sites Web afin d’éviter le « tsunami de procès » qu’elles redoutent. Elles craignaient également que les juges à l’échelle nationale ne considèrent la décision de la cour d’appel comme « imposant un mandat d’accessibilité au site Web à l’échelle nationale ». Joseph R. Manning Jr, un avocat de Newport Beach qui représentait Guillermo Robles, a assuré que la Cour suprême avait fait « le bon choix ». D’après lui, « il ne fait aucun doute que les aveugles et les malvoyants ont besoin de sites Web accessibles et d’applications mobiles pour fonctionner sur un pied d’égalité dans le monde moderne ».

Source : Décision de la Cour suprême (PDF)

Et vous ?

Que pensez-vous de cette décision de justice ?

Voir aussi

Google pourrait faire face à une enquête antitrust imminente du ministère américain de la Justice sur ses vastes activités en ligne
Le ministère de la Justice annonce un vaste examen antitrust de la Big Tech afin de déterminer si elle réduit la concurrence et étouffe l'innovation
McDonald's veut utiliser l'IA pour gérer les commandes passées dans ses magasins via son service Drive dédiés aux automobilistes et s'offre une nouvelle startup technologique

[walfrat]

Certes c'est bien pour les malvoyants.

Pour les grosses entreprises, elles ont les moyens, quid des plus modestes ?

[ji_louis]

Respecter les bonnes pratiques et la norme HTML5 n'est pas si difficile.

Par exemple, mettre une propriété

alt="ceci est la description de l'image"

à chaque image d'illustration permet aux lecteurs vocaux de décrire ce que la personne ne peut pas voir, et c'est dans la norme HTML depuis plus d'une décennie!
Si enfin cela permet de rationaliser les usages sur les IHM du web, cela sera une TRÈS bonne chose!

[matthius]

C'est Gnome qui permet aux aveugles de lire ce qu'ils veulent. C'est une loi absurde.

[Fleur en plastique]

On dit que la Justice est aveugle, et on dirait que c'est bien le cas. Pour moi ce jugement est scandaleux, on ne doit pas fermer les yeux sur l'abus de pouvoir de ces juges. S'ils croient y voir un semblant de justice, ils se fourrent le doigt dans l'oeil jusqu'à l'omoplate. Ils se croient visionnaires, mais là c'est du tout vu, les aveugles, sous prétexte d'un léger handicap, vont réclamer des millions de dollars à des petites entreprises pour un prétexte futile. Vous verrez.

[defZero]

Que pensez-vous de cette décision de justice ?

Foutage de gueule généralisé.
Ça n'as aucun sens.
Bientôt on va assister à des attaque en justice, parce que les écran ne sont pas adapter au mal voyant ? C'est vraiment nawak.
Si j’étais mal voyant comme ce messieurs et que je voulais commander cher Domino's, j'aurais fait ce que toute personne sensé aurait fait, j'aurais utilisé mon téléphone.
Le monsieur à juste chercher la merde et tout le monde sait bien que quand on la cherche, on finit toujours pas la trouvé.

@ji_louis

Respecter les bonnes pratiques et la norme HTML5 n'est pas si difficile.

Par exemple, mettre une propriété
alt="ceci est la description de l'image"
à chaque image d'illustration permet aux lecteurs vocaux de décrire ce que la personne ne peut pas voir, et c'est dans la norme HTML depuis plus d'une décennie!
Si enfin cela permet de rationaliser les usages sur les IHM du web, cela sera une TRÈS bonne chose!

Si seulement s'était aussi simple, mais avec la "WebAppization" du Web et la cible mouvante perpétuel qu'est devenu HTML5, bonne chance pour respecter les normes style ARIA.
De plus, rien ne garantie de toute façon que le "lecteur d'écran" soit capable de bien interprété ces "normes" pour rendre une lecture compréhensible à l'utilisateur.

A mon avis, le seule véritable moyen d'arriver à quelque chose de sensé et utilisable, serai d'avoir un web alternatif, avec son propre langage, adapté aux "lecteur d'écran".
Une sorte de WAP pour "lecteur d'écran".

P.S. : il y a plein d'autres choses à faire bien avant le web et qui aurait infiniment plus de retombés.
Par exemple :
- Rendre obligatoire l'enseignement du braille et de la langue des signes, au même titre que la langue officiel du pays. (ce que j'aurais adoré en passant)
- Obliger tous fabriquant, quelque soit le domaine, à prendre en compte toutes les infirmités possibles et imaginables dans leurs choix de conceptions. -> Ce qui n'est pas souhaitable/faisable pour des raisons évidentes.
...etc.

[clementmarcotte]

C'est Gnome qui permet aux aveugles de lire ce qu'ils veulent. C'est une loi absurde.

Liberté égalité fraternité ???????????????????????????????????????????????

Que c'est donc beau une égalité inégale

[clementmarcotte]

On dit que la Justice est aveugle, et on dirait que c'est bien le cas. Pour moi ce jugement est scandaleux, on ne doit pas fermer les yeux sur l'abus de pouvoir de ces juges. S'ils croient y voir un semblant de justice, ils se fourrent le doigt dans l'oeil jusqu'à l'omoplate. Ils se croient visionnaires, mais là c'est du tout vu, les aveugles, sous prétexte d'un léger handicap, vont réclamer des millions de dollars à des petites entreprises pour un prétexte futile. Vous verrez.

Être aveugle c'est un léger handicap ?

Au Canada, la non discrimination sur la base du handicap et la non discrimination en général est un droit constitutionnel de depuis 1982 et les Tribunaux y font très attention et l'interprètent généralement très largement en faveur des citoyens. C'est un droit fondamental autant que la liberté d'expression ou de religion.

Et quand je lis les réponses en général, je les trouves méchantes, insensibles et bornées. Là ce sont les Français qui sont aveugles. Liberté juste pour les non-handicapés, inégalité les handicapés, non-fraternité envers les "anormaux". Puis ça se dit un pays civilisé.

[eldran64]

Je ne pense pas que cette condamnation soit bonne. Que les choses accessibles aux personnes souffrant de handicap et que ça soit obligatoire, je trouve ça fondamentalement bien.
Par contre pour le cas de Domino's pizza, il y a la possibilité de passer un appel pour avoir le même service. A partir du moment où il existe une méthode ou un moyen qui rend les choses accessibles on ne devrait pas rendre obligatoire le reste de manière automatique et aveugle (sans mauvais jeux de mot).

Par exemple, pour déclarer ses impôts ou pour lire ses mails il est normal que ça soit accessible au plus grand nombre. Mais pour une boutique qui vend des pizza? à partir du moment où on peut les appeler où est l'injustice d'être obligé de passer un appel quand on est aveugle?

[Invité]

Je ne pense pas que cette condamnation soit bonne. Que les choses accessibles aux personnes souffrant de handicap et que ça soit obligatoire, je trouve ça fondamentalement bien.
Par contre pour le cas de Domino's pizza, il y a la possibilité de passer un appel pour avoir le même service. A partir du moment où il existe une méthode ou un moyen qui rend les choses accessibles on ne devrait pas rendre obligatoire le reste de manière automatique et aveugle (sans mauvais jeux de mot).

Par exemple, pour déclarer ses impôts ou pour lire ses mails il est normal que ça soit accessible au plus grand nombre. Mais pour une boutique qui vend des pizza? à partir du moment où on peut les appeler où est l'injustice d'être obligé de passer un appel quand on est aveugle?

À condition de pouvoir trouver le numéro de téléphone sur le site. À condition aussi qu'il ne soit pas plus contraignant pour l'utilisateur de passer le coup de fil (par exemple, si le service téléphonique est payant, si les délais sont plus longs, etc.). Aussi, au téléphone on peut être tenté de mettre en avant telle ou telle garniture en supplément, or certaines personnes (dont moi) préfèrent faire leur choix tranquillement sans être poussées.
Si on va par là, on pourrait dire que les rampes d'accès pour les fauteuils roulants ne sont pas indispensables à partir du moment où tous les produits sont disponibles sur le site Internet.
Pour ma part, je trouve que rendre obligatoire l'accessibilité des sites Web est une étape naturelle de l'effort collectif visant à favoriser l'autonomie des personnes handicapées, et je salue la décision de la Cour suprême. J'espère que la France suivra cet exemple.

[ji_louis]

Pour vérifier si son site web est "blind-friendly", on peut le tester avec le navigateur linx (ne supporte pas le javascript), eSpeak (synthèse vocale multiplateforme) ou Orca (Linux).
Et encore une fois, il suffit de faire du HTML bien formé (c'est à dire respectant complètement la norme HTML du W3C) pour que ce soit utilisable par les liseuses des non-voyants. C'est peut être mon habitude de travailler sur des sites administratifs qui me donne l'impression que la chose est simple... mais c'est vraiment simple!

[CoderInTheDark]

Il y a vraiment des coups de canne blanche qui se perdent, surtout pour décapité les vleures en plastiques.

Premier problème on pousse tout le monde à utiliser les sites internet, par exemple en France de plus en plus de démarches administratives n''existe plus que par internet, c'est pratique pour l'état qui ferme de plus en plus de guichets.
Et ces même administrations continue d'envoyer des courriers papiers et n'acceptent pas forcément des mails pour qu'on leurs répondent.
Un jour quand j'en aurai marre je vais leur répondre en braille. :;D
Et si un service n'est pas disponible, on fait comment ?
Il faut une alternative, et il faut laisser le choix à l'utilisateur.

Concernant le braille, beaucoup d'aveugles ne savent pas le lire quand j'ai fait ma rééducation on me l'a imposé, et j'ai découvert plus tard que beaucoup ne lisaient pas le vbaille et se contentait d'écouter la synthèse vocale et utilisaient les livres audio.
Personnellement je préfère lire les livres en braille car avec les livres audio on est influencé par l'acteur, qui enlève une part d'imaginaire car il nous influence avec ses intonations.

Le téléphone c'est bien beau, mais ça coûte cher, surtout que les numéros surtaxés sont mise en avant et que les numéros au tarifs normal sont cachés et même supprimées.
J'utilise un service de transport adapté, j'ai réclamé le numéro normal, car avec toutes les attentes cumulées, j'avais de grosses notes de téléphones en fin d moi.

Revenons à nos moutons, faire un site accessible c'est simple, surtout si on fait du HTML propre.
HTML5 et ARIA ont déjà répondus aux problèmes, il suffit de le respecter.

Il reste des problèmes
Un exemple de gros problème c'est que les développeur ne gère que la sourie pour leurs composants, et les non-voyant on utilise pas le clavier.
Alors tout ce bazar javascript css n'est pas souvant accessible

Le composant de cette page pour poster un messagqueeà un léger problème, je ne peux pas le quitter avec la touche tab pour aller sur le bouton.
Heureusement il y a un raccourcis clavier pour valider son message.
Alors pour vous faire une idée de l'accessibilité de vos page faite le teste de les utiliser seulement avec le clavier.

Faire un site accessible c'est aussi faire du web sémantique
C'est à dire qu'un robot pourra les parcourir pour les recherches et le référencement, c'est mieux, alors ça ne concernent pas seulement les déficients visuels, comme ça vous n'aurez pas l'impression de perdre votre temps.

Par contre les catchas à base d'images c'est toujours la m*!, surtout les catchas sémantiques, et même pour les voyants.
Car on vous demande de cliquer les images avec un taxi un feu, un lac, ... il suffit qu'il y est juste un bout de truc pour refaire le teste.
Ca gonfle tout le monde
Je sais je suis obligé de demander, que l'on les fasse pour moi même avec un catcha audio.
A ce propos il y a un plug in qui tente de résoudre le catcha pour l'utilisat'eur en utilisant le catcha audio.
Il avait pensé pour les aveugles mais il pourrait rendre service à tous.

Pour vous faire une idée vous n'avez qu'a tester un lecteur d'écran, si vous avez windows 10, vous avez le narateur installé.
appuyer sur "ctrl + windows entré" pour le lancer et le même
raccourcis pour le stopper
ctrl pour le faire taire c'est le raccourcis le plus utile
les flèches pour lire mot à mot ou ligne à ligne
touche insère du pavé numérique plus flèche du bas lancer la lecture

Bon pour les raccourcis je suis un peu limité car je connais mieux NVDA, qui est aussi gratuit, et JAWS qui est du vol
Et pour les développeurs python en mal de challenge NVDA permet d'étendre ses possibilité avec des script python, pour rendre une application accessible avec un plug in dédié par exemple

sous linux il y a Orca avec Gnome, la synthèse vocale par défaut(Hi-speak) est infame, moi j'en ai installée une .

Sii vous testez c''est mieux de le faire sans l'écran

J'avais déjà parlé de faire les tests avec lynx, mais ça ne donne qu'une idée du rendu statique de la page.
On a quand même besoin aussi du Javascript pour interagir avec la page

J'ai presque terminé un article à ce sujet.
https://github.com/FabriceLuneau/WebAccessible

dans le dossier doc il y a l'article au format word.

Actuellement Je me penche sur des exemples de page en html simple.
Pour que vous puissiez vous rendre compte en utilisant un lecteur d'écran de ce que ça donne.
Mais il y a trop de produit différents surtout voice over, qui est très différent dans son utilisation.

[defZero]

@CoderInTheDark +1

Pour le coup, tu m'as appris quelque chose concernant le braille.
Ça me conforte d'autant plus dans l'idée qu'il devrait être obligatoirement appris dès le primaire et par tous au même titre l'alphabet latin.
De plus, je te rejoint tout à fait sur le fait de rendre plus accessible ce qui peut l'être et dans tous les cas de proposer des méthodes d'accès alternatives quand c'est possible.
Et d’ailleurs c'est ce que je pointais du doigt avec pour exemple, dans le cas cité, l'usage du téléphone au lieu du site.

Par contre je vois quand même un gros paquet de remarque à faire.
Reprenons donc tes critiques/arguments (soutenue par d'autres également):

Premier problème on pousse tout le monde à utiliser les sites internet, par exemple en France de plus en plus de démarches administratives n''existe plus que par internet, c'est pratique pour l'état qui ferme de plus en plus de guichets.

Concernant l'obligation de passer par des sites web, je trouve que ça va dans le sens du progrès, surtout au vu de l'accueil/compréhension parfois douteux/se dont nous gratifiaient les agents.
En générale les sites Administratifs sont les plus "screen reader friendly" qui soit, tous simplement parce-que leur UI est simple à rendre compatible, ce n'est que du texte et des formulaire.
Comme le fait remarquer @ji_louis, c'est simple ...pour un site administratif.

P.S. : Je croit bien, sauf erreur de ma part, que l'administration public a un service dédier à l'accessibilité de ces sites.

Et ces même administrations continue d'envoyer des courriers papiers et n'acceptent pas forcément des mails pour qu'on leurs répondent.
Un jour quand j'en aurai marre je vais leur répondre en braille. :;D
Et si un service n'est pas disponible, on fait comment ?
Il faut une alternative, et il faut laisser le choix à l'utilisateur.

Oui et. C'est pareil pour tout le monde.
Là dessus aucune discrimination ils sont insupportables pour tout le monde.

Le téléphone c'est bien beau, mais ça coûte cher, surtout que les numéros surtaxés sont mise en avant et que les numéros au tarifs normal sont cachés et même supprimées.
J'utilise un service de transport adapté, j'ai réclamé le numéro normal, car avec toutes les attentes cumulées, j'avais de grosses notes de téléphones en fin d moi.

Oui et. Encore une fois c'est pareil pour tout le monde.
Dans le cas de l'article, c'est juste un non sujet puisqu'il suffit de lancer faire recherche dans l'annuaire ou sur Google (déjà bien "screen reader compatible") pour avoir un numéro non surtaxer directement disponible.
Après je suis tout à fait d'accord que certaines entreprises en joue pour limiter les appels ou faire du fric, mais ça c'est plutôt égalitaire de leurs parts.
[LOL]Peut importe le handicape, chez nous on vous enfle pareille.[/LOL]
Enfin, ça n'excuse rien, mais en théorie, depuis peut les services téléphoniques surtaxés doivent s'annoncer avant de commencer la surfacturation de l'appel (c'est pas la panacée, mais ça vas dans le bon sens).

Revenons à nos moutons, faire un site accessible c'est simple, surtout si on fait du HTML propre.
HTML5 et ARIA ont déjà répondus aux problèmes, il suffit de le respecter.

Oui ...mais faire du HTML propre pour présenter du simple texte ou des formulaire, c'est facile.
En revanche pour une WebApp avec des centaines de Components que vous n'avez pas, la plus part du temps en tout cas, développer vous même, c'est autre chose.
D'ailleurs même à les développer vous même, à moins que le client soit prêt à y mettre une grosse somme ce n'est juste pas faisable si vous n'avez pas une personne/équipe dédié et spécialisé à la tâche.
De plus, j'en suis désolé, mais vous ne semblez pas vous rendre compte que les normes d'accessibilités mises en place, ont été créer à un moment ou le web ne servait encore qu'à faire transiter du texte simple (HTML3/4, XHTML, ...etc).
Maintenant, il est possible d’utilisé les attributs ARIA et de mettre en place un balisage "screen reader ready", mais je regrette ce n'est pas SIMPLE.
Enfin, on peut argumenté des heures, mais dès lors que vous commencer à coder une WebApp (ou toutes application ayant une UI complexe) ça devient invivable pour le dev ou en tous cas très compliquer sans faire exploser le budget d'un projet.
Je vous l'accorde Dominno's a les moyens, mais c'est loin d'être une généralité et ce jugement ne me semble pas faire de distinction en fonction du porte monnaie des sociétés.

Il reste des problèmes
Un exemple de gros problème c'est que les développeur ne gère que la sourie pour leurs composants, et les non-voyant on utilise pas le clavier.
Alors tout ce bazar javascript css n'est pas souvant accessible

On est bien d'accord et ça rejoint ce que j'écris.
Pour une UI simple en HTML/CSS c'est faisable, mais dès que ça ce complique ça devient plus Hard.
D’ailleurs le problème des sites ne gérant que l'interaction via pointeur, pose également problème sur support tactile.
Support qui est parfois la seules interfaces disponible/pratique à certains autres handicapes.

Faire un site accessible c'est aussi faire du web sémantique
C'est à dire qu'un robot pourra les parcourir pour les recherches et le référencement, c'est mieux, alors ça ne concernent pas seulement les déficients visuels, comme ça vous n'aurez pas l'impression de perdre votre temps.

Oui, la sémantique est très importante ...quand elle à du sens .
Dans le cas d'une UI ce n'est pas toujours le cas, voire même parfois impossible d'attribué un sens à un éléments.
Je rappel que les seules attributs ARIA, ainsi que leurs mise à jours, ne suffisent pas à donner une sémantique à toutes les interactions visuel possible.
Elles font un bon travail de description, mais encore une fois ça demandera une personne/équipe dédier à la tâche, pour avoir un résultat pas forcement à la hauteur.

Par contre les catchas à base d'images c'est toujours la m*!, surtout les catchas sémantiques, et même pour les voyants.

+10 000. Rien à redire là dessus.

Sii vous testez c''est mieux de le faire sans l'écran

...Mouais.
Pour un site perso (pas une WebApp complexe), en y mettant de la bonne volonté pourquoi pas.
Maintenant dans un environnement pro avec les contrainte de TDD/CI/CD, juste pas faisable sans une équipe dédié et spécialisé.
Dans tous les cas ça demandera un budget conséquent.

Bref tous ça pour revenir à mon 1er commentaire et affirmer que :

• Dans le cas précis de l'article, ça n'as juste pas de sens.
• Le développement "screen reader ready" n'est pas si simple que certain le crois
• Qu'il y a bien d'autre choses à mettre en place dans notre société pour facilité la vie de tous le monde, avant de s'attaquer à Dominno's parce-qu'un gars voulais pas utiliser son téléphone.

@clementmarcotte

Être aveugle c'est un léger handicap ?

Au Canada, la non discrimination sur la base du handicap et la non discrimination en général est un droit constitutionnel de depuis 1982 et les Tribunaux y font très attention et l'interprètent généralement très largement en faveur des citoyens. C'est un droit fondamental autant que la liberté d'expression ou de religion.

Et quand je lis les réponses en général, je les trouves méchantes, insensibles et bornées. Là ce sont les Français qui sont aveugles. Liberté juste pour les non-handicapés, inégalité les handicapés, non-fraternité envers les "anormaux". Puis ça se dit un pays civilisé.

Au Canada ...et dans pleins d'autres pays ayant ratifier la "Déclaration universelle des droits de l'homme" à partir de 1948.
A part peut-être le commentaire de @Fleur en plastique, je n'est rien lue d'autre qui puisse être qualifié de méchant, insensible ou borné dans les commentaires.
Et puis, ça ne veut rien dire un "pays civilisé", "développé" à la limite, mais citez moi un pays qui ne soit pas basé sur une civilisation.
[LOL]Je veut dire que même le Canada à une civilisation de base[/LOL]

P.S. : Je vais énoncé une vérité que les Bisounours ont oubliés de faire passé :
Par définition, la vie sera toujours plus compliqué pour une personne avec un handicape.
Je suis tout à fait conscient que ce n'est pas une raison pour ne pas essayer de leur simplifier la vie, mais par définition ce sera toujours plus compliqué.
Donc les personnes qui pense que les choses sont simple, même à y mettre de la bonne volonté, je leur répond que non sa ne va pas de sois et peut importe où vous êtes ce sera toujours vrai.

[Invité]

Ça me conforte d'autant plus dans l'idée qu'il devrait être obligatoirement appris dès le primaire et par tous au même titre l'alphabet latin.

Contente-toi déjà de maîtriser la grammaire et la conjugaison du français avant d'apprendre le braille
Je vais noyer mes yeux dans le collyre pour y nettoyer tout le sang que tu y as généré.

[clementmarcotte]

P.S. : Je vais énoncé une vérité que les Bisounours ont oubliés de faire passé :
Par définition, la vie sera toujours plus compliqué pour une personne avec un handicape.
Je suis tout à fait conscient que ce n'est pas une raison pour ne pas essayer de leur simplifier la vie, mais par définition ce sera toujours plus compliqué.
Donc les personnes qui pense que les choses sont simple, même à y mettre de la bonne volonté, je leur répond que non sa ne va pas de sois et peut importe où vous êtes ce sera toujours vrai.

Su au moins tu faisais preuve d'un peu de bonne volonté.
https://www.microsoft.com/fr-ca/ai/a...gDcQ#primaryR5
https://www.microsoft.com/en-us/accessibility
https://www.microsoft.com/en-us/acce..._1%3aprimaryr2
https://www.microsoft.com/france/Accessibilite/
https://www.microsoft.com/fr-ca/Accessibility
https://www.microsoft.com/fr-ca/Accessibility/office

[CoderInTheDark]

@CoderInTheDark +1
Pour le coup, tu m'as appris quelque chose concernant le braille.
Ça me conforte d'autant plus dans l'idée qu'il devrait être obligatoirement appris dès le primaire et par tous au même titre l'alphabet latin.

Comme quoi on a toujours besoin d'un plus petit que soi, comme dans la fable du lion et de la sourie.

Pas sûr que tu soit toujours de cet avis après avoir lu ça.

En effet le braille n'est pas facile à apprendre, j'ai mis un an à apprendre les 26 lettres, après il a fallu apprendre les lettres accentuées ce sont des symboles à part, car on ne peut pas accentuer une lettre braille.
Il n'y a que 6 points soit 64 possibilités et 8 points en braille informatique soit 256 possibilités, car pour représenter les symboles ça ne suffisait pas.

64 possibilité c'est juste aussi.
C'est pourquoi les accents servent aussi pour les chiffres, on met un modificateur devant pour dire que sont a affaire à un nombre, en général on à pas de chiffre dans un mot.

Moi j'utilise très peu la plage braille et le braille informatique car le casque et la synthèse vocale me suffisent sur l'ordinateur, et les points en plastique d'une plage brailles me fatiguent le doigt.

En plus il ya plusieurs braille.
-L'intégral chaques symboles brailles représente une lettre, c''est le premier qu'on apprend.
- l'abrégé, qui permet de raccourcir les textes et d'accélérer la lecture, je n'ai pas encore fait la démarche de l'apprendre, je ne suis pas convaincu que ça gagne vraiment du temps, et doncje ne suis pas convaincu du retour sur l'investissement.
- le mathématique, car si on veut faire des maths il faut utiliser beaucoup de symbole
- le musicale, que j'aimerai bien apprendre

Oui l'ai dit le doigt car je ne sais lire qu'avec l'index droit, et pratiquement pas avec le gauche.
Je n'ai pas vraiment été un bon élève, car je n'ai pas écouté mes formateurs et j'ai surtout utilisé mon index droit.
Car on doit savoir lire à deux main, c'est à dire avec au moins les index des deux mains.
Mais en pratique la main gauche, pour les droitier, sert surtout à ne pas perdre sa ligne, et commence juste à lire le temps que la main droite arrive.
Mes premier livre braille étaient écrits une ligne sur deux, car au début c'est dur de ne pas se tromper de ligne.

Comme je le disais je lis surtout avec l'index droit.
Une fois j'ai été ennuyé, car je me suis fais une petite coupure à l'index droit.
J'ai eu beaucoup de mal à lire pendant 2 semaines.
J'ai essayé de compenser en lisant avec le majeur droit, le problème est que l'on met du temps à développer la sensibilité .
C'est pourquoi tout le monde ne peut pas apprendre, les personnes qui ont eu un métier manuelle, on parfois des difficultés à développer cette sensibilité

Je fais aussi de la guitare et de la basse.
La basse pose plus de problème, car on attaque les cordes avec le dessous du doigt, la même partie qui lit.
Car contrairement à ce que beaucoup de personnes pensent on ne lit pas avec l'extremité du doigt.

En général je ne lis pas plus de 10 à 20 pages d'une traite car le doigt fatigue au bout d'un moment, et ne reconnait plus les points.
Une fois j'avais un début d'ampoule à force de lire les chroniques martiennes.
Et comme tous les livres brailles ne se valent pas, ou s'use, ça fatigue de déchiffrer.

Actuellement je suis en train de lire "le premier homme" d'Albert Camus, le livre est ancien et a été écrit à la main et certains points sont éffacés, il y a des fautes de frappes, et comme il a été écrit à la main les pages sont imprimés que d'un seul côté, ce qui auguemente le nombre de volumes.
C'est pourquoi je préfère les livres récent imprimés par une machine.
En plus il faut multiplier le nombre de pages de la version en noire c'est à dire vos livres à vous, par 2 à 3.
Dans mon cas ça fait 12 volumes de 80 à 100 pages
C'est pourquoi je n'ai pas encore lu de Zola, Balzac, ou d'Harry Potter en braille.
J'ai lu des livres de 20 à 30 volumes sachant qu'il me faut en générale 1 semaine par volume, 2 à 3pendant les vacances.
ais je préfère me limiter à moins de 15 volumes.

Je peux les emprunter, et on me les envoie par la poste.
Mais pour combien de t'emps ? Car il y a des rumeurs disant que ce service gratuit est menacé, la poste ancienne entreprise publique rechignerai à assumer cet héritage.

Cafait toujours le désespoire du facteur qui doit s'y coller.
Car on m'envoie plusieur livres à la fois 3 à 4,.
La dernière fois ça faisait la taille d'un petit frigo
Ca prend de la place à lla maison, mais je suis sûr d'avvoir de la lecture.

Le problème est que on imprime de moins en moins de livres en brailles papier ca coûte cher et ça prend de la place, c'est pour ça que je les empruntes.
C'est dur d'avoir des livres récents.
Mais heureusement j'ai beaucoup de classique a lire, et avec le stock existant j'ai le temps de voir venir.
Car la tendance est de priviligié les brailles numérique, c'est à dire des fichiers à lire sur l'odinateur avec une plage braille, ou avec un terminal braille autonome.
Les livres audio sont aussi mis en avant, ce sont soit des enregistement fait par un acteur, je n'aime pas car les acteurs font bien leur métier et leur jeu m'influence, et me prive d'une part d'imaginaire.
Il y aussi des livres audio réalisé par des synthèse vocale très convaincante.
Moi je ne veux pas perdre ce contact avec le livre.

Le braille est aussi sur plastique
On utilise beaucoup de bande dymo qu'on écrit nous même, pour repérer un tas de truc.

C'est comme ça que J'ai fait mon système à base de magnette et de bande dymo, pour refaire des diagrammes de class et de MCD.
Et ça me permet de concevoir avec des voyants

Au sujet de la lecture, je ne veux pas lire à haute voix en publique.
Je trouve ça humiliant car je vais lentement et en plus comme je lis avec le doigt, j'ai l'impréssion d'être de retour à l'école primaire.

J'ai parlé de la lecture, mais il y a aussi l'écriture.

On peut écrire à la main avec un poinçon et une règlette ou une tablette.
Mais pour écrire il faut endosser, c'est à dire donner des coups de poinçon au dos du support.
Alors il faut penser à l'envers lorsque l'on donne les coups de poinçon pour faire une syméttrie horizontale, et écrire de droite à gauche .
C'est source d'erreur, personnellement je ne fait que mes étiquette à la règlette car je fais trop de faute sur un texte.

Il y a une machine à écrire le braille, la Perkins, qui à l'avantage de taper à lendroit.
C'est un truc en métal lourd qu'on croierait sorti des usines Vuick ou Cadillac dans les années 60.
Ca fait un bruit d'enfer, moi je m'en suis surtout servi pour la musculation. ;D

Comme j'ai eu des cours de dactylograpphie, j'ai appris à taper sans regarder le clavier.
Et puis j'ai toujours préferé les raccourcis clavier à la sourie, j'ai toujours trouvé cela plus rapide que de rechercher le pointeur .
en déplacement j'utilise un mac book air 13 pouce avec un casque c'est bien mieux en mobilité.

Alors tu veux toujours imposer l'apprentissage du braille ?







Tout le monde ne peut pas apprendre le braille, il faut développer une sensibilité tactile.
Des personnes qui ont un métier manuel sont parfois très handicapé dans l'apprentissage

@CoderInTheDark +1
De plus, je te rejoint tout à fait sur le fait de rendre plus accessible ce qui peut l'être et dans tous les cas de proposer des méthodes d'accès alternatives quand c'est possible.
Et d’ailleurs c'est ce que je pointais du doigt avec pour exemple, dans le cas cité, l'usage du téléphone au lieu du site.

Je cherche la petite bête, mais les personnes défficiente visuelles et défficiente auditives elles font comment avec le téléphone.
C'est pourquoi Il faut étendre les spossibilités au maximum.

Il y a aussi le facile à lire et à comprendre
Pour les personnes souffrant d'une déficience intellectuelle, qui auront plus de facilité à lire un site internet, que d'écouter le téléphone qui ne répètera pas et va trop vite.

@CoderInTheDark +1
Concernant l'obligation de passer par des sites web, je trouve que ça va dans le sens du progrès, surtout au vu de l'accueil/compréhension parfois douteux/se dont nous gratifiaient les agents.

Certain disent que c'est une forme de déshumanisation, mais se retrouver face à un employé surchargé, qui fait la gueule, au final on peut préférer le site internet austère, c'est sûr.

Mais le vrai problème c'est que tout le monde n'a pas un ordinateur, et ne sait pas s'en servir.
C'est placé des personne dans une situation handicapante.

Surtout les cas particulier ne sont souvent pas pris en compte.
On se retrouve rapidement face à une machine qui vous répète de faire un choix, mais il n'est pas dans la liste, alors c'est vite stressant, car l'utilisateur se retrouve bloqué.
Handicapé ou pas.

@CoderInTheDark +1
En générale les sites Administratifs sont les plus "screen reader friendly" qui soit, tous simplement parce-que leur UI est simple à rendre compatible, ce n'est que du texte et des formulaire.

Moi j'ai une autre lecture.
L'administration a créé le RGAA référentiel du guide de l'accessibilité de l'administration, qui est une transposition du WCAG Web GuideLine Content Accessibility
Dans les contrats et les marchés publiques il y a une clause qui demande d'atteindre un score déterminé d'accessibilité
Comme quoi quand on sort le bâton sa marche.

@CoderInTheDark +1
Oui ...mais faire du HTML propre pour présenter du simple texte ou des formulaire, c'est facile.
En revanche pour une WebApp avec des centaines de Components que vous n'avez pas, la plus part du temps en tout cas, développer vous même, c'est autre chose.
...
De plus, j'en suis désolé, mais vous ne semblez pas vous rendre compte que les normes d'accessibilités mises en place, ont été créer à un moment ou le web ne servait encore qu'à faire transiter du texte simple (HTML3/4, XHTML, ...etc).
Maintenant, il est possible d’utilisé les attributs ARIA et de mettre en place un balisage "screen reader ready", mais je regrette ce n'est pas SIMPLE.

Vous vous mettez le doigt dans l'oeil jusqu'au talon.

Ariaça veut dire Accessible Rich Internet Application, la norme a été pensé pour le web 2.0, qui du fait de sa nature dynamique son emploi massif du JavaScript aller poser problème.
C'est pourquoi le W3c avait pris les devant et mis en place cette norme pour répondre au défis que poserait le Web 2.0

Et donc je ne comprends pas cette référence au passé.
Au temps du web statique, le web textuelle ne posait pas autant de problème

De nombreux problème ont pour origine des ccomposant maison.

Pour les composant d'éditeur tiers.
Il faut faire de l'accessibilité par le haut, si un composant est inaccessible il faut s'adresser à l'éditeur du framework, plutôt que de tomber sur un wevmaster en particulier.
La mise à jour du framework permettera de faire ruisseler l'accessibilité sur tous les sites utilisateurs.

Mais la vérité est que les gens font du n'importe quoi avec des SPAN ou des DIV, qui n'ont pas de sémantiques.
Ou détourrne des composant de leur emploi, un tableau comme grille de placement, dans ce cas il faut mettre "role='prsentation"" dans la balise table, pour signifier le nouveau sens.

Des tableaux à base de DIV ou de SPAN, faut être maso. Et là il faudra mettre un max d'attribut role pour donner du sens au machin pour lui donner une sémantique de tableau.

Des bouton de validdations de formulaire avec une DIV ou une SPAN, c'est vrai que ça demande un gros effort de mettre "role='button' et "tabindex=''", pour le rendre focussable.
Quand ça été à la mode on s'est retrouvé avec des formulaire impossible à valider, car le bouton était introuvable, car ce n'était pâs un bouton mais un truc déssiner à l'écran.

Je disais qu'on ne pouvait pas utiliser la sourie.
ARIA permet de faire des drag and drop accessible au clavier, si ce n'est pas un exemple d'application complexe.

Tout n'est pas accessible, et tout ne pourra être rendu accessible mais on peut quand même faire mieux.

Déjà si les dev pensait à mettre "<html lang='fr'> ".
Car sinon le lecteur d'écran lit la page comme si elle avait été rédigé en anglais.
Ce n'est pas de l'accessibilité c'est du bon sens, si la page est écrite en français il faut le dire.
C'est juste que certains sont trop paresseux et parte d'un template sans le modifier.

A ce propos Sonar signal ce genre de problème.
Il y a des outils de tests et de mesure de l'accessibilité qui peuvent aider.

C'est surtout un manque de volonté, car même les règles les plus simples sont ignorées

Moi je me bat déjà pour le minimum vital, mais ça semble déjà être trop dur pour certain

[CoderInTheDark]

C'est terminé à 80%
Je n'ai pas terminé la partie sur les zone live.
Mais déjà faire ce qui est dessous, est-ce si dur ? à votre avis


********************


1 Comment écrire du HTML accessible*?
Présentation du contexte
Ce document est destiné aux développeurs, web designer et webmasters, qui souhaitent rendre leurs sites ou applications web accessibles, au plus grand nombre d’utilisateurs. Même si ce document traite avant tout de l’accessibilité pour les déficients visuels, il peut s’appliquer à tout type de handicap. Il peut s’appliquer au web sémantique et tests automatisés d’interfaces.
Les auteurs
Fabrice LUNEAU, je suis développeur, Java/J2E. Je suis titulaire d’un BTS d’informatique de gestion option développeur et d’une licence de concepteur développeur informatique. JE suis devenu non voyant à la suite d’une maladie. Je connaissais déjà là problématique de l’accessibilité de l’outil informatique, car j’intervenais bénévolement dans une association de déficient visuels, et j’ai pu échanger avec des adhérents sur cette problématique. Après avoir perdu la vue, j’ai pu constater les problèmes d’accessibilité de l’outil informatique et de la fonction de développeur pour les déficients visuels, au cours de ma reconversion professionnelle.



Introduction
Dans ce document nous expliquerons essentiellement comment écrire du HTML accessible. D’une manière générale il convient d’utiliser le HTML de façon sémantique et non visuelle. C’est-à-dire qu’une balise doit être utilisée pour son rôle et non pour son rendu à l’écran. Car les lecteurs d’écran s’appuie sur le rôle ou la fonction d’une balise HTML, pour retourner les informations aux utilisateurs non-voyants. Si l’on souhaite agir sur la présentation il convient d’utiliser les propriétés CSS.
On peut s’appuyer sur la norme ARIA(Accessible Rich Internet Application)du W3C et HTML5, qui sont des formidables avancées en matière d’accessibilité.
Afin de restituer l’information à l’utilisateur le lecteur d’écran, crée une copie de la page, qui s’appuie sur le code HTML, pour créer une version accessible à plat. Nous allons exposer comment bien renseigner cces informations en partant du haut de la page jusqu’au pied de page.

La page HTML
Lorsque l’internaute non-voyant arrive sur une page, un certain nombre d’informations lui sont annoncées*:
Liste de 3 éléments
• Le titre de la page
• le nombre de cadre
• Le nombre de liens
• Le nombre de titres
• le nombre de zones, qui composent le document
Fin de liste
Ensuite le lecteur d’écran commence la lecture du document depuis le début.
En général l’utilisateur, stop la lecture et cherche à aller au contenu principal via une touche de raccourcis. En allant au premier titre de niveau un de la page, ou en cliquants sur un lien d’évitement «*aller au contenu*» ou «*skip to main content*». Cela évite de faire une recherche hasardeuse dans la page.
Ensuite il est possible de naviguer avec la touche tabulation pour aller d’élément focusable en éléments focusable (liens, éléments de formulaire,….). Mais le fait d’appuyer sur la touche tabulation saute la lecture des textes, qui ne sont pas focusable.
Il est aussi possible de naviguer entre les différentes zones de la page, si la page utilise cette possibilité.
Il est possible d’obtenir la liste de tous les éléments classés par catégories et de demander à se déplacer à un élément par son type.
En pratique, les lecteurs d’écran permettent d’obtenir*:
Liste de 3 éléments
• la liste des liens hyper texte
Grâce à elle, il est possible de parcourir la liste pour rechercher le lien désiré. C’est pourquoi les liens doivent avoir un texte évocateur.
◦ un lien nommé*: «*cliquer ici*» ne veut rien dire*!
• la liste des titres par niveau. Celle-ci permet de se déplacer dans le document pour rechercher le contenu désiré. Le lecteur d’écran annonce «*titre de niveau n*» et après lit le texte. . C’est pourquoi les niveaux de titres doivent être utilisés pour leurs niveaux et non pour leur apparence.
Il est important de noté, que la mise en formes n’est pas annoncées*:
• taille du texte
• couleur du texte, même un text transparent sera lu
• aspect de la police italic, gras, souligné,…
• Les lecteurs fournissent ces informations si l’utilisateur en fait la demande explicitement, mais l’intérêt est limité.

• la liste des zones de formulaire
Pour les formulaires, il est possible d’obtenir toute la liste des éléments et de naviguer directement, parmi ces derniers.
Liste de 4 éléments
◦ champs
◦ zone de texte
◦ case à cocher
◦ boutons radios
◦ bouton

• les zones composant la page.
•
Fin de liste Fin de liste Problématique technique
Les lecteurs d’écrans vocalisent tous les éléments textuels et foc usable, or un certain nombre d’éléments ne disposent pas par défaut de texte, comme les images et les champs de formulaires.
De plus le texte fournit doit avoir du sens dans le contexte de la page et hors du contexte. Car la navigation sur une page n’est pas forcément linéaire. Elle peut être interrompue et lors de la reprise l’information fournie peu être incompréhensible hors de son contexte, si l’on arrive directement sur un élément. Par exemple un lien intitulé «*ici*», qui est précédé du texte «*pour télécharger le logiciel cliquer ici*», n‘a pas de sens si l’on arrive directement dessus avec la touche tabulation Il faut réunir les deux informations.
Il ne faut aussi ne pas oublier que l’internaute non-voyant n’utilise pas de souris, et donc des éléments non foc usable au clavier seront inaccessibles.
Par exemple une image simulant un bouton de validation de formulaire , activable seulement à la souris*; ne sera pas accessible.Et sera reconnu comme une image et non comme un bouton par le lecteur d’écran

1 Mise en place dans le code.
Les solutions proposé dans ce document, , requiert peu de technique. Elles reposent en grandes partie sur la mise à disposition d’untexte accessible et à sa mise en valeur par le code HTML. Et dans un deuxième temps sur l’utilisation des propriétés ARIA et en particulier «*rôle «*.

Les stratégies.
Il existe deux stratégies possibles.

Créer Un site totalement accessible.
La première approche est de créer un site totalement accessible. Cependant on peut être confronté à des solutions techniques antagoniques. Néanmoins cela n’est pas un objectif impossible à tenir.
Une première approche est d’utiliser du HTML standard, sans élément dynamiques, limiter l’utilisation du JavaScript et d’élément dessinés en CSS.

1 Créer un site alternatif accessible.
La deuxième approche est de proposer des outils directement intégrés dans les pages.
• Des feuilles de styles pour les malvoyants, avec des contrastes moins agressifs ou négatifs (vert sur noir, blanc sur noir).
• Créer un site alternatif en HTML simple ou sans les éléments non-accessibles, remplacer les éléments dynamiques par des éléments HTML statiques. Remplacer les menus pliables par des listes.*
• Il est possible de créer des éléments seulement accessible et visible par les lecteurs d’écrans.

Entête de la page
Pour se comprendre le mieux est de parler la même langue. Ainsi il est important d’indiquer dans le code de la page la langue du contenu.
<html lang="fr">

Sinon à défaut il se peut, que le lecteur d’écran essaye de lire la page en français avec une voix anglaise, ce qui est pratiquement incompréhensible.
Le lecteur d’écran peut détecter automatiquement la langue*et certaindialect du texte , dans la pratique cette solution n’est pas toujours fiable.

Sans la balise <body> ajouter la propriété ARIA role avec la valeur
• «*Document*» par défaut
• »application*» si la page n’est pas destiné à être manipulé par un navigateur web ou lu par un utilisateur humain.

1 Structurer le document
Si le document est composé de plusieurs parties, il faut les identifier explicitement. Les zones sont annoncées par le letteur d’écrans ce qui guide la navigation.

• L’entête header
<header role="banner">…
</header>

• le menu ou les menus
<nav role="navigation">
…
</nav>

• Le contenu principal du document, il peut en y avoir qu'un par page.
<main role="main">
…
</main>

• Le pied de page footer
<footer role="contentinfo">
…
</footer>


Le titre de la page
Le titre de la page doit annoncer la fonction de la page et rappeler sur quel site on se trouve. Car si l’on change de fenêtre ou d’onglet, il doit être possible de s’appuyer sur lui, pour savoir où l’on se trouve.
Une page intitulé «*Accueil*», ne fournit pas assez d’informations, il faut une information complémentaire, comme le nom du site. «*Accueil – de Développez.net*».

Une page intitulé «*Forum sur l’accessibilité des application web*», fournit assez d’informations.
Il est possible de rajouter le nom du site, à chaque fois. Mais de préférence à la fin du titre. Car dans de nombreux cas l’information est superflue. Si on sait où l’on se trouve, il est possible d’intérrompre la lecture .
Les pages de résultat de recherches paginées doivent indiquer le numéro de la page en cours et le nombre de page totale.

Les menus
Il est possible de proposer un ou plusieurs menus , pour la navigation, la recherche,…
Il faut les identifier comme vu précédemment avec la balise «<nav>*» et la propriété «* rôle « nav*», et utiliser les balise <ul> et <li> pour structurer les éléments du menu.
chaque éléments du menu doit être marqué avec la propriété role="menuitem">.

<nav role="navigation">
<ul role="menu">
<li role="menuitem">Accueil</li>
…
</ul>
</nav>

Les titres
La balise <H> est reconnue naturellement. Cependant il faut bien utiliser les titres. Le lecteur d’écran annoncera le titre par son niveau puis par son texte. C’est pourquoi les niveaux de titres doivent être utilisés pour leur sens et non pour leur aspect, comme on le ferai avec un traitement de texte. Cela permet de structurer le document et de guider la lecture.
Pour changer l’aspect d’un titre, il convient d’utiliser les propriétés CSS.
La page doit comprendre un seul titre de niveau 1 dont le contenu doit être proche du titre de la page, c’est-à-dire du contenu de la balise <title>. Puisque on s'attend à trouver le contenu principal de la page en dessous de ce dernier.
On peut éventuellement utiliser plusieurs titre de niveau 1, si on a structurer la page en plusieurs parties, mais toujours un seul titre de niveau 1 par zone.

Note*: Il est d’ussage d’insérer les liens sociaux sous le titre de niveau 1 d’un article par exemple. Pour facilitée la navigation il est préférable de remetttre cette zone après la fin du contenu, car pour donner son avis il faut l’avoir lu*) ;, cela permet de ne pas retourner en arrière pour trouver ces liens.

2 Les textes et les paragraphes
Le texte est naturellement accessible, il suffit de lancer la lecture ou de naviguer avec les touches de flèches. Mais le texte n’est pas focussable. Il est néanmoins possible de naviguer de paragraphe en paragraphe, c'est-à-dire de balise <p> en balise <p>, cependant il ne s’agit pas d’un mode de navigation pertinent.
Il peut être judicieux de placer le focus, à l’endroit où doit commencer la lecture, avec une <div> par exemple, ou d'utiliser un lien d'évitement «*aller au contenu*», «*skip to main content*»,, ou encore utiliser une zone dédié aux lecteur d’écrans comme nous le verrons à la section «*Cacher du texte aux utilisateur voyants*».
Les listes sont aussi naturellement accessibles, elles sont annoncées par «*début de liste*» et «*fin de liste*». Puis ensuite les éléments avec leur présentation puce ou numéros. Elles permettent de structurer un menu par exemple, comme on l’a déjà vu avec la balise <nav>.

3 Cacher du texte aux utilisateur voyants
En théorie il est possible de faire du responsive design à l'attention des déficient visuels avec les propriétés CSS suivantes*:
• aural CSS 2.0) / speech (CSS 2.1)Synthèses vocales
• braillePlages braille
• embossedImprimantes braille

Mais en pratique ces propriétés ne sont pas implémenté dans les navigateurs, donc inutilisables*!

Pour afficher un texte seulement pour les utilisateurs de lecteurs d’écran, il est possible d'utiliser une <div> invisible, c’est à dire des propriétés qui la rende trop petite pour être affiché par le navigateur, avec les propriétés CSS suivantes par exemple*:
.visuallyhidden {

blindZone {*** border: 0;
*** clip: rect(0 0 0 0);
*** height: 1px;
*** margin: -1px;
*** overflow: hidden;
*** padding: 0;
*** position: absolute;
*** width: 1px;
}

Cette solution peut poser des problèmes de référencement, mais est plus cohérente qu’afficher un texte en blanc sur blanc. Une solution de ce type es utilisé par Google sur la page de résultat, un text «*si vous utiliser un lecteur d’écran cliqué ici …*», qui n’est pas visible par les autres utilisateurs.

4 Les images.
Les images sont focussable au clavier. Quand le lecteur d’écran arrive sur une image, s’il ne dispose pas d’information, il lit le nom du fichier de l’image, ce qui n’est pas d’une grande aide et très perturbant, surtout quand il s’agit d’un numéro. Il faut Proposer au minimum une alternativ avec la propriété alt et éventuellement une description avec la propriété description. Il est possible de proposer un lien vers une description avec la propriété «*longdesc*».
C’est pourquoi il est impératif de bien choisir le texte en fonction du contexte de la page.

<img alt=*»*» description=*»*»>

5 Les champs de formulaires.
Les textes décrivant les éléments de formulaire sont indépendants, de ces derniers. C’est pourquoi Il faut définir la propriété id, dans la balise de l’élément de formulaire. Cela permet de les associer avec la balise <label>

<label for=’nom*‘>Nom*:</label><input type=’text’ type=’text’ id=’nom’/>

Ainsi lorsque le lecteur d’écran entrera dans un élément de formulaire il lira le label associé, le type de l‘éléments, puis le contenu, éventuel, du champ. Il est donc possible de savoir quoi saisire.Les options de HTML5, sont également annoncées par le lecteur d’écran. ARIA propose aussi les options «*required*» *et «*invalid*», qui peuvent sembler être en doublon, mais il est préférable d'utiliser les deux, car l’implémentation varie d’un navigateur à l’autre et utiliser les deux augmente les chances que l‘information soit accessible, car il est probable qu’au moins une des deux solution soit prise en compte.
• Saisie obligatoire «*role=*»required».
• Valeur incorrecte «*role=*»invalid*».

***ajouter les propriétés html5 correspondantes**

6 Les éléments cliquables
Il est de plus en plus courant de substituer les boutons HTML par des SPAN ou d'utiliser des images pour simuler des boutons ou des éléments cliquables. Dans la mesure du possible les bouton HTML devraient être préférés.
Néanmoins si vous souhaité utiliser un bouton personnalisé, pour le rendre accessible vous devez*l’adapter Selon une des solution suivantes.

Les boutons html hors formulaire
Les «*<input type=*»bouton*» …*» utilisé en dehors d’un formulaire et associés à un code HTML sont accessibles, et sont actionnable avec la touche «*entré et «*espace*».
Ils ne demandent pas d’adaptation, c’est pourquoi ils devraient être préférés.

<input type="button" value="bouton standard" onClick="alert('clicked')" />
Les boutons sur des liens
On peut ajouter la propriété «*role=*‘button’*» sur un lien, mais il ne faut pas oublier qu’un lien est activé seulement pour la touche entré et pas par la barre espace, il faut donc ajouter un gestionnaire de clavier.

Les boutons <span> et <div>
• Il faut leur attribuer une propriété «*rôle*» «*. avec la valeur «*button*».
• les rendre foccusable, si il ne le sont pas.
leur attribuer un nom accessible à l’aide des attributs aria-label ou aria-labelledby, si il n’y a pas de texte à l’intérieur de la balise.
• Ajouter un gestionnaire de clavier JavaScript , car l'évènement onClick concerne seulement la sourie, il faut gérer la touche espace et entré.

<input type="button" value="bouton standard" onClick="alert('clicked')" />
Valider
</span>

Les boutons interrupteur à deux ou trois état.
Il faut utiliser les propriétés ARIA
• «*role=*»button*»*» .
• Utiliser un gestionnaire de clavier.

La propriété «*aria-pressed*» permet de fixer l’état*:
• «*false*», le bouton n’est pas activé.
• «*True*», le bouton est activé.
«*mixed*», le bouton est dans un état indéterminé (bouton de Schrödinger ).

Il faut gérer l’état avec le JavaScript, et changer le rendu visuel en conséquence.

<span role="button" tabIndex="0" aria-pressed="true" onClick="switchButton(this)" onKeyUp="if(isValidated(event)) {switchButton(this)}">
Interrupteur
</span>

Les boutons images
Il faut s’assurer qu’ils ont une alternative textuelle, surtout quand ils n’ont pas de texte comme pour un bouton qui simulera une icône. Il faut utiliser la propriété ARIA «*label*» ou «*labelledby*» pour fournir un texte descriptif*.
Globalement ils se gèrent comme un bouton à deux états, il faut juste changer les images et le texte associé à l’image.

7 Les tableaux
z

Si un tableau est utilisés pour mettre en forme un contenu, comme un formulaire il faut ajouter l’attribut «*rôle=*»presentation*‘*». Ainsi le lecteur d’écran ignorera le tableau et ne n’indiquera pas la position du curseur dans le tableau, car cette information n’a aucun intérêt.

Les tableaux HTML standards <table>
La navigation dans un tableau peut se faire de cellule en cellule dans tous les sens ou bien de ligne en ligne. Il est possible de demander le titre de la colonne. Le lecteur d’écran peut aussi rappeler automatiquement le titre de la colonne et de la ligne lorsque on entre dans une cellule .C’est pourquoi il est important d’utiliser des entêtes pour les titres de colonnes et de lignes avec <th>
Les tableaux à base de <div> et <span>
Certains framorks web génère des tableaux avec des balises <div> et <span>, or ces dernière no’nt pas de sémantique. Il faut donc ajouter des atrtibuts role pour marquer le tableaux, les colonnes, et les lignes,..?. avec les rôle suivant.
• «*Grid*» pour marquer le tableau équivalent à <table>.
• «*columnheader*» pour les titres de colonnes équivalent à <th>
• «*rowheader*» pour les titres de lignes équivalent à <th>
• «*row pour les lignes équivalent à <tr>.
• «* gridcell” pour les cellules du tableau équivalent à <td>.

8 Mise à jour de contenu
Lorsqu'une partie du document est mise à jour, il faut le notifier à l'utilisateur. Dans notre cas au lecteur d'écran, qui lira l'information à l'utilisateur, sans modifier le focus et la position de son curseur.
Pour cela on peut utiliser les «*zones live*»Il faut.
Il faut définir si la zone doit être relue en entier, cas d*»un récapitulatif d’un panier avec le prix total et le nombre d’article. Ou si seulement le texte qui a été ajouté, par exemple un flux d’actualité.
• définir la zone concernée, avec le «*role=*»region*»*» .
•
<div role="region" aria-live="polite" aria atomic="true" aria-busy="false">
Zone de texte changeante
</div>

Ce composant offre de nombreuses possibilités et j’ai retenu.
Les ajouts, par exemple pour un flux d’actualités. Le lecteur d’écrans lira à l’utilisateur la dernière dépêche dès qu’elle tombera. «*aria-atomic=*‘tru’*».

la modification, le lecteur d’écran relie tout, par exemple le récapitulatif d’un panier. A chaque modification l’utilisateur sera notifié du nombre d’articles et du montant total de son panier. «*aria-atomic=*‘false*‘*».

Conclusion
Comme je l’avais indiqué en début d’article rende son code HTML accessible ne demande pas de techniques particulières, mais plutôt de la rigueur dans le respect des normes ARIA et du HTML en général. Il faut s’assurer qu’il y est un texte à la porté du lecteur d’*«écran, on doit pourvoir le lire dans le code HTML sans afficher la page. Il faut que l’élement HTML est un rôle et si il n’en a pas comme les <DIV< et les <SPAN> lui donner un avec l’attribut «*role=’...’*», et si on détourne une balise de son rôle initiale, il faut lui en attribuer un nouveau. Et il me paraît important de rappeler que le CSS ne change que l’apparence, et n’a pas d’impacts sur les lecteurs d’écrans.
L’accessibilité permet de faciliter l’intégration des personnes en situation de handicap, mais pas seulement elle améliore la lecture des pages par les robots d’indexation et de tests, car le web accessible et le web sémantique utilisent les mêmes leviers.

[defZero]

@CoderInTheDark, +2.
Merci pour le tuto, ça mériterait un article à part.

Je me doutait bien que le braille était galère, d'autant plus le braille français .
Mais ça ne m’aurait pas dérangé de l'apprendre à l'école et puis ça permettrait à plus de gens de prendre conscience des difficultés rencontrées.

Je cherche la petite bête, mais les personnes défficiente visuelles et défficiente auditives elles font comment avec le téléphone.
C'est pourquoi Il faut étendre les spossibilités au maximum.

Il y a aussi le facile à lire et à comprendre
Pour les personnes souffrant d'une déficience intellectuelle, qui auront plus de facilité à lire un site internet, que d'écouter le téléphone qui ne répètera pas et va trop vite.

Quelqu'un de mal voyant & entendant, auras des difficultés, c'est inévitable, mais en générale cette personne devrait bénéficier d'une assistance humaine, de même pour la personne déficiente intellectuelle.
Par contre, je persiste et signe dans l'idée que ce n'est pas possible de s'adapter à tous les handicapes même avec toute la bonne volonté du monde.

Mais le vrai problème c'est que tout le monde n'a pas un ordinateur, et ne sait pas s'en servir.
C'est placé des personne dans une situation handicapante.

Surtout les cas particulier ne sont souvent pas pris en compte.
On se retrouve rapidement face à une machine qui vous répète de faire un choix, mais il n'est pas dans la liste, alors c'est vite stressant, car l'utilisateur se retrouve bloqué.
Handicapé ou pas.

Dans ce cas on parle d' "illectronisme".
En effet c'est un handicape de l'ère moderne, mais on ne peut pas espérer prendre en compte tous les cas particulier, ce serait impossible à faire.
Du moins sans en revenir à la logique du plus petit dénominateur commun, qui est pas mal limitante niveaux progrès.

Moi j'ai une autre lecture.
L'administration a créé le RGAA référentiel du guide de l'accessibilité de l'administration, qui est une transposition du WCAG Web GuideLine Content Accessibility
Dans les contrats et les marchés publiques il y a une clause qui demande d'atteindre un score déterminé d'accessibilité
Comme quoi quand on sort le bâton sa marche.

Ce n'est pas un bâton ça, puisque c'est inclut dans l'appel d'offre, ce sera facturé à l'administration en étant inclus dans les réponses.
Encore une fois, pour qui a les moyens/le temps, c'est faisable, mais ce n'est clairement pas le cas de la majorités des projet informatiques, qui ont plutôt tendance à tirer sur la came, si vous voyez ce que je veux dire .

Ariaça veut dire Accessible Rich Internet Application, la norme a été pensé pour le web 2.0, qui du fait de sa nature dynamique son emploi massif du JavaScript aller poser problème.
C'est pourquoi le W3c avait pris les devant et mis en place cette norme pour répondre au défis que poserait le Web 2.0

Et donc je ne comprends pas cette référence au passé.
Au temps du web statique, le web textuelle ne posait pas autant de problème

De nombreux problème ont pour origine des ccomposant maison.

Oui, le Web 2.0, mais là on est au Web 3.0.
Qui développe encore des WebApp comme en 2016, 2017 ?
Quid des contenues créer par les clients via CMS ou pas ? Vous voyez un client compléter les attribut ARIA et faire du balisage sémantique.

Les avancés ont permit une expansion des possibilités de création, mais clairement l'accessibilité est resté le parent pauvre de ce boom technologique.
En théorie, le Web sémantique devait atteindre son apogée avec le HTML5, alors oui c'est mieux, mais ce n'est pas le graal.
Et les lecteur d'écran ont aussi des difficultés à s'adapter, sans parler du côté live de la norme HTML5, on peut aussi parler des Microformats/Microdatas non interprétés, alors que sémantiquement correct.

Mais la vérité est que les gens font du n'importe quoi avec des SPAN ou des DIV, qui n'ont pas de sémantiques.

+10 000. Tout est dit.

Déjà si les dev pensait à mettre "<html lang='fr'> ".

+10 000.
Avec un petit "Content-Type: text/html; charset=utf-8" paramétré sur le serveur HTTP pour les réponses, ça ferais du bien .
De même qu'un charset UTF-8 sur les base MySQL est pas le swedish je sais plus quoi.
Mais bon, ces derniers points, font partis des bonnes pratiques et normalement sont en static dans les templates de projet.

C'est surtout un manque de volonté, car même les règles les plus simples sont ignorées

Tout à fait d'accord, on parle ici de respect a minima des standard, avant même de parlais de faire des efforts d'accessibilité.

Moi je me bat déjà pour le minimum vital, mais ça semble déjà être trop dur pour certain

Et encore, ça c'est le côté dev, pour les clients le combat est perdu d'avance, sauf à leurs facturé des cours d'accessibilité/sémantique.

Finalement, j'en revient à mon premier poste concernant une sorte de langage Markdown pour lecteur d'écran.
In fine, c'est ce qu'il y a de plus abordable, pour créer un site accessible aux différents handicapes.
Des sites sans js, en une sorte de "Markdown" sémantique spécifique, mais présentant le même contenue, juste plus simple à interpréter pour les lecteurs d'écrans.

P.S. : Quand tu écrit "chroniques martiennes", tu parle bien des Chroniques de Mars de Edgar Rice Burroughs ?
Si oui, comment trouve tu son style d'écriture, moi je le trouve parfois fouillis, même si j’apprécie l'histoire.

[Jipété]

P.S. : Quand tu écrit "chroniques martiennes", tu parle bien des Chroniques de Mars de Edgar Rice Burroughs ?

Comme CoderInTheDark a l'air de savoir de quoi il parle, je penche plutôt pour les "Chroniques martiennes" de Ray Bradbury…

Et sinon, as-tu pris en compte la remarque de 7gyY9w1ZY6ySRgPeaefZ ?

Contente-toi déjà de maîtriser la grammaire et la conjugaison du français avant d'apprendre le braille
Je vais noyer mes yeux dans le collyre pour y nettoyer tout le sang que tu y as généré.

On dirait bien que non, hélas. Peut-être as-tu des actions dans une entreprise qui fabrique du collyre ? Car sa consommation va augmenter…


@CoderInTheDark : est-ce que les lecteurs de pages Web comme ici pour le forum lisent tout et le traduisent d'une manière compréhensible ?
Je pense entre autres aux pouces rouges et verts qui accompagnent les messages postés.

[CoderInTheDark]

@CoderInTheDark, +2.
Merci pour le tuto, ça mériterait un article à part.

J'ai du mal a terminer le tuto.
Je pense qu'il manque pas grand chose, je dois surtout terminer la partie live zone.
Le but est d'aller à l'essentiel pour ne pas vous rebuter

Je suis aussi en panne Peut être aussi car je ne fais plus beaucoup de HTML.
Je fais pafois du teste manuellement et je donne mon avis en relisant le code.

J'ai un problème par exemple j'ai commencé des exemples de codes, avec ce qu'il faut faire et ne pas faire ils sont conformes à l'accessibilité, mais pas accessible à vous.
Comme mon exemple sur les tableaux à base de DIV et de SPAN.
Je ne sais pas comment dessiner le tableau.

Ou tout simplement les pages sont moches et je ne sais pas les rendres plus agréables à vous.
Il parait que j'ai fait un exemple avec des couleurs moches et ilisibl ouarf un truc inaccessibleaux voyants, mon monde à l'envers.

Le CSS c'est impossible à utiliser pour moi, il faut corriger avec les yeux.

@CoderInTheDark, +2.
Je me doutait bien que le braille était galère, d'autant plus le braille français .
Mais ça ne m’aurait pas dérangé de l'apprendre à l'école et puis ça permettrait à plus de gens de prendre conscience des difficultés rencontrées.

Tu dois être maso. ;D
Qu'est ce qui se passe quand on donne du papier à poncer à un déficient visuel ?

Il dit "A la vache c'est écrit vachement petit"

@CoderInTheDark, +2.

Quelqu'un de mal voyant & entendant, auras des difficultés, c'est inévitable, mais en générale cette personne devrait bénéficier d'une assistance humaine, de même pour la personne déficiente intellectuelle.
Par contre, je persiste et signe dans l'idée que ce n'est pas possible de s'adapter à tous les handicapes même avec toute la bonne volonté du monde.

Le facile à lire et à comprendre c'est


un peu le principe de développez.
C'est donner des clegfs à des personnes pour comprendre.
Il n'est pas obligé d'avoir un gros déficit intélectuel.
A minima il faudrait donner des explication sur certains éléments complexe.

@CoderInTheDark, +2.
Et les lecteur d'écran ont aussi des difficultés à s'adapter, sans parler du côté live de la norme HTML5, on peut aussi parler des Microformats/Microdatas non interprétés, alors que sémantiquement correct.

Les lecteurs d'écrans fonctionnent mieux avec le web plutôt qu'avec les clients lourds.
C'est pourquoi on a tendance à gagner à ce que les application web soit des applications internet.

@CoderInTheDark, +2.
Finalement, j'en revient à mon premier poste concernant une sorte de langage Markdown pour lecteur d'écran.
In fine, c'est ce qu'il y a de plus abordable, pour créer un site accessible aux différents handicapes.
Des sites sans js, en une sorte de "Markdown" sémantique spécifique, mais présentant le même contenue, juste plus simple à interpréter pour les lecteurs d'écrans.

Google proposeune version HTML simple des application plus accessible.
Mais bon on n'est pas obligé d'en arrivé là pour tout le monde.

Il y a des problème de comportement avec les navigateurs.
Avec Chrome à une époque on ne pouvait pas quiter un champs, on restait bloqué.
Avec Fire fox j'avais fait un menu dépliant, en CSS, mais après le lecteur d'écran ne pouvait m'annoncer si le menu était ouver ou fermé
Alors que mon menu s'ouvrait et se fermait normalement
...

@CoderInTheDark, +2.
P.S. : Quand tu écrit "chroniques martiennes", tu parle bien des Chroniques de Mars de Edgar Rice Burroughs ?
Si oui, comment trouve tu son style d'écriture, moi je le trouve parfois fouillis, même si j’apprécie l'histoire.

[/quote]

Non, je parlais des "Chroniques martiennes" de Ray Bradbury.
Le problème de la médiathèque où j'emprunte mes livres, est qu'ils ne font pratiquement plus de braille papier.
Mais avec le stock j'ai de quoi voir venir, et j'ai beaucoup de livre ancien à lire.
Au passage je n'ai pas aimé 451 ° F surtout la dernière partie, quand il a réussit à fuire la ville/
L'idée de départ est formidable, mais ça à mal véilli