IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Christian Olivier

42PARTAGES

23  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de ji_louis
Membre régulier https://www.developpez.com
Le 08/10/2019 à 18:17
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!
8  0 
Avatar de CoderInTheDark
Membre émérite https://www.developpez.com
Le 09/10/2019 à 19:52
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.
8  0 
Avatar de CoderInTheDark
Membre émérite https://www.developpez.com
Le 11/10/2019 à 8:43
Citation Envoyé par defZero Voir le message
@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

Citation Envoyé par defZero Voir le message
@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.

Citation Envoyé par defZero Voir le message
@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.

Citation Envoyé par defZero Voir le message
@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.

Citation Envoyé par defZero Voir le message
@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
5  0 
Avatar de
https://www.developpez.com
Le 10/10/2019 à 22:38
Citation Envoyé par defZero Voir le message
Ç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é.
4  0 
Avatar de CoderInTheDark
Membre émérite https://www.developpez.com
Le 11/10/2019 à 8:59
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.
&#9702; 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
&#9702; champs
&#9702; zone de texte
&#9702; case à cocher
&#9702; boutons radios
&#9702; 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.
4  0 
Avatar de eldran64
Membre extrêmement actif https://www.developpez.com
Le 09/10/2019 à 11:16
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?
2  0 
Avatar de CoderInTheDark
Membre émérite https://www.developpez.com
Le 14/10/2019 à 19:08
Citation Envoyé par defZero  Voir le message
@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.

Citation Envoyé par defZero  Voir le message
@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"

Citation Envoyé par defZero  Voir le message
@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.

Citation Envoyé par defZero  Voir le message
@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.
Citation Envoyé par defZero  Voir le message
@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
...

Citation Envoyé par defZero  Voir le message
@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
2  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 08/10/2019 à 15:40
Certes c'est bien pour les malvoyants.

Pour les grosses entreprises, elles ont les moyens, quid des plus modestes ?
1  0 
Avatar de clementmarcotte
Inactif https://www.developpez.com
Le 08/10/2019 à 22:30
Citation Envoyé par Fleur en plastique Voir le message
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é.
2  1 
Avatar de
https://www.developpez.com
Le 09/10/2019 à 11:51
Citation Envoyé par eldran64 Voir le message
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.
1  0