Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Formation et certification Accessiweb
Bonjour,
La question que je me pose : Quels sont vraiment les avantages de la formation et la certification Accessiweb ? y a t-il un plus pour les développeurs ?
Je vois de plus en plus de boites qui financent la formation pour leurs collaborateurs, le but étant clair : "nos collaborateurs sont certifiés accessiweb" et donc gonfler les frais des prestations, j'ai l'impression que l'objectif devient commercial ...
Faut-il être certifié accessiweb pour être bon en accessibilité ???
Honnêtement, je ne pense pas.Envoyé par Macmillenium
Comme tu le dis, il y a certainement un intérêt commercial derrière tout ça.
Je pense aussi ...
J'ai rencontré plusieurs personnes certifiés accessiweb et qui n'ont aucune idée sur l'existence des navigateurs textuels à titre d'exemple
Mais bon si c'est la boite qui finance (vu le prix 2490€) tant mieux sa fera "une validation de compétences" de plus ...
Bonjour Macmillenium,
ça c'est le genre de question qu'il faudrait poser directement à quelqu'un comme Aurélien Levy (par exemple) via son blog
Bien sûr qu'il n'y a pas besoin d'être certifié pour être très compétent en accessibilité, comme tout certification c'est juste un gage de compétence et de sérieux.
Les niveaux d'expertises peuvent être très variable d'une personne à l'autre, ça c'est normal mais ne pas connaître les navigateurs texte pour un expert accessiweb, ça l'a fou vraiment mal en effet!
Hello Erwan,
Oui (logiquement) je pense que c'est l'objectif principale
Dont un responsable pôle intégration web d'une grande web agency sur Paris, sa peut remettre en cause la crédibilité de l'agence ...mais ne pas connaître les navigateurs texte pour un expert accessiweb, ça l'a fou vraiment mal en effet!
Bref, merci pour vos réponses
Personnellement, je le vois surtout comme ça.
Avoir une compétence en plus afin de pouvoir se "démarquer" (au delà du fait que cette formation peut permettre de s'améliorer et d'avoir une autre vision (plus juste ?) au moment du développement).
Pensez à utiliser les ressources disponibles en Dev. Web :
(x)HTML : Cours (X)HTML / FAQ (X)HTML
CSS : Cours CSS / FAQ CSS / Galerie CSS
Javascript : Cours / FAQ / Sources
Mon site : Développeur Web Freelance
Ceci dit l'accessibilité d'un site web (et si l'on exclu les problématiques de contrastes texte/fond du texte) cela reviens essentiellement à réaliser un dev' conforme au normes (sémantique, structure, séparation contenue/mise en forme/action).
Après avis personnel je trouve accesiweb un cran plus light que les normes WAI et WCAG. Ceci dit ça fait joli sur le CV
Je pense que vous parlez vite...
Malheureusement trop peu de site respecte les normes d'accessibilité... C'est un domaine assez complexe à comprendre tout d'abord puisque le fait de rendre un site accessible fait intervenir plusieurs notions : le type d'handicap et pour chacun d'entre eux : les spécificités... Et à tout cela, il faut contenter tout le monde si je peux m'exprimer ainsi !
Il est bien gentil de dire qu'effectivement la certification accessiweb a un but commercial mais si nous partons de cette réflexion, il en est de même pour toutes les certifications !
Enfin, l'accessibilité du web est une question à prendre au sérieux. Pourquoi ? Et bien parce qu'aujourd'hui (février 2008) trop peu de sites sont accessibles ou du moins respectent les normes d'accessibilité... Et, nous nous rapprochons d'une date butoire où les sites de l'Etat Français devront obligatoirement être accessible. Et il en viendra (j'en suis persuadé) aux sites commerciaux français...
Pour rendre un site accessible, il ne suffit pas de connaître deux ou trois petites astuces pour qu'il soit validés.
Tout d'abord, il est très déplorable de voir des sites récemment développés ne respectant pas ces normes... Je trouve cela très dommageables puisque par exemple un site conçu et développé mais non accessible va nécessiter un grand travail de refonte et surtout de relecture du dit site pour y effectuer les corrections nécessaires pour le rendre accessible...
Pour information, le fait de développer un formulaire en utilisant une balise label avec un attribut for suivi d'un champ texte par exemplle avec bien entendu un attribut id correspondant à l'attribut for de la balise label va permettre de lier l'étiquette au champ.
Voilà une des règles de mise en oeuvre d'un formulaire accessible...
Ensuite, pour comprendre d'avantage la problématique de l'accessibilité, il faudrait déjà connaître un petit peu certaines aides techniques utilisées par les personnes handicapées notamment je pense aux déficients visuels...
Savez-vous comment est retraduit une page d'un site web en vocal (via Jaws) ? Et bien, c'est l'intégralité du code HTML qui est intercepté par ce logiciel Jaws. Donc, la personne utilisant ce logiciel "verra" les différentes éléments du site selon la structure donné par le Développeur. Dans ce cas, les feuilles de styles CSS ne sert strictement à rien.
Par exemple, pour la petite anecdote, un site avant en apparence, un menu en première partie (en haut de la page) et, via Jaws, ce menu se trouve à la fin de la page. Et bien oui, en effet, dans le code HTMl, ce menu se trouve juste avant la fermeture de la balise body...
Et, lors de la conception, il faut aussi pas mal de petites choses comme par exemple: le site doit être visible et lisible avec un aperçu noir et blanc.
Voilà ce qu'on peut dire de l'accessibilité et surtout de la certification. Maintenant, je serai entièrement d'accord avec ce que vous venez de dire plus haut dans ce topic, LE JOUR où LA PLUPART des sites (80%) seront accessibles...
Bonjour,
Oui et non, la soumission d'un service en ligne aux directives issues des WCAG n'est pour l'essentiel pas très complexe à mettre en place, ni même celles issues d'ARIA. Tout dépendra de ce que tu souhaites rendre accessible. La mise en ouvre des description audio et des sous titres de contenus multimedia n'est par exemple pas des plus aisé mais ce genre de déploiement reste minoritaire. Il y a aussi l'accessibilité du Flash et d'AJAX...
D'autre types de difficultés comme celle qu'on l'on peut rencontrer à la rédaction d'un alt, ou pour répondre à des problèmes d'accessibilité cognitives ou d'ergonomie peuvent rentrer en jeux.
D'autre part l'accessibilité ne se résume pas à fournir un réponse à la somme des handicaps existant, ce point de vue est une erreur d'appréciation qui ne tient par exemple pas compte des différents contextes d'utilisation (consultation sur appareils mobile, via navigateur texte, sans javacript, images ou CSS...)
Pas strictement non. La propriété display ne se limite pas uniquement aux navigateurs graphiques mais à tous les dispositifs d'utilisation (aussi bien contextuels qu'auditifs ou visuels). Par exemple JAWS sait interpréter le display:none et ne lira pas le contenu de l'élément qui en est doté.
Non la conformité aux standards c'est autre chose que ce que tu met entre parenthèse. Il y a aussi une confusion moins évidente entre validité et conformité aux standards (plutôt du côté navigateur) mais on peut mettre autre chose dans ce qu'on appelle la conformité...
La validité du document participe en règle général à une meilleur accessibilité du document et diminue les risque de mauvaise interprétation des UA (user agents > navigateurs, synthèse vocales...) actuels et à venir.
En revanche une bonne sémantique est essentielle pour l'accessibilité.
Ca n'est pas comparable, Accessiweb comme RGAA, UWEM, Anysurf et les autres référentiels ne sont que des méthodes d'application de la norme WCAG, destinés à faciliter le déploiement des directives WCAG qui en l'état ne sont pas vraiment exploitables, concernant essentiellement les WCAG1.0. Les WCAG2.0 le sont d'avantage même si leur longueur sont plus importantes...
Ensuite le WAI (Web Accessibility Initiative) n'est pas une norme mais une branche du W3C chargée de promouvoir et de produire des normes d'accessibilité comme WCAG, UAAG, etc.
Je me suis mal exprimé. J' entend par conforme aux normes, le fait d'avoir dans le dev, intégré l'ensemble des "Bonnes pratiques et normes" dont celles que je cite entre parenthèse.
Le référentiel WCAG2 est plus long car il est, entre autre, plus complet et justement cherche à fournir aux développeurs les indications qui manquaient à la version 1.0. Afin que les points qui prêtaient le plus à confusion tant dans leur définition que leur mise en œuvre ne le soit plus. Et ainsi fournir un référentiel unique qui n'est plus à être interprété mais à être appliqué.
Salut,
+1
Quelque soit le type d'accès
En effet et je trouve sa un peu trop exigeant, la propriété display est quand même une propriété d'affichage, je ne vois pas trop le rapport avec les lecteurs vocales et principalement les Media Speech ...
Plusieurs contraintes graphiques nous obligent à passer par cette propriété afin de mettre des alternatives textuelles mais bon ...
C'est clair.
Entre Mai 1999 et Décembre 2008 le web a bien évolué.
Salut Macmillenium,
Laissons de côté le media Speech qui n'est à ma connaissance toujours pas implémenté par les principaux lecteurs d'écran et dont le module CSS3 associé n'a d'ailleurs toujours pas atteint le statut de Candidate Recommandation, même si Opera l'implémente déjà en partie...
Je crois qu'à ce sujet une petite mise au point s'impose parce que les faits ne sont pas aussi évidents et binaires qu'ils n'y paraissent:
Pour commencer la propriété display n'est pas une propriété d'affichage à proprement parler mais une propriété de rendu interprétable quelque soit le média spécifié, autrement dit elle influe directement ce qui ce qui rendu ou non à l'utilisateur et non affiché, ce qui suit finalement cette logique d'accessibilité selon laquelle un contenu équivalent doit être servi à l'utilisateur quelque soit son mode de consultation. Les lecteurs d'écran étant soumis à cette contrainte, il est donc logique qu'ils sachent interpréter la propriété display et même la propriété visibility qui est aussi interprétée mais pas toujours dans les même conditions ou de manière différente selon le lecteur d'écran même si celle-ci est spécifique aux médias visuels. Bref encore pas mal de confusion à ce niveau là.
Techniquement le display:none retire l'élément (à partir du DOM tree parsé) de la structure de formatage qui une fois générée par l'UA, est transférée vers le media cible (print, screen...) . De ceci on en conclut que display:none est indépendant du média.
Ceci dit il faut savoir que le display:none n'est pas appliqué de la même manière selon la structure sur laquelle il s'applique sur les principaux lecteurs d'écran:
> Un display:none appliqué à un span qui se trouve à l'intérieur d'un lien ne sera pas pris en compte dans JAWS et HPR, ce qui veut dire qu'il lira le contenu du span.
Exempledans le cas d'une navigation de lien en lien dans un lecteur d'écran.
Code : Sélectionner tout - Visualiser dans une fenêtre à part <a href="...">En savoir plus <span>sur le Château de Fontainebleau</span></a>
Window Eyes quand à lui n'a besoin que d'un background-image sur l'un des ancêtres de l'élément doté du display:none pour pouvoir interprété le contenu de l'élément.
Ceci dit la méthode la plus fiable reste encore celle qui consiste à placer l'élément à masquer aux navigateurs visuels en dehors du viewport via le positionnement absolue, puisque des lecteurs d'écran assez répandues tel que NVDA ou Voice Over (sur MAC) ne liront pas un élément doté d'un display:none.
Bien vu
Merci à tous !
Répondre avec citation
Partager