Le document électronique a l’avantage par rapport aux autres formats de documents d’être manipulable pour, notamment, s’adapter aux handicaps des utilisateurs. Pour les handicapés, l’accès à Internet (et plus généralement à l’outil informatique) est un formidable vecteur d’intégration dans la société, que ce soit pour les actes quotidiens (s’informer, communiquer, acheter, etc) ou pour le travail (lecture, écriture et télétravail).
L’utilisation des standards du Web pour construire un site offre un bénéfice connexe de première importance : le résultat sera plus facilement accessible aux personnes handicapées (cécité complète, partielle, daltonisme, handicap moteur ou cognitif) en étant compatible avec les aides techniques (plage Braille, lecteur vocal, navigation sans souris, etc.).
Les touches d’accès clavier sont a priori un mécanisme d’accessibilité très séduisant par sa simplicité de mise en oeuvre. Mais les nombreux obstacles rencontrés du fait d’une implémentation inachevée en limitent considérablement la portée. Seules une poignée de touches numériques s’avèrent finalement pertinentes, et ce uniquement en renfort d’autres mesures d’accessibilité plus éprouvées.
En fouinant sur le web, on peut découvrir plusieurs pratiques pour appeler des scripts en Javascript qui vérifient le contenu d’un formulaire. Mais elles sont, hélas, rarement correctes dans le sens où beaucoup d’entre elles réduisent l’accessibilité et l’ergonomie des formulaires, voire sont inefficaces. Cet article vous propose de passer en revue ce qu’il faut faire et ne pas faire en la matière.
Comment ouvrir une nouvelle fenêtre sans se priver des internautes qui ne disposent pas de JavaScript ou l’ont désactivé ?
Les images constituent le premier obstacle majeur à l’accessibilité des pages Web. Voici quand et comment en donner un équivalent sous forme de texte.
Réalisons un menu déroulant qui soit à la fois portable, utilisable sans JavaScript et accessible aux personnes handicapées.
En nous présentant les différentes actions de la cellule accessibilité de BrailleNet, Pierre Guillou fait pour nous le point sur les problématiques d’accessibilité du Web.
Pour mieux comprendre l’accessibilité, faisons un tour d’horizon des handicaps et des technologies permettant de les contourner, et comment le W3C s’attelle à faire du Web un endroit accessible à tous.
L’accessibilité de contenus et de services web peut-elle se réduire à l’atteinte de niveaux prédéfinis et réglementés ? Répondre « oui » d’emblée serait réducteur et contre-productif, et c’est pourtant ce qui a été fait jusqu’à présent. Ce premier article va montrer que la problématique est bien plus complexe qu’il n’y paraît.
Le premier article sur la démarche d’accessibilité a montré qu’une approche exclusivement centrée sur des résultats ponctuels et quantifiés était limitée et insuffisante. Mais quels sont les moyens d’anticiper et de maîtriser les risques de façon continue ? Quels sont les outils ? Quelles sont les perspectives ? Ce second article décline quelques élements de réflexion et de réponse.
Au sein des PMI ou des grands comptes, on voit fréquement des projets Internet ou intranet souffrir des effets pervers d’un double pilotage par les directions informatiques (DSI) et les directions communication.
A l’heure où certains pays se dotent d’une législation nationale sur l’accessibilité numérique, ce document rappelle les enjeux internationaux de l’accessibilité, et l’ensemble de ses bénéfices sociaux, financiers, techniques et managériaux.
Les formulaires sont souvent utilisés mais parfois de manière peu souhaitable ou peu accessible. Cet article est là pour faire un tour d’horizon des possibilités et des bonnes habitudes. Il peut être autant utile au débutant cherchant à comprendre les formulaires qu’au confirmé cherchant quelques notions d’accessibilité.
La simple mise en place de formulaires sur un site peut devenir une opération assez complexe dès lors que l’on souhaite effectuer des contrôles sur les données saisies par les utilisateurs. Pour effectuer ce type de contrôles, deux possibilités nous sont offertes :
Dans cet article, nous allons montrer l’intérêt que peut apporter le Modèle Objet de Document (DOM) pour effectuer des contrôles côté client. Cette deuxième solution ne devra toutefois pas nous faire oublier la nécessité absolue d’effectuer dans le même temps des contrôles côté serveur. Ces derniers permettront d’une part d’éviter la soumission complète des données dans un format invalide, et d’autre part nous permettront d’assurer l’accessibilité de nos formulaires aux utilisateurs n’ayant pas la possibilité ou ayant fait le choix de ne pas activer Javascript sur leur poste de travail.
Si la solution proposée ici est un plus par rapport aux indispensables contrôles côté serveur, elle ne manque pas d’intérêt : elle permet d’éviter des échanges de données fastidieux avec le serveur, d’accélérer la validation des formulaires, et également d’enrichir et de faciliter la saisie pour les utilisateurs.
Mais avant de commencer, que devons nous savoir :
Page valide XHTML 1 Strict,
CSS2 et
accessible AA.
Ce site s'affiche mieux dans un navigateur conforme aux standards,
voici pourquoi.
Site hébergé par l'APINC
et propulsé par SPIP.