Accessibilité: Designer et implémenter un meilleur produit - FLUPA UX-Day 2015
•Transferir como PPTX, PDF•
1 gostou•824 visualizações
Presenté lors du FLUPA UX-Day 2015. Quelques conseils sur ce que vous pouvez faire, à différents niveau du cycle de vie de vos produits (wireframes, design, code, test) pour les rendre plus accessibles.
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (17)
Accessibilité: Designer et implémenter un meilleur produit - FLUPA UX-Day 2015
- 1. Accessibilité Sophie Buda, FLUPA UX Day 2015 Designer & Implémenter un meilleur produit
- 2. A PROPOS DE MOI…
- 3. POURQUOI?
- 5. La loi
- 6. “laughably terrible PR” “epic fail” “disappointing” “denying essential service” “take affordable transportation away from blind people” “Unacceptable”“accessibility is clearly not a priority for them” “despite their claim, accessibility has not been considered at all” “discriminatory practise”
- 7. 15% de la population mondiale
- 9. PERMANENTS ET TEMPORAIRES Moteur CognitifVisuel Auditif
- 10. EUH… …c’est pas comme s’ils pouvaient utiliser un ordi ou un smartphone?“ ”
- 11. ALTERNATIVES
- 12. LES GUIDELINES Web Content Accessibility Guidelines (WCAG) 2.0 2008 BBC Mobile Accessibility Standards & Guidelines 2013
- 13. SUR QUOI AGIR Wireframe Design Code User test
- 14. WIREFRAME
- 15. STRUCTURE
- 16. greys-anatomy GREY’S ANATOMY 2 videos en Replay STRUCTURE
- 19. CONTENU NON ACCESSIBLE Vidéo importante… Il faudra une alternative (transcript / audio description / sous- titres) Image décorative… Il ne faudra pas d’alternative.
- 21. Fruits légumes Fruits légumes CONTENU NON ACCESSIBLE
- 22. SENS DE LECTURE
- 23. SENS DE LECTURE 12,99 intégrale broadcurch saison 2
- 24. SENS DE LECTURE 1 2 3
- 25. INTERACTION
- 26. INTERACTION Tab. Tab. Tab. Tab. Tab. Tab. …
- 28. DESIGN
- 29. CONTRASTE
- 30. DIFFÉRENCIATION
- 31. STYLES & ACTIONS
- 35. CODE
- 36. ELEMENTS QUI ONT DU SENS
- 37. WAI-ARIA Accessible Rich Internet Applications
- 38. role="tab" aria-selected="false" aria-label="Social" WAI-ARIA role="tab" aria-selected="true" aria-label="Primary" Primary tab. Social tab. To activate tab page press space bar.
- 40. QUAND ON FAIT DES SUPPOSITIONS… “I’d like to be able to see more on each page. Now, I can only see two stories. It would be better if it was smaller.” (utilisateur qui a des problèmes de vue)
- 41. QUAND C’EST OK POUR LES GUIDELINES… “I can’t find a link to log in!” (utilisateur aveugle)
- 42. QUAND C’EST UN BON POINT… “I didn’t need to use it in the game!” (enfant qui a des problèmes de vue)
- 43. POUR EN SAVOIR PLUS… • WCAG 2.0: http://www.w3.org/TR/WCAG20/ • BBC Mobile accessibility guidelines: http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile • Web accessibility in mind: http://webaim.org/ • Tools from the Paciello group: http://www.paciellogroup.com/resources/
Notas do Editor
- Bonjour, bienvenue. Aujourd’hui je suis la pour vous parler d’accessibilité.
- Je vais d’abord me présenter un peu et vous expliquer comment moi je suis arrive a travailler sur des problématiques d’accessibilité. A la base, j’ai une formation d’ingénieur Telecom. Je me suis spécialisée en UX par la suite en faisant un petit détour par la Suède. Ensuite, j’ai commencé a travailler dans une entreprise qui fait des sites et des apps pour le monde de l’aviation. Aujourd'hui, je vis a Londres et je travaille pour une petite agence de conseil en UX. C’est a l’ époque ou je travaillait pour les compagnies aériennes que je suis tombée dans le bain de l’accessibilité. Parce quand je suis arrivée dans la boite, c’était en 2013, y avait cette loi, qui venait d’ être promulguée au Etats-Unis, qui oblige toute les compagnies aériennes qui ont des vols vers le territoire Américain a rendre leur site accessible d’ici fin 2015. On a commence a tester nos sites, et on c’est rendu compte que ca n’allait pas tout. c’ était un peu la panique, parce il y avait plein de choses a changer tout d’un coup pour satisfaire aux normes… Ce que je veux faire aujourd’hui, c’est vous montrer deux-trois petits trucs auquel vous pouvez penser pour éviter de vous retrouver dans une situation comme ca….
- Laissez-moi vous expliquer rapidement pourquoi c’est essentiel de prendre en compte l’accessibilité, au cas ou vous n’êtes pas déjà convaincu, on si vous avez a convaincre d’autres personnes, …
- La première raison, c’est un peu la raison de Bisounours… C’est parce que c’est bien. Internet ouvre un monde de possibilité. Le web a complètement change la vie de la plupart des personnes qui ont un handicap. Une personne aveugle par exemple peut faire ses courses en lignes au lieu de demander a quelqu’un de la conduire au supermarché. Donc, sur le plus moral, rendre son site accessible, c’est la bonne chose a faire. Alors évidemment, en règle générale tout le monde est d’accord avec ca, mais ca ne suffit pas toujours… Heureusement, il y a une autre très bonne raison…
- …c’est tout simplement que c’est la loi. Votre site peut se faire trainer en justice… c’est arrive a des grosses boites comme Netflix ou Uber, et c’est jamais de la très bonne pub.
- La je vous ai mis quelques exemples du genre de choses qui se sont dites a propos de ces boites, sur Twitter, dans des journaux, sur des blogs… La dernière polémique en date c’était lorsque Netflix a sorti Daredevil, une série dont le héros est aveugle… mais la série elle-même n’ étais pas accessible aux aveugles, c’est un peu dommage Donc, c’est pas très bon pour l’image de votre boite de ne pas être accessible, surtout que…
- Il y a entre 15 et 20% de la population mondiale qui présente un handicap. C’est-a-dire presque un milliard de personne…. C’est énorme. Du coup pour un business, c’est pas une très bonne idée de décider de ne pas s’intéresser du tout a tout ces gens, voire de ce les mettre a dos. Surtout que avec le vieillissement de la population, cette part de 15% va plutôt avoir tendance a augmenter…. J’ai vu quelques froncement de sourcils quand j’ai annonce ce chiffre de 15%... Ca parait énorme, mais c’est parce que quand on pense handicap, on a souvent en tête cette petite icon de bonhomme dans un fauteuil roulant….. Mais handicape n’est pas synonyme de fauteuil roulant. En fait, on considère que 90% des handicaps ne sont pas visibles… Alors, j’espère vous avoir un peu convaincu de penser a l’accessibilité. Je sais que il reste peut-être une barrière… souvent les gens avec qui je parle me dissent qu’ils pensent que ca va prendre trop temps, que ca va être chiant, ca va être dur, …. Ben j’ai un scoop. L'accessibilité, c’est pas difficile, et c’est pas un énorme changement quand on travaille dans l’UX. Parce que la clé, c’est de….
- …. De penser aux besoins des utilisateurs… de TOUS les utilisateurs. Alors par quoi il faut commencer pour comprendre les besoins de TOUS les utilisateurs?.
- Il faut retenir qu’il y a 4 types de handicaps: Visuel, Moteur, Cognitif, Auditif. Mais en fait, il ne faut pas s’intéresser aux handicaps, mais plutôt aux barrières créées par ces handicaps. Et en y réfléchissant, vous verrez que l’on peut très confronté à ces barrières sur le web sans souffrir d’un handicap permanent…. Par exemple: Quand on dit handicap visuel, on pense je ne peux pas bien voir la page, donc on se dit personnes aveugles, ou qui qui sont daltoniennes. Mais ça peut aussi être vous et moi, lorsqu'on a oublié nos lunettes, ou un lendemain de soirée, quand on a un peu la gueule de bois et qu’on regarde l’écran en mode ‘oooouuuuh ça fait mal aux yeux’ Pareil pour tout ce qui est d’ordre moteur: on pense paralysie, parkinsons, mais ça peut aussi être avoir le bras dans le plâtre ou utiliser son ordi affalé dans le canapé avec un café dans une main et son téléphone dans l’autre Pour tout ce qui est d’ordre cognitif: on pense troubles de l’attention, difficultés d’apprentissage, autisme, mais ça peut aussi être tout simplement surfer sur le web tout en regardant la tv… Et pour l’audition: on pense surdité, mais ça peut aussi être au bureau et ne pas avoir d’écouteurs pour regarder la super vidéo qu'on vient de vous envoyer… Avant de continuer, je voudrais juste clarifier un point. Souvent quand je parle de certains handicaps, et notamment de personnes aveugles, j’entends des choses du genre:
- « euh pourquoi on devrait s'embêter avec ca, c’est pas si ils pouvaient utiliser un ordi ou un smartphone? » [silence] Si, c’est tout a fait possible. Et contrairement aux idées reçues, un smartphone ca peut être super pour l’accessibilité parce que il y a pleins de features déjà intégrées pour aider… Sur ordi comme sur mobile, il faut juste se dire qu’il y a des façons d’accéder au contenu et d'interagir avec ce contenu qui sont différentes de ce a quoi on pense d’habitude.
- Par example: Certaines personnes utilisent un lecteur d’ écran qui va retranscrire la page au format audio ou braille. Ca s’appelle un lecteur d’ écran, mais ca ne lit pas vraiment ce qu’il y a l’ écran, ce que ca fait c’est que ca va interpréter le code, donc il faut que le code soit clean. Tout le monde ne peut pas utiliser une souris. Du coup certaines personnes utilisent un clavier, ou alors des choses comme un bouton unique ou une sorte de baguette en bouche. Ca peut aussi être un logiciel de reconnaissance vocale par exemple. Autre chose, c’est que même si vous êtes très content du rendu visuel, certaines personnes vont préférer voir votre contenu autrement, avec des zoom ou en customisant le display de la page par exemple en changeants les couleurs du texte et du fond. Dernier truc, les personnes qui ont des troubles cognitifs ne vont pas apprécier si il y a beaucoup de distractions sur la page comme plein de couleurs et d’animations, et si il y a des choses un peu difficile a digérer comme les textes long, et tout ce qui est un peu déroutant, comme par exemple une icon qui a une fonction sur une page puis une fonction différente sur la page suivante.
- Il y a des normes qui font autorité en matière d’accessibilité, ce sont les WCAG 2.0. Mais elles ne sont pas toute récentes. Du coup, pour ce qui est de l’accessibilité sur mobile, il n'y a pas de normes internationalement reconnues. Ce qui est souvent utilise c’est les guidelines pour mobile publiées par la BBC. Je ne suis pas là pour vous expliquer ces normes en détail, parce qu’on n’a pas tout l’après-midi… non, ce que j’ai envie de faire, c’est de vous montrer 2-3 trucs facile à vérifier qui vont faire une grosse différence…
- Vous pouvez agir en plusieurs points du processus de développent d’un projet pour vous assurer, a moindre coup, que le produit final soit accessible. Je vais vous donner quelques conseils de ce que vous pouvez faire a chaque étape. J’ai choisi de prendre des exemples aux hasard, sur des sites de ‘grosses’ boites que vous allez surement reconnaitre, parce que je voulais vous montrer que ca peut arrive a tout le monde de faire ce genre d’erreurs…
- La première chose que vous pouvez faire, c’est annoter vos sketches ou vous wireframes. A ce stade la, vous avez surement défini ce que serais les principaux éléments de votre site ou app, et comment interagir avec… C’est le bon moment pour regarder de près certaines choses comme…
- La structure de la page. Imaginons que dans votre wireframe pour un site de replay, vous ayez plusieurs fois un élément comme ca: Une image, du texte, et l’idée c’est que quand on clique dessus ca envoie vers les vidéos dispo pour la série. Mais la, c'est pas très clair exactement ce qui est un lien ou pas… Si vous passez ca a l’équipe de dev, ils risquent de juste rendre le texte cliquable par exemple. Ca va revenir vers vous, vous aller leur dire que toute la zone doit être cliquable, ca repars chez dev et un autre type va ajouter un lien a l’arrache … Et voila ce que ca peut donner …
- Trois liens vers la même page…. Alors, pour pas mal d’utilisateurs, ca ne fera pas une grosse différence… Mais pour un utilisateur clavier qui va devoir taber a travers 3 liens pour chacune des 20 séries proposées sur la page, ca va vite devenir pénible… pareil pour un utilisateur aveugle. Souvent, ces utilisateurs demandent a leur lecteur d’écran de leur donner une liste de tous les liens sur la page qu’ils vont utiliser pour naviguer. Et la, non seulement la liste est interminable puisque chaque série a 3 liens, mais en plus ces liens ne sont pas supers bien nommes. En plus, honnêtement, c’est pas une façon très élégante d’ écrire son code d’enchainer 3 fois le même lien comme ca. Si on veut que toute la zone soit cliquable, c’est quand même un peu plus propre d’avoir une balise lien dans lequel on met tout le reste…
- Si vous délivrez vos wireframe en les annotant comme ca, la structure est claire des le début. Et du coup, il y a plus de chances que les bonnes balises html soient utilisées, ce qui est super important pour aider les assitive technologies a parser la page. Il y a plein d’autres petites choses que vous pouvez noter pour clarifier la structure, comme les heading levels, dire si une liste ordonnée ou pas, si on utilise un bouton ou lien, etc. Vous avez peut-être remarqué que j’ai écris ‘image sans alt’, je vais expliquer ca dans un instant…
- Un autre truc facile que vous pouvez faire, c’est flager tout le contenu qui risque de ne pas être accessible a tout le monde. Si vous insérez des choses comme ca [montrer] une vidéo ou une image dans votre wireframe, vous savez tout de suite que tout le monde ne va pas pouvoir les voir / entendre.
- Alors notez-le sur les wireframes, et demandez-vous si ces éléments sont essentiels, c’est-a-dire, est-ce que si je passe a cote il me manque une info importante? Si ces éléments sont effectivement essentiels, vous allez devoir prévoir une alternative. Pour une vidéo, ca sera un transcript, de l’audio description, des sous-titres… Pour une image, ca sera, dans le code, un attribut ‘alt’ pour définir un texte alternatif. Voila un petit exemple de ce qui peut se passer, si vous insérez une image sans attribut alt ….
- Cette bannière publicitaire, est lue comme pubbandeauxredir/page1. Ca ne transmet pas du tout le message de l’image. Pourquoi? Parce que sans titre pour le lien, et sans texte alternatif pour l’image, le lecteur d’ écran va juste utiliser ce qu’il peut trouver de plus proche, comme le nom du fichier ou une partie du lien. Même si a l’écran, il n’y a pas de texte associé a une image, un lien, un bouton ou un form field, il faut toujours définir un texte associe ou un label et l’inclure dans le code. Au passage, il y a un autre truc ici qui n’est pas franchement une bonne idée la plupart du temps: utiliser des images de texte au lieu d’un vrai texte, parce que: Vous allez devoir cacher plein de texte pour que les utilisateurs qui ne voient pas l’image ai le message… Une image de texte, ca passe pas très bien quand on zoome, et si on veut utiliser des paramètres custom (changer la police ou la couleur) pour faciliter la lecture, ca va évidemment pas s’appliquer au texte dans l’image… Alors ici, un texte alternatif pour l’image est nécessaire…
- Mais parfois, un texte alternatif est inutile: …ici, un lecteur d’ écran va vous lire ‘fruits légumes fruits légumes’…Il se trouve que la, l’image, c’est pas vraiment une image qui transmet de l’information. Elle est la pour aider les utilisateurs voyants a scanner rapidement la page sans lire le texte. On voit les bananes, on comprends que c’est la section des fruits. Mais cette image n’apporte rien pour un utilisateur qui ne voit pas les images. Du coup, c’est tout a fait acceptable et même carrément recommandé d’utiliser un texte alternatif vide pour cette image, histoire que le lecteur d’écran comprenne bien qu’il peut l’ignorer.
- Une autre chose à noter sur les wireframes, c’est dans quel sens le contenu doit être lu. Le sens de lecture vous parait peut être évident, mais quand ce n’est pas précisé, les choses risquent d’être inverses dans le code et mises dans le bon sens avec du CSS.
- Ici par exemple, vous voulez surement plutôt savoir de quelle série on parle avant de voir combien ca coute de l’acheter, non? Visuellement, c’est comme ca que ca marche, je vois ‘Broadchurch’ puis ‘12,99’. Donc dans le code, le texte ‘broadchurch saison 2’ devrait venir avant le texte ‘12,99 intégrale’ or ce n’est pas le cas. La, on a juste inversé 2 petits bouts de texte, donc c'est pas tout a fait dramatique, Mais ce genre d’inversions, ca peut devenir très mauvais si ca arrive a l’ échelle de sections entières.
- Donc sur les wireframes, quand vous avez des sortes de sections, notez dans quel ordre un utilisateur est sensé lire le contenu: 1,2,3 et hop c’est fait.
- Une autre chose a laquelle vous pouvez réfléchir des le stade des wireframes, c’est comment les utilisateurs vont interagir avec le contenu, , notamment sans souris. Je vous conseille de noter toutes les interactions spéciales ou complexes qui risquent de demander un peu d’attention pour être accessible… les choses comme les tabs, les sections collapsables, les sliders … ou sur cette wireframe, le menu qui ouvre un sous-menu: est-ce qu’un utilisateur de lecteur d’ écran va comprendre que des nouveaux liens apparaissent en dessous? Comment on navigue dans ce menu avec un clavier: ou va le focus quand j’ai activé un lien du menu: dans le sous-menu ou pas?… Souvent, pour ce genre de choses un peu ‘custom’, il n’y a pas une solution accessible prédéfinie qui marche toujours, donc il faudra faire des recherches et tester pour voir ce qui marche dans votre cas ou pas. Essayez aussi de repérer tout ce qui pourrait être optimisé pour aider certains utilisateurs, parce que accessible c’est bien, mais utilisable c’est mieux. Par exemple:
- ….Ici, je dois taber 17 fois pour atteindre la barre de recherche, ou pire, 40 pour arriver contenu principal. C’est pas top, et on pouvait déjà le voir sur la wireframe. Donc la, 2 choix: Soit vous changez la page pour avoir moins de lien avant les liens ‘intéressants’, Soit vous ajouter un skip link, comme ici:
- sur ce site, ce qui se passe c’est que j’arrive, je tab une fois, je suis sur le logo, normal. Je tab une deuxième fois… et la surprise, il y a un petit truc qui apparait et qui me propose de ‘skip to content’… ok, j’appuie sur entrer… et la on m’envoie directement dans la barre de recherche, sans passer par tous les liens de la barre de navigation. On a utilisé un script pour que ce ‘skip to content’ soit caché sauf quand il reçoit le focus grâce a un clavier ou screen reader.
- Donc il y a certaines choses dont vous pouvez vous occuper des le stade des wireframes. Apres il y a des choses que vous pouvez remarquer au moment de définir l’identité visuelle de votre produit… Notamment, est-ce que tout va être suffisamment visible ou pas….
- A partir d’un prototype statique ou même déjà d’un document de ‘design guidelines’ ou de ‘branding’, vous pouvez tester si le contraste sera suffisant ou non pour que le texte soit toujours lisible. Sur cet exemple, j’adore les couleurs… mais honnêtement, ca fait un peu mal aux yeux quand on essaye de lire, surtout le texte blanc sur la photo. Le contraste, ca se teste très facilement, il y a plein d’outils gratuits disponibles qui peuvent vous aider a choisir les couleurs de façon intelligente et de prévoir quelque chose qui marche aussi quand vous utilisez une image en fond.
- Un autre truc super important a vérifier, c’est que vous n’utilisez jamais seulement des éléments visuels, comme une couleur, pour identifier quelque chose: La par exemple, c’est un tableau qui montre les matchs gagnés ou perdus, et a droite, vous pouvez voir ce que ca donne pour quelqu’un qui a une forme de daltonisme… c’est tout de suite beaucoup moins clair.
- Voila un autre exemple ou on identifie quelque chose visuellement et du coup ca marche pas pour tout le monde… ici, ils ont choisi de faire en sorte que quand on passe la souris sur un lien, on nous montre que ce lien a le focus en mettant un effet de flou derrière, ou lieu de le souligner comme c’est fait par défaut: et du coup, ce qui a été fait, c’est que l’indicateur par défaut a été disabled, et on a rajoute cet effet ‘onmouseover’… Le problème? Regardez ce qui se passe pour un utilisateur qui navigue avec son clavier:
- J’arrive sur cette page, je presse ‘tab’. Qu’est-ce qui ce passe? A priori rien.
- Du coup je presse de nouveau Tab. Toujours rien
- Encore une fois, toujours rien. On peut accéder aux liens avec le clavier, sauf qu’en fait on le sais pas , comme on ne voit rien,… du coup… Il y a peu de chances que la personne reste sur votre site. Tout doit être accessible avec le clavier et le feedback doit toujours être clair pour tout le monde. C’est pas seulement la responsabilité des développeurs. Si on passe le design aux codeurs, en leur disant que le flou la, c’est l’effet quand on survole avec le souris, forcement, le clavier va être oublié… Donc ayez le reflexe de toujours penser au clavier, et si vous définissez quelque chose qui se passe quand on survole avec la souris, indiquez aussi l’alternative clavier.
- Alors, a partir de maintenant, je m’adresse surtout aux développeurs… Imaginons qu’on vous passe des wireframes bien annotées comme on l’a vu plus tôt, et que visuellement le design ai était bien pensé pour éviter les problèmes d’accessibilité. Maintenant, c’est a vous de faire attention…
- Pour chaque élément du design, utilisez les éléments HTML correspondants. Evitez au maximum les balises génériques comme div et span. Un lecteur d’ écran ne peut pas aller investiguer dans votre script pour voir que vous faites agir votre élément générique comme un bouton par exemple, et du coup l’utilisateur ne va pas savoir que c’est supposé être un bouton. En plus, ca va vous faire plein de travail supplémentaire pour que ce ‘faux’ bouton soit accessible avec le clavier. Donc, quand un élément natif est disponible, utilisez-le!
- Si il n’existe pas d’éléments natifs pour ce que vous voulez faire vous pouvez vous aider un peu de WAI-aria, mais seulement en dernier recours! A la base, c’est prévu pour les applications ‘riches’ c'est-à-dire avec des components un peu plus interactifs, plus dynamiques que ce qui se fait normalement. C’est ce que je vous avait proposé de flagger sur les wireframes comme ‘truc qui va demander un peu d’attention’. Pourquoi c’est utile WAI-aria? Parce que ca aide les lecteurs d’ écran, en vous permettant par exemple de préciser: quel rôle assume l’élément, et dans quel état il se trouve actuellement, et si il a des propriétés spéciales.
- Un exemple que vous connaissez surement tous: Les tabs dans gmail. Grâce a Aria, le lecteur d’ écran me dit que c’est des tab, il me dit comment chaque tab s’appelle, et il sait laquelle est ouverte et lesquelles sont fermées.
- On a parlé de wireframes, de design et de code. évidemment il faut aussi tester vous-même l’app ou le site avec un clavier et avec un lecteur d’écran. Et c’est aussi très important de tester avec de vrais utilisateurs parce que…
- Quand on fait des suppositions sur ce que veulent les gens, on peut se tromper. Par exemple, on se dit que quelqu'un qui a des problèmes de vue veut surement que tout soit très gros. Mais il y a des limites. Par exemple, sur cette app, quand on l’a testé, tout le monde, y compris les utilisateurs avec des troubles de la vision, a dit préférer avoir des photos et des titres un peu plus petit mais plus d’articles sur la page.
- Une autre très bonne raison de tester avec de vrais utilisateurs, c’est que même quand a priori on a respecte toutes les guidelines, parfois ca va pas marcher quand même pour les utilisateurs. Ici, techniquement, ‘my account’ serait ok pour WCAG 2.0: le lien est bien codé et le titre du lien veut dire quelaue chose… Sauf que en session de test, quand on demandait aux gens de se logger, ils avaient du mal trouver ce lien, notamment certains des utilisateurs aveugles. Pourquoi? Parce que dans leur liste de liens, ils cherchaient un lien qui commence par ‘S’ (pour ‘sign up’) ou ‘L’ (pour ‘log in’), ils ne pensaient pas a chercher sous ‘M’ pour ‘My account’.
- Un dernier truc à mentionner… On ne découvre pas que des problèmes en testant avec des utilisateurs qui présentent un handicap. Parfois, vous pouvez même découvrir des trucs qui vont vous aider à remonter un peu le moral des troupes. Par exemple, lors des tests pour un jeu vidéo pour enfants sur tablette, ça ne se passait pas super bien, il y avait pas mal de trucs qui ne fonctionnaient pas très bien pour les enfants. Normalement, l’équipe avait prévu de ne pas vraiment prendre en compte l’accessibilité avant au moins la 3 ou 4eme version du jeu, mais ils nous ont quand même demandé d’inviter quelques enfants qui ont un handicap mineur… Et on s’est rendu compte que ça ne marchait pas trop mal pour eux. Les gamins dyslexiques ou qui avaient des troubles de l’attention n’avaient pas plus de problèmes que les autres. On avait aussi par exemple un enfant qui en règle générale a besoin d’utiliser zoom intégré à iOS pour voir ce qui se passe à l’écran, et avec ce jeu, il n’en a pas eu besoin du tout.
- Voilà quelques liens utiles si vous voulez en savoir plus… Les deux premiers sont des normes, les deux seconds sont mes 2 sites très utiles pour comprendre l’accessibilité et trouver des tools qui vont serons utiles.