accesskey_mod_content

Imatges, multimèdia i CAPTCHA

Per a cada imatge complexa s'ha de proporcionar una descripció detallada en un document HTML aparti o en el mateix en el qual es troba aquesta imatge.

En HTML 4.01 o XHTML la URL d'aquesta descripció detallada s'indicarà en l'atribut longdesc de la imatge. Addicionalment, i per 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í, segueix sent necessari oferir per a cada imatge una alternativa textual en l'atribut alt que identifiqui breument el tipus d'informació transmesa a través del mateix.

Exemple de codi

Text identificatiu de la imatge complexa

Descripció de [nom de la imatge]

En canvi, en HTML5 l'atribut longdesc passa a considerar-se com a obsolet. En aquest cas, la forma d'incloure una descripció detallada és incloent aquesta descripció a la mateixa pàgina o en una pàgina aparti 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 posseeix funcionalitat alguna. Pensant en una pàgina Web concreta, això significaria que en mancar d'aquestes 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è sigui 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 posseeixin 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 transmeti 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 produeixin parpellejos i centelleigs.
  • Control de la reproducció: És també important proporcionar als elements de vídeo, un mecanisme mitjançant el com es permeti controlar als usuaris la reproducció dels mateixos (avanç, pausa, etc.). A més, aquest mecanisme, s'haurà de poder manejar des de qualsevol tipus de de dispositiu (teclat, ratolí, etc.)

En cas que el contingut multimèdia s'emeti en directe l'únic requisit és que es proporcionin subtítols en temps real, a més d'evitar que es produeixin centelleigs i parpellejos. No és necessari proporcionar una transcripció textual completa ni descripció sonora. Encara així, per facilitar l'accés a aquest contingut es recomana proporcionar a posteriori una versió gravada amb totes les mesures d'accessibilitat necessàries.

Per ampliar informació sobre els vídeos es pot consultar la “Guia d'Accessibilitat per a Contingut Multimèdia” disponible a 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 recollits en les WCAG que poguessin ser aplicats sobre la interfície i funcionalitat d'aquest tipus de continguts. Han d'emprar-se tècniques i eines 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 aquest tipus d'objectes (per incompatibilitats amb el motor MSAA (Microsoft Activi 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'aquest) o en un vincle a un document independent.

Si l'objecte Flaix és merament decoratiu (no ofereix informació textual, no ofereix 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, aquest 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à tenir centelleigs que puguin 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 controlar la reproducció de l'àudio i pausar o detenir els moviments i animacions.

Finalment, per 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 eina de desenvolupament. En el seu lloc, hauria d'emprar-se un codi igualment funcional i tolerant amb les gramàtiques W3C.

Exemple de codi

 







    

 
        Alternativa equivalent
    


 

 

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 constitueixen la millor forma de distingir a un humà d'una màquina.

No obstant això, encara que hi ha algunes solucions CAPTCHA millor que unes altres, no existeix encara la solució ideal. El que sí és important és que el CAPTCHA inclòs en el lloc web sigui capaç d'identificar correctament a persones amb discapacitats com a humans.

El grup de treball Accessible Platform Architectures (APA)(Obre en nova finestra) , amb la col·laboració de Research Questions Task Force (RQTF)(Obre en nova finestra) , ha elaborat l'esborrany " Inaccessibility of CAPTCHA(Obre en nova finestra) ". Aquesta 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 aquest document s'analitzen els diferents enfocaments de CAPTCHA existents, juntament amb les seves barreres d'accessibilitat associades. També s'inclouen referències a les recerques més recents sobre aquesta temàtica, a més d'abordar els sistemes de federació d'identitats, autenticació de doble factor, biomètrica, CAPTCHA 3D, etc.

Aquest document serveix d'ajuda per donar compliment als requisits recollits en el criteri de conformitat 1.1.1 Contingut no textual de les WCAG 2.0 i 2.1.

Subscriu-te al canal de youtube de l'OBSAE
Subscriu-te al canal de youtube de l'OBSAE