Imatges, multimèdia i CAPTCHA
Per a cada imatge complexa s'ha de proporcionar una descripció detallada en un document HTML aparte o en el mateix en el qual es troba aquesta imatge.
En HTML 4.01 o XHTML la URL d'esta descripció detallada s'indicarà en l'atribut longdesc de la imatge. Addicionalment, i per a oferir la màxima compatibilitat, es pot proporcionar un enllaç de text a continuació de la imatge, vinculant-ho al començament de la descripció detallada. Encara així, seguix sent necessari oferir per a cada imatge una alternativa textual en l'atribut alt que identifique breument el tipus d'informació transmesa a través del mateix.
Exemple de codi
Descripció de [nom de la imatge]
En canvi, en HTML5 l'atribut longdesc passa a considerar-se com a obsolet. En este cas, la forma d'incloure una descripció detallada és incloent aquesta descripció en la mateixa pàgina o en una pàgina aparte enllaçada amb un enllaç situat de forma contigua a la imatge.
Com a imatge decorativa s'entén tota aquella que no transmet cap informació rellevant i no posseïx funcionalitat alguna. Pensant en una pàgina Web concreta, açò significaria que en mancar d'estes imatges no es perd cap informació.
Com a imatge no decorativa, es pot entendre, que són totes aquelles que complementen d'alguna manera la informació mostrada i/o transmeten informació per si mateixes. Així mateix, les imatges funcionals no es consideren decoratives (enllaços, bàners, etc.)
Un element de vídeo perquè siga accessible de complir els següents punts:
- Posseir una alternativa accessible: Per a qualsevol element de video és necessari proporcionar una alternativa equivalent tant per a la banda visual com per a la sonora, és a dir, una transcripció completa de tota la informació transmesa en el vídeo. A més, aquesta alternativa s'ha de trobar en un format accessible.
- Sincronitzar els equivalents alternatius amb el propi vídeo: Independentment que les presentacions multimèdia posseïsquen un equivalent textual, s'ha de proporcionar un equivalent sincronitzat (subtítols) de la banda sonora.
- Proporcionar una descripció sonora de la informació important de la pista visual: Quan es transmeta informació important en la banda visual del vídeo, és necessari incloure una descripció sonora de l'escena (també cridada Audiodescripción).
- Centelleigs i parpellejos apropiats: S'ha d'evitar que els continguts dels elements de vídeo produïsquen parpellejos i centelleigs.
- Control de la reproducció: És també important proporcionar als elements de vídeo, un mecanisme mitjançant el com es permeta controlar als usuaris la reproducció dels mateixos (avanç, pausa, etc.). A més, este mecanisme, s'haurà de poder manejar des de qualsevol tipus de de dispositiu (teclat, ratolí, etc.)
En cas que el contingut multimèdia s'emeta en directe l'únic requisit és que es proporcionen subtítols en temps real, a més d'evitar que es produïsquen centelleigs i parpellejos. No és necessari proporcionar una transcripció textual completa ni descripció sonora. Encara així, per a facilitar l'accés a aquest contingut es recomana proporcionar a posteriori una versió gravada amb totes les mesures d'accessibilitat necessàries.
Per a ampliar informació sobre els vídeos es pot consultar la “Guia d'Accessibilitat per a Contingut Multimèdia” disponible en l'apartat "Guies Pràctiques" de l'àrea de documentació .
Qualsevol objecte Flaix ha d'estar dissenyat sobre la base dels criteris comuns d'accessibilitat: ús adequat del color, independència de dispositiu, navegació coherent, llenguatge clar i senzill, control de detecció del moviment, no ocupació de de centelleigs i en general, tots aquells aspectes arreplegats en les WCAG que pogueren ser aplicats sobre la interfície i funcionalitat d'este tipus de continguts. Han d'emprar-se tècniques i ferramentes com el panell d'accessibilitat (incorporat des de la versió 6.0 i millorat en les versions successives) del programari de desenvolupament d'Adobe Flash. Els elements d'interacció de l'objecte han de permetre una tabulació ordenada (d'acord amb la disposició en pantalla) i qualsevol informació important de l'objecte ha de ser interpretada adequadament per un lector de pantalla.
Al mateix temps, i a causa que no des de tots els agents d'usuari podrà accedir-se de forma completa a este tipus d'objectes (per incompatibilitats amb el motor MSAA (Microsoft Active Accessibility), ha de proporcionar-se una alternativa equivalent en (x)HTML+CSS. Aquesta alternativa haurà d'incloure's entre les etiquetes OBJECT del Flaix, i complementàriament contextualitzada en el propi document (acompanyant a l'objecte però independent d'este) o en un vincle a un document independent.
Si l'objecte Flaix és merament decoratiu (no oferix informació textual, no oferix funcionalitat i només s'empra com a acompanyament visual) no és necessari proporcionar alternativa al mateix.
Independentment de si l'objecte Flaix és decoratiu o si disposa d'una alternativa accessible, este no ha d'interferir o dificultar l'accés a la resta de continguts de la pàgina a les persones amb discapacitat. Així, no podrà tindre centelleigs que puguen provocar atacs a persones amb epilèpsia fotosensitiva, no podrà bloquejar o interrumplir la navegació amb teclat per la resta de continguts i haurà de disposar de mecanismes per a controlar la reproducció de l'àudio i pausar o detindre els moviments i animacions.
Finalment, per a incrustar un element Flaix en un document, és recomanable emprar un codi (X)HTML vàlid segons les gramàtiques publicades per W3C: és comú l'ocupació d'atributs i elements desaconsellats com EMBED, generats per la pròpia ferramenta de desenvolupament. En el seu lloc, hauria d'emprar-se un codi igualment funcional i tolerant amb les gramàtiques W3C.
Exemple de codi
L'evolució de les tècniques CAPTCHA ha posat de manifest que les solucions tradicionals, com els caràcters continguts en imatges, no solament són insegurs, si no que també dificulten la interacció amb persones amb algun tipus de discapacitat. En l'actualitat, desenvolupaments recents com Google reCAPTCHA, l'autenticació multidispositivo i sistemes de federació d'identitats constituïxen la millor forma de distingir a un humà d'una màquina.
No obstant açò, encara que hi ha algunes solucions CAPTCHA millor que unes altres, no existix encara la solució ideal. El que sí és important és que el CAPTCHA inclòs en el lloc web siga capaç d'identificar correctament a persones amb discapacitats com a humans.
El grup de treball Accessible Platform Architectures (APA)
, amb la col·laboració de Research Questions Task Force (RQTF) , ha elaborat l'esborrany " Inaccessibility of CAPTCHA ". Esta publicació data del 2005, encara que està sent contínuament revisada amb l'objectiu d'incloure els últims canvis tecnològics en la matèria.
En este document s'analitzen els diferents enfocaments de CAPTCHA existents, juntament amb les seues barreres d'accessibilitat associades. També s'inclouen referències a les investigacions més recents sobre esta temàtica, a més d'abordar els sistemes de federació d'identitats, autenticació de doble factor, biomètrica, CAPTCHA 3D, etc.
Este document servix d'ajuda per a donar compliment als requisits arreplegats en el criteri de conformitat 1.1.1 Contingut no textual de les WCAG 2.0 i 2.1.
