INTRODUCCIÓN A LA ACCESIBILIDAD WEB Y APLICACIÓN CON GESTOR DE CONTENIDOS IGES Año 2016.
Autor: RAÚL SOTO ARAGÓN
Los contenidos de este manual están bajo una licencia Creative Commons de tipo Reconocimiento No Comercial Sin Obra Derivada. Se permite su copia y distribución por cualquier medio siempre que mantenga el reconocimiento de sus autores, no haga uso comercial de las obras y no realice ninguna modificación de ellas.
2016 Introducción a la Accesibilidad Web y Aplicación con Gestor de Contenidos IGES
INTRODUCCIÓN A LA ACCESIBILIDAD WEB Y APLICACIÓN CON GESTOR DE CONTENIDOS IGES . 4 Presentación del Manual .............................................................................................................. 4 Introducción y objetivos ................................................................................................................ 4 Introducción a la accesibilidad web. ......................................................................................... 4 Concepto de discapacidad .................................................................................................... 4 Concepto de accesibilidad web ............................................................................................. 4 Objetivo y Referentes................................................................................................................ 5 Razones para abordar. .............................................................................................................. 7 Oportunidad única para abordarlo ....................................................................................... 7 Amplio colectivo al que va dirigido ....................................................................................... 7 Discapacidad por circunstancias ........................................................................................... 7 Envejecimiento de la población ............................................................................................ 8 Facilitar el acceso desde dispositivos heterogéneos ............................................................ 9 Marco legal en España .......................................................................................................... 9 Norma UNE139803:2012, Ley 26/2011 y RD. 1276/2011 ............................................... 10 Leyes Estatales ................................................................................................................ 11 Reales decretos de desarrollo de la Ley 51/2003 (LIONDAU) ......................................... 11 Infracciones y sanciones.................................................................................................. 12 Referencias. ..................................................................................................................... 13 Situación: Problemas y soluciones .............................................................................................. 13 Problemática en portales dinámicos. ...................................................................................... 13 Problemática de los autores ............................................................................................... 13 Descentralización de la publicación. ............................................................................... 13 Problema de las herramientas de edición........................................................................... 14 Problemas organizativos y de gestión ................................................................................. 16 Coste.................................................................................................................................... 16 Plan de acción y estrategia general......................................................................................... 16 Estrategias y acciones ......................................................................................................... 16 Filosofía de la estrategia ..................................................................................................... 17 Acciones a realizar. .................................................................................................................. 17 Documento base y detección de fuentes de errores .......................................................... 17 Medidas organizativas......................................................................................................... 18
1 de 74
Definición de un método normalizado de revisión. ................................................................ 19 Definición de un workflow básico de publicación ................................................................... 20 Procedimiento ante problemas y buenas prácticas en herramientas .................................... 21 Construcción del gestor, componentes de aplicación y migración ..................................... 22 Normas de diseño del portal ................................................................................................... 23 Cumpliendo la accesibilidad ........................................................................................................ 24 Accesibilidad. WCAG 2.O ......................................................................................................... 24 Introducción (Legislación y antecedentes históricos) ......................................................... 24 Pautas de Accesibilidad para el Contenido Web (WCAG 2.0) ............................................. 25 Estructura y organización de las Pautas WCAG 2.0 ........................................................ 25 PRINCIPIO 1: Perceptible ................................................................................................. 26 PRINCIPIO 2: Operable .................................................................................................... 30 PRINCIPIO 3: Comprensible ............................................................................................. 34 PRINCIPIO 4: Robusto ...................................................................................................... 36 Niveles de Conformidad con WCAG 2.0 .......................................................................... 38 Diferencias generales con WCAG 1.0 .............................................................................. 40 Como afecta WCAG 2.0 a elementos concretos y tecnologías específicas. Aspectos generales. ............................................................................................................................ 42 Imágenes y mapas de imagen ......................................................................................... 42 Multimedia (audio, vídeo, presentaciones) .................................................................... 42 Objetos programados (JavaScript y otros) ...................................................................... 42 Maquetación y presentación .......................................................................................... 43 Encabezados, listas, citas y otros bloques de texto ........................................................ 43 Idiomas y comprensión del lenguaje............................................................................... 44 Tablas de datos................................................................................................................ 44 Marcos ............................................................................................................................. 45 Formularios ..................................................................................................................... 45 Mecanismos de navegación ............................................................................................ 46 Metadatos ....................................................................................................................... 48 Documentos PDF ............................................................................................................. 48 Documentos Word .......................................................................................................... 49 Adobe Flash ..................................................................................................................... 51 Herramientas y métodos de validación de accesibilidad Web ........................................... 53
2 de 74
Chequeo del contraste del color ..................................................................................... 54 Recomendación tras evaluación ..................................................................................... 55 Resultado y beneficios. ........................................................................................................... 55 Mejora continua. ..................................................................................................................... 56 El gestor de contenidos IGES ................................................................................................... 56 ¿Qué es un CMS? ................................................................................................................ 56 Contenido Archivo ............................................................................................................... 57 Contenido imagen ............................................................................................................... 64 Contenido simples ............................................................................................................... 65 Otros contenidos y Plantillas ............................................................................................... 70 Multiportales ....................................................................................................................... 71 Referencias y bibliografía ........................................................................................................ 71 Glosario de Términos .............................................................................................................. 71
3 de 74
INTRODUCCIÓN A LA ACCESIBILIDAD WEB Y APLICACIÓN CON GESTOR DE CONTENIDOS IGES Presentación del Manual Para la Escuela de Formación e Innovación de la Administración Pública, es esencial que los alumnos dispongan de manuales cuyos contenidos respondan a sus necesidades de formación. Estos manuales deben poseer una organización y estructura que se adecue a las condiciones de aprendizaje de las personas adultas, con una metodología apropiada para este tipo de formación. El manual que presentamos es fruto del esfuerzo de varios profesionales que trabajan con la Escuela de Administración Pública en diversas materias, expertos en adaptar los contenidos al diseño del curso y a la didáctica del mismo. Nuestro principal objetivo es que sea un apoyo esencial en la adquisición de conocimientos, no solo durante la realización del curso, sino que, una vez finalizada la acción formativa, sirva de consulta y resolución de dudas en el desarrollo del trabajo. Lo que pretendemos es ofrecer materiales con calidad, con unos contenidos que respondan a las expectativas formativas de la administración regional, y que, evidentemente, pueden y deben ser mejorados por quienes de una u otra manera participan en los planes de formación de la Escuela de Administración Pública. Asimismo, deseamos que los materiales proporcionados sean el reflejo del trabajo y el buen hacer de todas las personas que contribuyen a la mejora de la calidad de la formación.
Introducción y objetivos Introducción a la accesibilidad web. Concepto de discapacidad Discapacidad: Una diferencia individual que supera un límite más o menos arbitrario. Según la RAE, discapacitado es: “la persona que tiene impedida o entorpecida alguna de las actividades cotidianas consideradas normales, por alteración de sus funciones intelectuales o físicas” Aunque para ser considerado discapacitado la limitación debe superar un umbral establecido algunas de estas limitaciones se encuentran también en otras personas de distinto grado. La discapacidad puede ser: física, intelectual o técnica. Concepto de accesibilidad web La accesibilidad web se refiere a la capacidad de acceso a la Web y a sus contenidos por todas las personas independientemente de su discapacidad o de las que se deriven del contexto de uso (tecnológicas o ambientales). Más específicamente, significa que la gente con discapacidad pueda percibir, entender, navegar e interactuar con la web, y que puedan contribuir. 4 de 74
Esta cualidad está íntimamente relacionada con la usabilidad. Iniciativa WAI de la W3C: (http://www.w3.org/WAI/) Accesibilidad ¿Puedo acceder o no?
Usabilidad ¿Es fácil y cómodo de acceder?
A continuación mostramos un ejemplo de cómo se desenvuelve una persona ciega estudiante de ciencias empresariales de la UNED en un sistema informático. Esta persona instala un lector de pantalla, JAWS. También muestra como maneja el Word y realiza búsquedas en Google. El video también muestra una línea braille y un lector de mensajes de telefonía móvil.
Imagen de un video de youtube sobre una persona ciega usando un sistema informático con un lector de pantalla. Dirección del video: https://www.youtube.com/watch?v=KZDo-J0lya4
Para personas con alguna discapacidad visual el uso del zoon en navegadores como Google Chrome e Internet Explorer recordamos que se realiza con las teclas CTRL + “+” y CTRL + “-“
Objetivo y Referentes Usabilidad universal El objetivo general es alcanzar la “usabilidad universal”, de forma que no sirvan de obstáculo las distintas limitaciones que puedan tener los usuarios. Lograr alcanzar el mayor número de usuarios posible. Para conseguir este objetivo, es obvio que habrá que construir la web teniendo en cuenta las diferentes tipologías de dificultades en el acceso.
5 de 74
Facilitar y simplificar el acceso a toda la información albergada en los portales. El objetivo debe ser el nivel AA En cuanto a la accesibilidad y usabilidad nos marcaremos como objetivo el Nivel doble-A de conformidad con las directrices de accesibilidad para el Contenido Web 2.0 (WCAG 2.0) a corto plazo, sin perder de vista a medio-largo plazo aquellas pautas interesantes del nivel triple-A. Referencias
W3C (World Wide Web http://www.w3.org/WAI/
Consortium)
-
WAI
(Web
Accessibility
Initiative)
Iniciativa para la accesibilidad Web.
Discapnet. http://www.discapnet.es
Portal que parte de la iniciativa para fomentar la integración social y laboral de las personas con discapacidad, cofinanciada por Fundación ONCE y Technosite.
SIDAR. http://www.sidar.org/
La "Fundación Sidar - Acceso Universal" Vela por conseguir que la Sociedad de la Información, en toda Iberoamérica, sea accesible e inclusiva. La Fundación tiene como principal objetivo la realización de estudios y actividades orientadas al desarrollo de acciones de investigación, formación, promoción, asesoría y todas aquellas que faciliten el desarrollo de la Sociedad de la Información de forma accesible e inclusiva.
Herramientas, wizards, artículos y tutorialess sobre accesibilidad en la web para desarrolladores web concienciados. http://accessify.com/
Web Accessibility Email Discussion Forum
Pregunta a los expertos. Los miembros de esta lista pueden ser capaces de responder a tus cuestiones sobre accesibilidad web. http://webaim.org/discussion/
Accesibilidad en Microsoft.
6 de 74
Productos y recursos, tecnología de asistencia, tutoriales detallados, guías clasificadas por discapacidades, beneficios empresariales, "case studies" y artículos, etc. http://www.microsoft.com/spain/accesibilidad/
Razones para abordar. En esta sección se describirán una serie de puntos relacionados con la motivación que nos va a llevar a abordar el problema de la accesibilidad. Oportunidad única para abordarlo Debemos de concienciarnos con el tema de la accesibilidad y sus distintos actores implicados en el problema. Hay que contemplar las diferencias entre personas. Cualquier sistema, y en particular los sitios web, deben tener en cuenta que el acceso no será realizado por una “persona ideal”, es decir, que se deberán tener en cuenta las limitaciones de cada uno para no limitar el acceso de diferentes colectivos de personas. Un buen uso de la web puede ofrecer a personas con discapacidad la posibilidad de acceder a relaciones sociales, servicios, opciones laborales, información, etc., que hasta ahora no tenía precedentes, sin embargo, un mal enfoque de la web, puede contribuir aún más a aumentar las dificultades que todos estos individuos tienen. El objetivo último de la administración debe llegar a todo el espectro social y a todos los colectivos, sin marginar a nadie, en cualquier iniciativa que tome y la web no puede ser una excepción. Amplio colectivo al que va dirigido Existe un Numero Personas que presenta alguna discapacidad. Es un colectivo numeroso. Hay que tener en cuenta que el colectivo de personas con discapacidad es bastante elevado, en España con los datos del 2008 del INE (Instituto Nacional de Estadísticas) son más de tres millones ochocientas mil de personas que presenta un 8,5% de la población y en Estados Unidos, Microsoft estima que 1 de cada cinco estadounidenses tienen algún problema de accesibilidad (datos del año 2000). Mucha gente, estaría de acuerdo en la necesidad de no ofrecer barreras a las personas con discapacidad, pero por otro lado tiene la percepción de que no merece la pena abordar el problema de la accesibilidad ya que el porcentaje de la población al que afecta es muy pequeño y como se ha comentado anteriormente; El porcentaje de la población es bastante elevado y existe un crecimiento actual de las tecnologías que afectará cada vez más por el uso; Esto está relacionado sobre todo con el envejecimiento de la población. Discapacidad por circunstancias Cualquier persona puede ser un “discapacitado” bajo determinadas circunstancias. La accesibilidad puede favorecer el acceso a personas que no son consideradas oficialmente un discapacitado, por ejemplo una persona mientras conduce no podrá prestar atención a la
7 de 74
pantalla, si está en una biblioteca no podrá activar el sonido, si está conduciendo no podrá tampoco manipular un ratón, etc. Algunas situaciones que pueden convertir a cualquier persona en un discapacitado son: Relacionados con la discapacidad visual:
Una persona mientras conduce no podrá prestar atención a una pantalla. Cuando haya muchos reflejos en la pantalla pueden disminuir nuestra visión. En una situación de oscuridad forzada. Personas sin gafas.
Relacionados con la discapacidad auditiva:
Dispositivos sin sonido. Mucho ruido en el ambiente. Bibliotecas en las que el silencio es forzado.
Relacionados con la discapacidad en la manipulación:
Conducción. Una persona con guantes para trabajo. En un barco balanceándose.
Relacionados con la discapacidad cognoscitiva:
Desconocimiento de idioma. Bajo la influencia del alcohol
Estos son sólo algunos ejemplos, pero se puede pensar en muchas más situaciones en las que cualquier persona puede presentar alguna limitación en sus capacidades. Envejecimiento de la población De todos es sabido que la población, en particular en España, y en general en todo el mundo está envejeciendo. Como es natural, cuanto mayor es una persona, mayor es el número de limitaciones funcionales que tiene. De lo cual se deduce que el colectivo de personas con discapacidad va en aumento. Por otro lado, la edad media de la población laboral cada vez es mayor en los países desarrollados. Además, en algunos países como en España, se está alargando la edad de jubilación (en España ahora es hasta los 67 años). Por tanto, la demanda de tecnologías y productos que sean accesibles cada vez será mayor, ya que la población que los necesita está en aumento. España continúa su proceso de envejecimiento. A 1 de enero de 2014 hay 8.442.427 personas mayores de 65 años, el 18,1% sobre el total de la población (46.771.341), según los datos del Padrón Continuo (INE).
8 de 74
Facilitar el acceso desde dispositivos heterogéneos Cuando una web es accesible se facilita el acceso además de mediante los distintos navegadores web, mediante otros dispositivos que utilizan un único sentido para el acceso: como puede ser acceso visual, auditivo, etc., u otros dispositivos con menor funcionalidad que un ordenador como un teléfono móvil, una televisión, frigoríficos que ejecutan las compras según se van vaciando, etc. Estos dispositivos pueden tener una menor capacidad de presentación y una menor disponibilidad de dispositivos de entrada. Marco legal en España El año 2007 fue sin duda el gran año para la Accesibilidad Web en España, puesto que se aprobaron diversas leyes de vital importancia para la accesibilidad de los portales de Internet, leyes que todos debemos conocer: Real Decreto 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las Condiciones Básicas para el Acceso de las Personas con Discapacidad a las Tecnologías, Productos y Servicios Relacionados con la Sociedad de la Información y Medios de Comunicación Social. http://www.boe.es/buscar/doc.php?id=BOE-A-2007-19968 Ley 11/2007, de 22 de junio. Acceso electrónico de los ciudadanos a los Servicios Públicos. (BOE de 23-6-07) http://noticias.juridicas.com/base_datos/Admin/l11-2007.html Ley 27/2007, de 23 de octubre, por las que se reconocen las lenguas de signos españolas y se regulan los medios de apoyo a la comunicación oral de las personas sordas, con discapacidad auditiva y sordociegas. http://www.boe.es/boe/dias/2007/10/24/pdfs/A43251-43259.pdf Ley 49/2007, de 26 de diciembre, por la que se establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad. http://www.boe.es/boe/dias/2007/12/27/pdfs/A53278-53284.pdf Sustituida por el Real Decreto Legislativo 1/2013, de 29 de noviembre, por el que se aprueba el Texto Refundido de la Ley General de derechos de las personas con discapacidad y de su inclusión social. http://www.boe.es/boe/dias/2013/12/03/pdfs/BOE-A-2013-12632.pdf Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información (LISI) http://www.boe.es/buscar/doc.php?id=BOE-A-2007-22440
9 de 74
Norma UNE139803:2012, Ley 26/2011 y RD. 1276/2011 Estas leyes fijan por fin el nivel de adecuación obligatorio de los portales de Internet, no ya sólo de la Administración Pública sino de las empresas que reciben financiación pública y de las empresas privadas con más de 100 trabajadores o que facturen más de 6 millones de euros (especialmente entidades bancarias, agencias de viaje, aseguradoras, empresas de transporte, suministradoras de electricidad, gas y agua, etc.) en el nivel de conformidad AA de la Norma UNE 139803. A través del Portal de Administración Electrónica puede obtenerse gratuitamente esta norma actualizada en 2012 que es de inmensa utilidad para los sitios web de las Administraciones Públicas. La Norma UNE 139803:2012: Requisitos de Accesibilidad para contenidos en la web, es una norma española de reciente aprobación (julio de 2012) que establece los requisitos de accesibilidad para los contenidos web. En cuanto a sus requisitos, referencia completamente a las Pautas de Accesibilidad para el contenido web WCAG 2.0 de la Iniciativa para la Accesibilidad Web (WAI) del Consorcio de la Web (W3C) por lo tanto hay una equivalencia directa entre ellas. En esta se abordan temas como la certificación de los portales; las sanciones por incumplimiento de las obligaciones de accesibilidad; el derecho de las personas sordas, con discapacidad auditiva y sordociegas a que el contenido de los portales esté disponible en la lengua de signos (equiparada a cualquier otra lengua del Estado); el derecho a que los procesos, procedimientos y dispositivos de firma electrónica sean plenamente accesibles, etc. La Secretaría de Estado de Administraciones Públicas, como parte de su iniciativa del Observatorio de Accesibilidad Web, ha suscrito un acuerdo con AENOR para la distribución gratuita de esta norma a través del Portal de Administración Electrónica. El conocimiento público y gratuito de esta norma pretende incidir positivamente en la implantación de estos nuevos requisitos de accesibilidad, especialmente en los portales web de las Administraciones Públicas. La descarga gratuita de la Norma UNE 139803:2012 puede realizarse desde: http://administracionelectronica.gob.es/PAe/accesibilidad/normativa
Una de las últimas leyes importantes en relación con la accesibilidad web es la Ley 26/2011, de 1 de agosto, de adaptación normativa a la Convención Internacional sobre los Derechos de las Personas con Discapacidad que entre otras cosas obliga a que las redes sociales (desarrolladas por entidades cuyo volumen anual de operaciones sean mayor a 6 millones de euros) sean accesibles antes de 2013; amplía la exigencia de accesibilidad a los instrumentos de cooperación internacional; y se reconoce el derecho a indemnización por daños y perjuicios en caso de discriminación. http://www.boe.es/boe/dias/2011/08/02/pdfs/BOE-A-2011-13241.pdf
10 de 74
El Real Decreto 1276/2011, de 16 de septiembre adecua la regulación reglamentaria vigente en materia de discapacidad a las directrices de la Convención, en la línea marcada por la Ley 26/2011. http://www.boe.es/diario_boe/txt.php?id=BOE-A-2011-14812 Leyes Estatales LEY 34/2002. La Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico regula determinados aspectos jurídicos de los Servicios de la Sociedad de la Información. (LSSI) https://www.boe.es/buscar/doc.php?id=BOE-A-2002-13758 Existe un portal sobre esta ley: http://www.lssi.gob.es/ Ley 32/2003, de 3 de noviembre, General de Telecomunicaciones. (BOE de 4-11-03) http://noticias.juridicas.com/base_datos/Admin/l32-2003.html Ley 51/2003, de 2 diciembre, de Igualdad de Oportunidades, no Discriminación y Accesibilidad Universal de las Personas con Discapacidad (LIONDAU) (B.O.E. de 3-12-03). http://www.boe.es/boe/dias/2003/12/03/pdfs/A43187-43195.pdf Reales decretos de desarrollo de la Ley 51/2003 (LIONDAU) Real Decreto 424/2005, de 15 de abril. Reglamento sobre condiciones para la prestación de servicios de comunicaciones electrónicas y servicio universal. (BOE de 29-4-05). Modificado por el Real Decreto 1494/2007, de 12 de noviembre. Ver Artículo 32.4 y Artículo 33 ("Otras medidas para facilitar la accesibilidad al servicio por las personas con discapacidad") Real Decreto 1414/2006, de 1 de diciembre, por el que se determina la Consideración de Persona con Discapacidad a los efectos de la Ley 51/2003 de Igualdad de Oportunidades, no Discriminación y Accesibilidad Universal de las Personas con Discapacidad (BOE de 16 de diciembre de 2006). Real Decreto 1417/2006, de 1 de diciembre, por el que se establece el Sistema Arbitral para la Resolución de Quejas y Reclamaciones en Materia de Igualdad de Oportunidades, no Discriminación y Accesibilidad por Razón de Discapacidad. (BOE de 13 de diciembre de 2006). Real Decreto 366/2007, de 16 de marzo, por el que se establecen las Condiciones de Accesibilidad y no Discriminación de las Personas con Discapacidad en sus Relaciones con la Administración General del Estado. (BOE de 24 de marzo de 2007). En el artículo 12 se especifica: los documentos e impresos deberán estar en todo caso disponibles en las correspondientes páginas web y en formato electrónico accesible, por tanto los documentos e impresos en formatos como Word o PDF deberán ser accesibles.
11 de 74
Real Decreto 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las Condiciones Básicas para el Acceso de las Personas con Discapacidad a las Tecnologías, Productos y Servicios Relacionados con la Sociedad de la Información y Medios de Comunicación Social.(BOE de 21 de noviembre de 2007) Infracciones y sanciones. Nombradas algunas leyes que hacen referencia a las infracciones y sanciones veamos algunos datos interesantes: Informe del año 2010 aparecen las siguientes denuncias en materia de accesibilidad web:
Expediente 15/10: Denuncia la Web de Transportes Metropolitanos de Barcelona por ausencia de accesibilidad. Expediente 16/10: Denuncia la Web del Corte Inglés por ausencia de accesibilidad. Expediente 17/10: Denuncia la página Web de AGBAR por ausencia de accesibilidad. Expediente 158/10: Queja por ausencia de accesibilidad página Web Openbank. Expediente 213/10: Denuncia página Web de Iberia por no observar nivel medio de accesibilidad. Expediente 214/10: Denuncia página Web de Corporación RTVE por no observar nivel medio de accesibilidad. Expediente 215/10: Denuncia página Web de Corporación Endesa por no cumplir nivel medio de accesibilidad. Expediente 216/10: Denuncia página Web del Grupo Gas Natural por no observar nivel medio de accesibilidad. Expediente 217/10: Denuncia página Web de Jazztel por no observar nivel medio de accesibilidad. Expediente 218/10: Denuncia página Web de ORANGE por no ser accesible. Expediente 219/10: Denuncia página Web de Corporación RTVE por no observar nivel medio de accesibilidad. Expediente 220/10: Denuncia página Web de Grupo Santander por no observar nivel medio de accesibilidad. Expediente 221/10: Denuncia página Web de Grupo Avanza por no obtener nivel medio de accesibilidad. Sergio Luján: http://accesibilidadenlaweb.blogspot.com.es/2012/01/quien-denunciar-la-falta-de.html
Datos más recientes (2015):
Sanidad sanciona a Iberia con 30.001 euros por inaccesibilidad de su página corporativa de Internet (31/07/2015) http://www.cermi.es/esES/Noticias/Paginas/Inicio.aspx?TSMEIdNot=6874 El CERMI denuncia ante el Defensor del Pueblo y el Consejo Nacional de la Discapacidad la falta de accesibilidad del portal de transparencia del Gobierno. http://semanal.cermi.es/noticia/CERMI-denuncia-web-transparencia-Gobiernoaccesibilidad.aspx
12 de 74
El CERMI presenta una queja ante la Defensora del Pueblo por la falta de accesibilidad de la web de cita previa del DNI http://www.telecinco.es/informativos/sociedad/CERMI-Defensora-Puebloaccesibilidad-DNI_0_1967175280.html
Referencias. Video tutorial sobre Accesibilidad web: Legislación en España por Sergio Luján Mora de la Universidad de Alicante.
Imagen del video tutorial sobre accesibilidad web: Legislación en España por Sergio Luján. Universidad de Alicante. http://www.youtube.com/watch?v=6fAg6BVBHck
Situación: Problemas y soluciones Problemática en portales dinámicos. Problemática de los autores Hoy en día pocos son los portales que albergan páginas estáticas, si no que suelen construirse mediante gestores de contenidos de publicación dinámica, lo que plantea una serie de problemas con respecto a la accesibilidad. Es importante conocer las causas potenciales de problemas de accesibilidad para trabajar en soluciones específicas de cada una de ellas. En este apartado se darán unas líneas generales de principales causas, pero, como es natural habrá que hacer un estudio personalizado de cada portal. Descentralización de la publicación. En este tipo de portales la publicación de contenidos está totalmente descentralizada, no siendo personal informático ni personal especializado en la web quien publica la información, sino que, el personal de la organización donde se genera la información es el responsable de distribuirla a través de todos los canales, lo que incluye también el canal web. De esta forma la web está mucho más viva y se agilizan los procesos de publicación. Los autores de los contenidos en muchos casos no están familiarizados con la problemática de la accesibilidad.
13 de 74
Además, en algunas ocasiones esos autores no tienen la cultura web suficiente, no conocen sus formatos (HTML, PDF, etc.) si no que se le facilitan herramientas que hacen posible la conversión a los formatos de la web. Problema de las herramientas de edición Los autores de la información, en algunos casos, utilizan herramientas para la edición de contenidos web como pueden ser Dreamweaver, Word, etc. Aunque algunas de ellas tienen opciones para generar código accesible, la realidad es que TODAS en mayor o menor medidas tienen problemas con las normas de accesibilidad (por ejemplo, utilizando atributos desaconsejados y por tanto prohibidos). Además, hay herramientas del tipo procesador de textos (p.ej. Word) que no tienen en cuenta en absoluto las consideraciones de accesibilidad, generando por tanto un código muy pobre en lo que respecta a la accesibilidad. El siguiente ejemplo por ejemplo:
Imagen de una instantánea del procesador de textos Word generando un documento HTML.
Devuelve el siguiente informe de error: Show/Hide Overview Overview Starting page: C:\Temp\Don Quijote de la Mancha.htm Started at: 2016/04/25 17:42:12 CEST Time taken: 2 seconds Validator Version: v10.2.2 Total pages checked: 1 Total links checked: 3 Total pages with problems: 1 Show/Hide Errors Total errors found: 6 Show/Hide Options Options
14 de 74
HTML validation: Auto Detect Accessibility: A2 Check for broken links: true Validation level: Only report errors top Show/Hide Results Results Upgrade to Total Validator Pro to validate an entire site in one go Click on the images or links below to view the results. For pages that validate you can display a logo. Display issue details:HoverShow allHide all C:\Temp\Don Quijote de la Mancha.htm 6 Errors: HTML (5), WCAG 2.0 A (1)
Estos problemas se trasladan al portal de contenidos cuando los autores introducen en el portal contenidos generados mediante estas herramientas o cuando utilizan la funcionalidad de pegar en editores del tipo WYSIWYG con código generado desde otras herramientas. Algunos componentes utilizados para el desarrollo de aplicaciones o gestores web, como por ejemplo, un editores visuales de HTML del tipo WYSIWYG (What You See Is What You Get), las plantillas utilizadas para la publicación de contenidos en el portal, los desarrollos, productos de terceros, etc.
Imagen del editor WYSIWYG que contiene el Gestor de contenidos IGES.
En componente que usa el Gestor de contenidos elimina gran parte de código innecesario de una forma automática aun viniendo de fuentes como la de Word. Pero a veces es imposible detectar algunos problemas.
15 de 74
Problemas organizativos y de gestión Los distintos roles de la organización implicada en el aseguramiento de la accesibilidad web, no suelen estar concienciados con el problema, ni formados, ni tienen a su disposición los recursos necesarios para llevar a cabo el trabajo. No suele existir una guía de procedimiento clara con respecto a la accesibilidad. Un elemento fundamental para asegurar la accesibilidad es disponer de una guía de procedimiento con respecto a la misma. Los controles de calidad no están suficientemente bien definidos y claros. No suele existir una estandarización de los controles de calidad con respecto a la accesibilidad. Las herramientas de gestión de contenidos no están bien diseñadas para el aseguramiento de la accesibilidad. Los gestores de contenidos, es decir, las herramientas utilizadas para realizar la publicación en la web en los distintos portales, no tienen por un lado en cuenta las normas de accesibilidad y por otro no tienen procesos específicos para el aseguramiento de la calidad con respecto a la accesibilidad. Coste Es un problema extremadamente complejo. Con respecto al coste de la implantación hay que decir eso sí, que es un problema extremadamente complejo por el cual, el grado de implantación de la accesibilidad se está complicando en general en los distintos portales web. Recursos invertidos. Para la consecución del objetivo de la accesibilidad, hay que hacer una inversión bastante alta tanto en recursos cuantitativos como pueden ser los recursos humanos o económicos, pero también hay que tener en cuenta recursos no tan fácilmente medibles como el impacto en la organización.
Plan de acción y estrategia general. Estrategias y acciones Estrategias generales, tecnológicas, organizativas, de gestión y de gestión del conocimiento. El problema de la accesibilidad hay que abordarlo a varios niveles: hay que definir una serie de estrategias generales (líneas maestras), a nivel tecnológico (de selección de herramientas, pautas de desarrollo, etc.), organizativas (concienciación, formación, creación de nuevos roles, etc.), de gestión (establecimiento de protocolos de actuación) y de gestión del conocimiento (documentación, distribución, acceso, etc.). ¿A quién afecta la estrategia?
16 de 74
Afectará a gran parte de los roles de la organización en mayor o menor medida, la estrategia se debe definir de forma que se redefinan los métodos de trabajo de autores de contenidos en la web, supervisores o revisores de calidad, desarrolladores de herramientas para la web, y en general a todo el personal implicado en la web. Acciones a realizar. Se definirán políticas o líneas maestras, se realizarán campañas de concienciación a los diversos roles implicados en la web, acciones formativas, creación de documentación como guías de buenas prácticas, manuales de procedimiento, etc., selección de herramientas del mercado que faciliten la tarea de la construcción de webs/contenidos accesibles ya sean automáticas o manuales y redefinición de métodos de trabajo. Filosofía de la estrategia De todos los roles que intervienen en el proceso de publicación el rol clave es el autor y será sobre el que habrá que concentrar los mayores esfuerzos para conseguir una web accesible. Es muy importante crear los contenidos directamente accesibles, ya que crear el código “inaccesible” para en etapas posteriores de la publicación editarlo y subsanar los errores de accesibilidad puede tener un coste muy elevado de recursos, económico, y supondría una carga muy pesada para revisores y validadores. Por ello, en la medida de lo posible, hay que hacer que los autores generen contenidos accesibles directamente desde sus orígenes, para lo cual hay que realizar una concienciación a los mismos de su responsabilidad en el proceso de publicación. Por ejemplo, si los autores generan mediante herramientas externas código inaccesible, podría darse el caso de que el revisor tuviese que corregir el contenido, supongamos retocando 100 puntos en el mismo. Si el autor cae en la cuenta de que ha “olvidado” alguna sección en su documento, volverá a generar el mismo con su herramienta “inaccesible” modificando la versión introducida en la web y provocará que el revisor tenga que corregir nuevamente esos 100 puntos que anteriormente corrigió. Además de la concienciación hay que facilitarle herramientas, documentación y todos los recursos necesarios para llevar a cabo su labor.
Acciones a realizar. Documento base y detección de fuentes de errores Creación del documento maestro de accesibilidad. Lo primero que se debe hacer es crear un documento maestro, que, teniendo como referencia principal las directrices de la WAI, indicase qué criterios debía cumplir un determinado contenido web para cumplir con los requisitos fijados para la Accesibilidad. Normalmente, como si se fija como objetivo el Nivel Doble-A de Conformidad, se estructura el documento en torno a este fin. Este documento es muy importante para esta o cualquier otra iniciativa. Antes de empezar a trabajar, documentar todos tus pasos, referencia a cualquier otro documento relacionado con
17 de 74
este tema, establece líneas, y en general, abarca todos los aspectos mencionados y alguno más. Identificación de fuentes de errores. Una vez generado el documento, lo siguiente que se debe hacer es identificar las principales fuentes de generación de código “no-accesible” que sirvan como base para un estudio de las acciones a tomar para subsanar cada una de estas fuentes de error. Es decir, debemos saber a qué nos enfrentamos para establecer acciones para abordar el problema. De las fuentes de error típicas, y quizás las más importantes, son los autores de los contenidos y las herramientas de portal utilizadas para realizar la publicación en la web. El desconocimiento de los formatos de la web y de las pautas de accesibilidad. Soluciones adoptadas en cada uno de los servicios:
Desarrollos a medida. Productos del mercado.
Todas pueden presentar en mayor o menor medida problemas de accesibilidad, por tanto, uno de los principales caballos de batalla del proyecto suele ser eliminar estos problemas de los autores y herramientas de portal que se utilicen. Estamos hablando de autores con falta de conocimiento de los formatos de la web y accesibilidad, pero otra fuente de error típica son, en los contenidos que los autores con conocimientos de HTML, introducen al escribir directamente su código HTML. Así mismo, cuando los autores utilizan herramientas, bien sean del tipo procesadores de textos como Word, o de propósito específico para la publicación en la web como Dreamweaver, etc., también introducen código inaccesible, en un alto grado en el caso de Word, y aunque en menor medida en el de Dreamweaver, tampoco están exentos (y varían según su utilización). Por último, otra fuente de inclusión de código inaccesible podían ser algunos componentes de aplicación utilizados en la construcción de herramientas de gestión de contenidos, como pueden componentes de edición visual de código HTML para que los autores puedan introducir contenidos sin conocer HTML aplicándoles algo de formato, por ejemplo, negrita, subrayado, inclusión de tablas, listas, etc. Estos componentes, también suelen tener problemas de accesibilidad en el código HTML que generan. Medidas organizativas Entre las medidas organizativas más importantes cabe destacar la creación de un grupo de calidad con respecto a la accesibilidad si la organización lo permite. Entre sus características cabe destacar:
Se trata del grupo responsable en última instancia del portal y por tanto de tomar las medidas necesarias para asegurar la accesibilidad. Se trata de un equipo multidisciplinar.
18 de 74
Es el depositario del conocimiento del sistema y por ende de todo lo relacionado con la accesibilidad en el mismo.
Sus principales funciones son:
Coordinación de todo el proceso de accesibilidad. Definición de estándares y procedimientos de trabajo encaminados a asegurar conformidad con el nivel doble-A de accesibilidad. Desarrollo, en el que deberá tener en cuenta las pautas de accesibilidad. Resolución de incidencias, en las que resolverá entre otras las relacionadas con accesibilidad. Formación, y por tanto el encargado de formar a los distintos roles implicados en publicación en la accesibilidad. Evaluación y supervisión de la calidad del portal, lo que incluye la evaluación de accesibilidad.
la
la la la
Creación de grupos en departamentos (para grandes corporaciones). Puede tratarse de un grupo o varios. Por ejemplo, en la CARM se propuso la creación de lo que se llama el GEWeb (grupo experto web que coordina las medidas y es el depositario del conocimiento del sistema y hace las funciones de revisor de calidad con respecto a la accesibilidad) y un grupo experto en cada consejería. Concienciación de usuarios. Para que el objetivo pueda ser cumplido es muy importante realizar campañas para que todos los roles implicados en la publicación de contenidos de la web tomen conciencia de la importancia de generar contenidos accesibles. Si los diversos usuarios implicados no toman conciencia será imposible alcanzar el objetivo de la accesibilidad. Para ello se han utilizado muchas de las razones expuestas en el apartado anterior de “Razones para abordar”. Igualmente es importante la formación de los mismos en la materia.
Definición de un método normalizado de revisión. Definición de un método de revisión. Otra de las tareas a realizar es la definición de un procedimiento de revisión, que defina claramente no sólo los distintos puntos de revisión, si no también, otros aspectos como cuándo revisar, cómo, con qué, etc. Identificación de formatos utilizados. Lo primero es identificar los formatos utilizados en nuestra web para tratarlos. Notar que lo más usual son las pautas para HTML y CSS, pero también se pueden aplicar a otros formatos como Word, PDF, etc. Utilización de Herramientas automáticas.
19 de 74
Para que el proceso sea lo más ágil posible, el procedimiento de revisión deberá apoyarse en herramientas automáticas que faciliten la tarea al cualquier persona que revisase la publicación. Para ello se deben evaluar las distintas herramientas existentes y realizar una selección (posteriormente haremos una recomendación) como por ejemplo TAW o Total Validator. ¿Cuándo realizar las revisiones? Mucha gente se queda en una revisión inicial cuando se aborda el proceso de “accesibilización” de una web. En ese instante el portal queda “más o menos” adaptado. El problema es que las webs están vivas, y hay que asegurar la accesibilidad posteriormente: cuando un contenido es modificado o uno nuevo es introducido, cuando los desarrolladores o diseñadores cambian una plantilla, hoja de estilos, componente de aplicación, etc., adicionalmente se deben definir revisiones con una cierta periodicidad para asegurar que algunas secciones clave (home, buscador, noticias, distintos tipos de contenido, etc.) y de la web en general. Sólo una inspección visual y del código puede decidir cuándo una página es accesible. Aunque las herramientas automáticas son muy útiles y serán de gran ayuda para nuestro fin, hay que notar que sólo una inspección visual y del código puede decidir a ciencia cierta cuando una página es accesible. Sistema de contacto para trasmitir dificultades. Es importante recoger el feed-back (además de obligado legalmente) de los usuarios. Por ello, se habilitará un mecanismo (dirección de correo electrónico, formulario de contacto, etc.) al que habrá que dotar de recursos, para que se transmitan las dificultades de acceso o se formulen quejas, consultas y sugerencias. Se complementará bien con “no encuentro lo que busco en la web”, de ahí se podrá analizar si hay secciones que existen en la web pero determinados colectivos no las están alcanzando (poniendo por ejemplo en el formulario si se tiene algún tipo de discapacidad).
Definición de un workflow básico de publicación Una de las acciones más interesantes es definir un circuito de publicación (workflow) en la herramienta gestor de contenidos de forma que se asegura la calidad en la publicación de los contenidos con respecto a la accesibilidad. Aunque el circuito de publicación pueda ser más complejo, es importante, de cara al aseguramiento de la calidad de la accesibilidad, que la revisión de accesibilidad se produzca después de la última modificación posible. El paso de supervisión de accesibilidad debe situarse como paso final cuando el autor introduzca un nuevo contenido en el sistema (o modifica uno ya existente). Aunque el autor está concienciado, y se le ha facilitado todo lo necesario para que genere contenidos accesibles, cuando el autor acabe su trabajo, el contenido pasará al estado de supervisión por parte del grupo de calidad con respecto a la accesibilidad, en el que el supervisor, comprobará que todo es correcto con respecto a la accesibilidad. En este punto, el supervisor de la
20 de 74
accesibilidad desde el gestor tendrá opción para lanzar automáticamente un validador de accesibilidad automático. En este paso tendrá dos opciones: bien corregir cualquier problema detectado, o, si lo considera oportuno, devolverá el contenido al autor indicando qué problemas de accesibilidad ha generado en el propósito de que sucesivos contenidos generados por ese autor no presenten los mismos problemas de accesibilidad. A continuación se realizarán las supervisiones que se estimen oportunas hasta llegar a la publicación.
Imagen que describe un sistema de flujos de trabajo.
Procedimiento ante problemas y buenas prácticas en herramientas Definición de un manual de procedimiento ante los principales problemas de accesibilidad. Se auditarán los problemas de accesibilidad que con mayor frecuencia se presenten en la web y se desarrollará un manual de procedimiento que ofrezca una guía del tipo “qué hacer ante el problema X”. De esta forma, los diversos roles implicados tienen una guía de referencia rápida para resolver los principales problemas encontrados. Esta guía estará desarrollada de forma que puede ser utilizada tanto por autores de contenidos como por validadores manuales, y ofrece también una pequeña guía para desarrolladores web de cómo subsanar automáticamente desde aplicaciones los principales problemas expresando mediante patrones para trabajar con expresiones regulares secciones de código que presentan problemas potenciales y ofreciendo también el patrón de sustitución. Esta guía es una guía “viva” en el sentido de que debe ir creciendo y siendo actualizada conforme se detecten problemas de accesibilidad susceptibles de ser “regularizados” y procedimentados en ella. Guía de buenas prácticas de las principales herramientas de generación de contenidos web. Se auditarán igualmente las principales herramientas de generación de contenidos, externas al gestor de contenidos, que utilizan los autores de la información para crear los contenidos y posteriormente introducirlos en el gestor. Herramientas como por ejemplo Dreamweaver, Word, etc. Una vez auditadas, se generarán guías de buenas prácticas para las mismas que incluyen configuración de las mismas, elementos recomendados y prohibidos, guías de procedimiento en la edición de contenidos, etc., de forma que los contenidos generados con las mismas obtengan un resultado lo más accesible posible, o al menos que faciliten su tratamiento posterior en aquellos casos en los que la generación del código directamente accesible no sea posible. 21 de 74
Utilización de pluggins en procesadores de texto como por ejemplo Word que generan código accesible. Muchos procesadores de textos como por ejemplo Word pueden utilizarse para generar código HTML a partir de un documento. De esta generación resulta normalmente código muy pobre con respecto a la accesibilidad. Existen algunos pluggins que se pueden instalar en el procesador de textos, que tratan de generar código accesible, y aunque en la mayoría de los casos no consiguen la accesibilidad total, son de una gran ayuda y ahorran mucho trabajo en revisiones posteriores. Algunos ejemplos de estos pluggins pueden ser:
Illinois Accesible Web Publishing Wizard. Es un pluggin para Office (Word, Excel y Power Point) que promete crear código accesible. Hay una presentación que habla de pluggins que transforman Word en código accesible utilizando como formato intermedio XML http://www.xmlw.ie/events/MaintainingAccessibleWebsitesWithMicrosoftWordAndX ML.ppt
Construcción del gestor, componentes de aplicación y migración Adaptación del gestor de contenidos y herramienta de portal. Es necesaria tener en cuenta las pautas de accesibilidad a la hora de abordar la construcción, implantación o modificación del gestor de contenidos y la herramienta de portal utilizada. Esta adaptación debe desarrollarse teniendo en cuenta desde un principio el documento maestro de la accesibilidad. Habrá que realizar un inventario de componentes (plantillas, hojas de estilo, componentes de aplicación, etc.) y definir para cada uno de ellos las acciones a realizar. Por ejemplo, para una plantilla de presentación habrá que aplicar las pautas de accesibilidad pero para un componente de aplicación que permita la introducción de código HTML hay que pensar en mecanismos de corrección de ese código. Realización de componentes de aplicación para corregir automáticamente fallos de accesibilidad. Se puede plantear la realización de un componente de aplicación que corrijan automáticamente muchos de los principales fallos auditados en la guía de principales problemas de accesibilidad anteriormente descrita. Este componente es de especial utilidad, ya que se incorpora en diversos sitios del gestor de contenidos, de forma que, por ejemplo, cuando un autor escribe código en el gestor, o cuando lo genera desde otra herramienta externa al mismo (desde editores como Dreamweaver o Word) y lo pega al gestor, se dispara su ejecución y corrige automáticamente muchos de los fallos que se incorporan fruto de una escritura manual o la generación de estas herramientas. Con este componente el trabajo de los revisores es mucho más sencillo, posibilitando que el autor escriba código Accesible HTML, salvando limitaciones a veces de su conocimiento y a veces generadas por otras herramientas.
22 de 74
En el gestor de contenidos se utiliza un componente de aplicación de terceros, como por ejemplo, editores visuales de HTML del tipo WYSIWYG (What You See Is What You Get) para facilitar a los autores que no tienen conocimientos de HTML la inclusión de formato, tablas, etc. en sus contenidos. Este componente puede generar contenidos con problemas de accesibilidad (casi seguro que lo harán). Se plantean varias líneas de trabajo para corregir el comportamiento de estos componentes: por un lado se tratará de personalizar su comportamiento, se podrá tratar de eliminar la funcionalidad no imprescindible con problemas o aplicar correctores automáticos después de su uso. Corrección de contenidos existentes en el portal. Otro trabajo que potencialmente hay que realizar es la corrección de contenidos existentes en la base de datos del portal con problemas de accesibilidad. En este punto, se pueden realizar scripts de corrección, reutilizar en la medida de lo posible los componentes de corrección anteriormente mencionados o la “triste” corrección manual. Inclusión en la guía de estilos de un apartado específico para la accesibilidad. En la guía de estilo referente al diseño del portal, se deben incluir apartados específicos para la accesibilidad o añadir connotaciones para la misma en cada uno de sus apartados.
Normas de diseño del portal Respetar las normas de diseño generales del portal. Las organizaciones suelen tener normas de diseño para los portales. Para ello, se seguirá lo dispuesto en la guía de estilos del portal (revisando eso sí esta guía por si hay algún problema con respecto a la accesibilidad). Algunos ejemplos pueden ser: No usar tamaños o tipos de letra directamente en el código (se hará a través de la hoja de estilos CSS del portal). No es una norma de accesibilidad y usabilidad directamente, pero es horrible encontrarse en una misma organización páginas con distinto tamaño de letra, fuente, etc. Una solución puede ser por ejemplo, eliminar esas marcas FONT automáticamente al introducirlas en el gestor de contenidos. No usar títulos de nivel 1 (H1). Con frecuencia los portales introducen un marco común a todas las páginas en el que ya debe estar incluido el H1. No usar colores en textos: también es horrible en cuanto al estilo corporativo que cada uno pueda personalizar los colores que desee en las páginas (se personalizará si lo permiten las hojas de estilo CSS del portal).
23 de 74
Cumpliendo la accesibilidad Accesibilidad. WCAG 2.O Introducción (Legislación y antecedentes históricos) Con la aceptación de la Norma UNE 139803-2012: Requisitos de Accesibilidad para contenidos en la web, en julio de 2012, se establecen los nuevos requisitos de accesibilidad para los contenidos web, equivalente en su totalidad con las Pautas de Accesibilidad para contenidos Web (WCAG 2.0) de la Iniciativa para la Accesibilidad Web (WAI) del Consorcio de la Web (W3C), que sustituye a la norma hasta entonces vigente (139803:2008) y cuyo cumplimiento en su nivel AA era exigido a los portales de la Administración Pública. El estándar ISO/IEC 40500:2012, convierte a las WCAG 2.0 en estándar internacional. El 15 de octubre de 2012, las Pautas de Accesibilidad Web promovidas por la Iniciativa de Accesibilidad Web del W3C (http://www.w3.org/WAI/), las WCAG 2.0, han sido reconocidas como un estándar internacional ISO. El estándar ISO/IEC 40500:2012 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=58625 Este reconocimiento como norma internacional facilita que cualquier país puede hacer referencia al estándar ISO/IEC 40500:2012 en sus correspondientes legislaciones nacionales favoreciendo la armonización. De hecho, las WCAG 2.0 serán la base para la estandarización armonizada a nivel europeo. En España concretamente, ya se había avanzado en este camino puesto que AENOR, aprobó en el mes de Julio de 2012 la Norma UNE 139803:2012 que también es equivalente a las WCAG 2.0 La noticia en el PAE: http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P804924061272303754870 &langPae=es&detalleLista=PAE_13560711131159068 Recientemente se ha publicado con fecha de 6 de mayo de 2016 en el portal administracionelectronica.gob.es la siguiente noticia: El Consejo Europeo y el Parlamento Europeo han logrado alcanzar un acuerdo después de una larga negociación. La Comisión Europea también se muestra satisfecha por el acuerdo. Este acuerdo, sujeto aún a la aprobación formal en todos los ámbitos, permitirá establecer a nivel europeo unos requisitos de accesibilidad mínimos para los portales y las aplicaciones móviles del sector público. La Directiva cubrirá todos los sitios web y aplicaciones móviles del sector público, desde los de las administraciones, tribunales y servicios de policía a los de los hospitales, universidades y bibliotecas públicas, y hará que sean accesibles a todos los ciudadanos, en particular a los ciegos, los sordos o las personas con dificultades auditivas, visuales o funcionales. El texto acordado de la Directiva: 24 de 74
Cubre todos los sitios web, sus contenidos y las aplicaciones móviles de los organismos del sector público, con un escaso número de excepciones (como los organismos de radiodifusión y el streaming en vivo). También cubre las extranets e intranets que se publiquen o se renueven sustancialmente después de la entrada en vigor de la directiva. Se excluyen algunos tipos de contenidos antiguos (documentos ofimáticos, multimedia, archivos) siempre y cuando no se necesiten actualmente en procedimientos administrativos. Además contempla un mecanismo de solicitud bajo demanda en caso de contenidos no accesibles. Establece un mecanismo de feedback para notificar problemas existentes pudiendo escalarlo en caso de no ser atendido. Requiere un seguimiento y una presentación de informes por parte de los Estados miembros acerca de la accesibilidad de estos sitios web y aplicaciones móviles. Los informes deben presentarse a la Comisión y ser objeto de publicación. Exige a los estados miembros la designación de los organismos encargados de defender el cumplimiento de esta directiva y realizar las tareas de monitorización y reporte. Referencia las normas técnicas de aplicación en línea con UNE-EN 301 549. En entorno web esto se traduce en WCAG 2.0 (o su equivalente en ámbito español UNE 139803:2012). Estas normas será necesario complementarlas con unas CTS (common technical specifications) para cubrir al completo el campo de las aplicaciones móviles.
Más información en: http://administracionelectronica.gob.es/pae_Home/pae_Actualidad/pae_Noticias/Anio2016/ Mayo/Noticia-2016-05-06-Acuerdo-comision-europea-accesibilidad-web.html Pautas de Accesibilidad para el Contenido Web (WCAG 2.0) Es la última versión de las pautas de accesibilidad del contenido en la Web del World Wide Web Consortium (W3C). Estructura y organización de las Pautas WCAG 2.0 Las WCAG 1.0 están organizadas en 14 Pautas generales, que conforman los principios generales de accesibilidad que se deben tener en cuenta al crear contenidos en la Web. Dentro de cada Pauta se encuentran una serie de puntos de verificación, con una orientación práctica, que ofrecen explicaciones técnicas acerca de cómo hacer accesibles los contenidos, teniendo en cuenta los diferentes elementos usados en dichos contenidos. Estos puntos de verificación estaban asociados a tres niveles de prioridad, relacionados a su vez con los tres niveles de cumplimiento A, Doble A y Triple A. Las nuevas Pautas WCAG 2.0 presentan una estructura con ciertas similitudes, aunque también con notables diferencias: Las pautas se organizan en cuatro principios básicos: y dentro de cada uno de los principios nombrados se encuentran las Pautas en sí.
25 de 74
PRINCIPIO 1: Perceptible La información y los elementos de la interfaz de usuario deben presentarse a los usuarios de formas en las que los usuarios puedan percibirlos
Pauta 1.1: Alternativas textuales. Proporcione alternativas textuales para cualquier contenido no textual, de modo que puedan ser convertidos a otros formatos que las personas necesiten, como textos ampliados, braille, síntesis de voz o un lenguaje más simple.
Criterios (Nivel A, AA, AAA) 1.1.1 Contenido no textual: Todo contenido no textual que se presenta al usuario tiene una alternativa textual que cumple el mismo propósito, excepto en las situaciones enumeradas a continuación. (Nivel A) Controles, Entrada de datos: Si el contenido no textual es un control o acepta datos introducidos por el usuario, entonces tiene un nombre que describe su propósito. (Véase la Pauta 4.1 para requisitos adicionales sobre los controles y el contenido que aceptan entrada de datos). Contenido multimedia tempodependiente: Si el contenido no textual es una presentación multimedia con desarrollo temporal, entonces las alternativas textuales proporcionan al menos una identificación descriptiva del contenido no textual. (Véase la Pauta 1.2para requisitos adicionales sobre contenido multimedia). Pruebas: Si el contenido no textual es una prueba o un ejercicio que no sería válido si se presentara en forma de texto, entonces las alternativas textuales proporcionan al menos una identificación descriptiva del contenido no textual. Sensorial: Si el contenido no textual tiene como objetivo principal el crear una experiencia sensorial específica, entonces las alternativas textuales proporcionan al menos una identificación descriptiva del contenido no textual. CAPTCHA: Si el propósito del contenido no textual es confirmar que quien está accediendo al contenido es una persona y no una computadora, entonces se proporcionan alternativas textuales que identifican y describen el propósito del contenido no textual y se proporcionan formas alternativas de CAPTCHA con modos de salida para distintos tipos de percepciones sensoriales, con el fin de acomodarse a las diferentes discapacidades. Decoración, Formato, Invisible: Si el contenido no textual es simple decoración, se utiliza únicamente para definir el formato visual o no se presenta a los usuarios, entonces se implementa de forma que pueda ser ignorado por las ayudas técnicas. Pauta 1.2: Alternativa para multimedia tempo-dependientes. Proporcione alternativas para el contenido basado multimedia en el tiempo.
26 de 74
Criterios (Nivel A, AA, AAA) 1.2.1 Sólo audio y sólo vídeo (grabado): Para contenido sólo audio grabado y contenido sólo vídeo grabado, se cumple lo siguiente, excepto cuando el audio o el vídeo es un contenido multimedia alternativo al texto y está claramente identificado como tal: (Nivel A) Sólo audio grabado: Se proporciona una alternativa para los medios tempodependientes que presenta información equivalente para el contenido sólo audio grabado. Sólo vídeo grabado: Se proporciona una alternativa para los medios tempodependientes o se proporciona una pista sonora que presenta información equivalente al contenido del medio de sólo vídeo grabado. 1.2.2 Subtítulos (grabados): Se proporcionan subtítulos para el contenido de audio grabado dentro de contenido multimedia sincronizado, excepto cuando la presentación es un contenido multimedia alternativo al texto y está claramente identificado como tal. (Nivel A) 1.2.3 Audiodescripción o Medio Alternativo (grabado): Se proporciona una alternativa para los medios tempodependientes o un audiodescripción para el contenido de vídeo grabado en los multimedia sincronizados, excepto cuando ese contenido es un contenido multimedia alternativo al texto y está claramente identificado como tal. (Nivel A) 1.2.4 Subtítulos (en directo): Se proporcionan subtítulos para todo el contenido de audio en directo de los multimedia sincronizados. (Nivel AA) 1.2.5 Audiodescripción (grabado): Se proporciona una audiodescripción para todo el contenido de vídeo grabado dentro de contenido multimedia sincronizado. (Nivel AA) 1.2.6 Lengua de señas (grabado): Se proporciona una interpretación en lengua de señas para todo el contenido de audio grabado dentro de contenido multimedia sincronizado. (Nivel AAA) 1.2.7 Audiodescripción ampliada (grabada): Cuando las pausas en el audio de primer plano son insuficientes para permitir que la audiodescripción comunique el significado del vídeo, se proporciona una audiodescripción ampliada para todos los contenidos de vídeo grabado dentro de contenido multimedia sincronizado. (Nivel AAA) 1.2.8 Medio alternativo (grabado): Se proporciona una alternativa para los medios tempodependientes, tanto para todos los contenidos multimedia sincronizados grabados como para todos los medios de sólo vídeo grabado. (Nivel AAA) 1.2.9 Sólo audio (en directo): Se proporciona una alternativa para los medios tempodependientes que presenta información equivalente para el contenido de sólo audio en directo. (Nivel AAA) Pauta 1.3: Adaptable. Cree contenido que pueda ser presentado de diferentes formas (por ejemplo, un esquema de presentación más simple) sin perder información o estructura.
27 de 74
Criterios (Nivel A, AA, AAA) 1.3.1 Información y relaciones: La información, estructura y relaciones comunicadas a través de la presentación pueden ser determinadas por software o están disponibles como texto. (Nivel A) 1.3.2 Secuencia significativa: Cuando la secuencia en que se presenta el contenido afecta a su significado, se puede determinar por software la secuencia correcta de lectura. (Nivel A) 1.3.3 Características sensoriales: Las instrucciones proporcionadas para entender y operar el contenido no dependen exclusivamente en las características sensoriales de los componentes como su forma, tamaño, ubicación visual, orientación o sonido. (Nivel A) Nota: Para los requisitos relacionados con el color, véase la Pauta 1.4. Pauta 1.4: Distinguible (vista y oído). Facilite a los usuarios ver y escuchar el contenido, incluyendo la separación entre fondo y primer plano Criterios (Nivel A, AA, AAA) 1.4.1 Uso del color: El color no se usa como único medio visual para transmitir la información, indicar una acción, solicitar una respuesta o distinguir un elemento visual. (Nivel A) Nota: Este criterio de conformidad trata específicamente acerca de la percepción del color. En la Pauta 1.3 se recogen otras formas de percepción, incluyendo el acceso por software al color y a otros códigos de presentación visual. 1.4.2 Control del audio: Si el audio de una página web suena automáticamente durante más de 3 segundos, se proporciona ya sea un mecanismo para pausar o detener el audio, o un mecanismo para controlar el volumen del sonido que es independiente del nivel de volumen global del sistema. (Nivel A) Nota: En la medida en que cualquier contenido que no satisfaga este criterio puede interferir con la capacidad del usuario de emplear la página en su conjunto, todo contenido de la página web (tanto si satisface o no otros criterios de conformidad) debe satisfacer este criterio. Véase Requisito de Conformidad 5: Sin interferencia. 1.4.3 Contraste (mínimo): La presentación visual de texto e imágenes de texto tiene una relación de contraste de, al menos, 4.5:1, excepto en los siguientes casos: (Nivel AA) Textos grandes: Los textos de gran tamaño y las imágenes de texto de gran tamaño tienen una relación de contraste de, al menos, 3:1. Incidental: Los textos o imágenes de texto que forman parte de un componente inactivo de la interfaz de usuario, que son simple decoración, que no resultan visibles para nadie o forman parte de una imagen que contiene otros elementos visuales significativos, no tienen requisitos de contraste.
28 de 74
Logotipos: El texto que forma parte de un logo o nombre de marca no tiene requisitos de contraste mínimo. 1.4.4 Cambio de tamaño del texto: A excepción de los subtítulos y las imágenes de texto, todo el texto puede ser ajustado sin ayudas técnicas hasta un 200 por ciento sin que se pierdan el contenido o la funcionalidad. (Nivel AA). 1.4.5 Imágenes de texto: Si con las tecnologías que se están utilizando se puede conseguir la presentación visual deseada, se utiliza texto para transmitir la información en vez de imágenes de texto, excepto en los siguientes casos. (Nivel AA) Configurable: La imagen de texto es visualmente configurable según los requisitos del usuario. Esencial: Una forma particular de presentación del texto resulta esencial para la información que se transmite. Nota: Los logotipos (textos que son parte de un logo o de un nombre de marca) se consideran esenciales. 1.4.6 Contraste (mejorado): La presentación visual de texto e imágenes de texto tiene una relación de contraste de, al menos, 7:1, excepto en los siguientes casos. (Nivel AAA) Textos grandes: Los textos de gran tamaño y las imágenes de texto de gran tamaño tienen una relación de contraste de, al menos, 4.5:1. Incidental: Los textos o imágenes de texto que forman parte de un componente de la interfaz de usuario inactivo, que son simple decoración, que no resultan visibles para nadie o forman parte de una imagen que contiene otros elementos visuales significativos, no tienen requisitos de contraste. Logotipos: El texto que forma parte de un logo o nombre de marca no tiene requisitos de contraste mínimo. 1.4.7 Sonido de fondo bajo o ausente: Para el contenido de sólo audio grabado que (1) contiene habla en primer plano, (2) no es un CAPTCHA sonoro o un audiologo, y (3) que no es una vocalización cuya intención principal es servir como expresión musical (como el canto o el rap), se cumple al menos uno de los siguientes casos: (Nivel AAA) Ningún sonido de fondo: El audio no contiene sonidos de fondo. Apagar: Los sonidos de fondo pueden ser apagados. 20 dB: Los sonidos de fondo son, al menos, 20 decibelios más bajos que el discurso en primer plano, con la excepción de sonidos ocasionales que duran solamente uno o dos segundos. Nota: Por la definición de "decibelio", el sonido de fondo que cumple con este requisito es aproximadamente cuatro veces más silencioso que la locución principal.
29 de 74
1.4.8 Presentación visual: En la presentación visual de bloques de texto, se proporciona algún mecanismo para lograr lo siguiente: (Nivel AAA)
Los colores de fondo y primer plano pueden ser elegidos por el usuario. El ancho no es mayor de 80 caracteres o signos (40 si es CJK). El texto no está justificado (alineado a los márgenes izquierdo y derecho a la vez). El espacio entre líneas (interlineado) es de, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos es, al menos, 1.5 veces mayor que el espacio entre líneas. El texto se ajusta sin ayudas técnicas hasta un 200 por ciento de modo tal que no requiere un desplazamiento horizontal para leer una línea de texto en una ventana a pantalla completa.
1.4.9 Imágenes de texto (sin excepciones): Las imágenes de texto sólo se utilizan como simple decoración o cuando una forma de presentación particular del texto resulta esencial para la información transmitida. (Nivel AAA) Nota: Los logotipos (textos que son parte de un logo o de un nombre de marca) se consideran esenciales. PRINCIPIO 2: Operable Los componentes de la interfaz y la navegación deben ser operables
Pauta 2.1: Acceso mediante teclado Haga toda la funcionalidad disponible desde teclado.
Criterios (Nivel A, AA, AAA) 2.1.1 Teclado: Toda la funcionalidad del contenido es operable a través de una interfaz de teclado sin que se requiera una determinada velocidad para cada pulsación individual de las teclas, excepto cuando la función interna requiere de una entrada que depende del trayecto de los movimientos del usuario y no sólo de los puntos inicial y final. (Nivel A) Nota 1: Esta excepción se refiere a la función subyacente, no a la técnica de entrada de datos. Por ejemplo, si la entrada de texto se hace por medio de escritura a mano, la técnica de entrada (escritura a mano) depende del trazo (ruta trazada) pero la función interna (introducir texto) no. Nota 2: Esto no prohíbe ni debería desanimar a los autores a proporcionar entrada de ratón u otros métodos de entrada de datos adicionales a la operabilidad a través del teclado. 2.1.2 Sin trampas para el foco del teclado: Si es posible mover el foco a un componente de la página usando una interfaz de teclado, entonces el foco se puede quitar de ese componente usando sólo la interfaz de teclado y, si se requiere algo más que las teclas de dirección o de tabulación, se informa al usuario el método apropiado para mover el foco. (Nivel A)
30 de 74
Nota: En la medida en que cualquier contenido que no satisfaga este criterio puede interferir con la capacidad del usuario para emplear la página por completo, todo contenido de la página web (tanto si satisface o no otros criterios de conformidad) debe satisfacer este criterio. Véase Requisito de Conformidad 5: Sin interferencia. 2.1.3 Teclado (sin excepciones): Toda la funcionalidad del contenido se puede operar a través de una interfaz de teclado sin requerir una determinada velocidad en la pulsación de las teclas. (Nivel AAA) Pauta 2.2: Suficiente tiempo. Proporcione a los usuarios suficiente tiempo para leer y usar el contenido Criterios (Nivel A, AA, AAA) 2.2.1 Tiempo ajustable: Para cada límite de tiempo impuesto por el contenido, se cumple al menos uno de los siguientes casos: (Nivel A) Apagar: El usuario puede detener el límite de tiempo antes de alcanzar el límite de tiempo; o Ajustar: El usuario puede ajustar el límite de tiempo antes de alcanzar dicho límite en un rango amplio que es, al menos, diez veces mayor al tiempo fijado originalmente; o Extender: Se advierte al usuario antes de que el tiempo expire y se le conceden al menos 20 segundos para extender el límite temporal con una acción simple (por ejemplo, "presione la barra de espacio") y el usuario puede extender ese límite de tiempo al menos diez veces; o Excepción de tiempo real: El límite de tiempo es un requisito que forma parte de un evento en tiempo real (por ejemplo, una subasta) y no resulta posible ofrecer una alternativa al límite de tiempo; o Excepción por ser esencial: El límite de tiempo es esencial y, si se extendiera, invalidaría la actividad; o Excepción de 20 horas: El límite de tiempo es mayor a 20 horas. Nota: Este criterio de conformidad ayuda a asegurarse de que los usuarios puedan completar una tarea sin cambios inesperados en el contenido o contexto que sean el resultado de un límite de tiempo. Este criterio de conformidad debe considerarse en combinación con el Criterio de Conformidad 3.2.1, que impone límites a los cambios de contenido o contexto como resultado de una acción del usuario. 2.2.2 Poner en pausa, detener, ocultar: Para la información que tiene movimiento, parpadeo, se desplaza o se actualiza automáticamente, se cumplen todos los casos siguientes: (Nivel A) Movimiento, parpadeo, desplazamiento: Para toda información que se mueve, parpadea o se desplaza, que (1) comienza automáticamente, (2) dura más de cinco segundos y (3) se presenta en paralelo con otro contenido, existe un mecanismo para que el usuario la pueda
31 de 74
poner en pausa, detener u ocultar, a menos que el movimiento, parpadeo o desplazamiento sea parte esencial de una actividad; y Actualización automática: Para toda información que se actualiza automáticamente, que (1) se inicia automáticamente y (2) se presenta en paralelo con otro contenido, existe un mecanismo para que el usuario la pueda poner en pausa, detener u ocultar, o controlar la frecuencia de actualización a menos que la actualización automática sea parte esencial de una actividad. Nota 1: Para los requisitos relacionados con el parpadeo o el destello de contenido, véase la Pauta 2.3. Nota 2: En la medida en que cualquier contenido que no satisfaga este criterio puede interferir con la capacidad del usuario para emplear la página como un todo, todo contenido de la página web (tanto si satisface o no otros criterios de conformidad) debe satisfacer este criterio. Véase Requisito de Conformidad 5: Sin interferencia. Nota 3: Para el contenido que es actualizado periódicamente por medio de un software, o que se sirve a la aplicación de usuario por medio de streaming, no hay obligación de preservar o presentar la información que ha sido generada o recibida entre el inicio de la pausa y el reinicio de la presentación; no sólo podría no ser técnicamente posible, sino que además en muchas ocasiones podría ser erróneo o engañoso hacerlo. Nota 4: Una animación que ocurre como parte de una fase de precarga de un contenido o una situación similar puede ser considerada esencial si no se permite interacción a ningún usuario durante esa fase, y si el hecho de no indicar el progreso pudiera confundir a los usuarios y hacerles creer que ha habido un fallo en el contenido. 2.2.3 Sin tiempo: El tiempo no es parte esencial del evento o actividad presentada por el contenido, exceptuando los multimedia sincronizados no interactivos y los eventos en tiempo real. (Nivel AAA) 2.2.4 Interrupciones: El usuario puede postergar o suprimir las interrupciones, excepto cuando las interrupciones implican una emergencia. (Nivel AAA). 2.2.5 Re-autentificación: Cuando expira una sesión autentificada, el usuario puede continuar la actividad sin pérdida de datos tras volver a identificarse. (Nivel AAA). Pauta 2.3: Destellos. No diseñe el contenido en formas que se conoce que pueden provocar ataques epilépticos.
Criterios (Nivel A, AA, AAA) 2.3.1 Umbral de tres destellos o menos: Las páginas web no contienen nada que destelle más de tres veces en un segundo, o el destello está por debajo del umbral de destello general y de destello rojo. (Nivel A)
32 de 74
Nota: En la medida en que cualquier contenido que no satisfaga este criterio puede interferir con la capacidad del usuario para emplear la página como un todo, todo contenido de la página web (tanto si satisface o no otros criterios de conformidad) debe satisfacer este criterio. Véase Requisito de Conformidad 5: Sin interferencia. 2.3.2 Tres destellos: Las páginas web no contienen nada que destelle más de tres veces por segundo. (Nivel AAA). Pauta 2.4: Navegable. Proporcione formas de ayudar a los usuarios a navegar el contenido y determinar dónde están o donde se encuentran.
Criterios (Nivel A, AA, AAA) 2.4.1 Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web. (Nivel A) 2.4.2 Titulado de páginas: Las páginas web tienen títulos que describen su temática o propósito. (Nivel A) 2.4.3 Orden del foco: Si se puede navegar secuencialmente por una página web y la secuencia de navegación afecta su significado o su operación, los componentes que pueden recibir el foco lo hacen en un orden que preserva su significado y operabilidad. (Nivel A) 2.4.4 Propósito de los enlaces (en contexto): El propósito de cada enlace puede ser determinado con sólo el texto del enlace o a través del texto del enlace sumado al contexto del enlace determinado por software, excepto cuando el propósito del enlace resultara ambiguo para los usuarios en general. (Nivel A) 2.4.5 Múltiples vías: Se proporciona más de un camino para localizar una página web dentro de un conjunto de páginas web, excepto cuando la página es el resultado, o un paso intermedio, de un proceso. (Nivel AA) 2.4.6 Encabezados y etiquetas: Los encabezados y etiquetas describen el tema o propósito. (Nivel AA) 2.4.7 Foco visible: Cualquier interfaz de usuario operable por teclado tiene una forma de operar en la cual el indicador del foco del teclado resulta visible. (Nivel AA) 2.4.8 Ubicación: Se proporciona información acerca de la ubicación del usuario dentro de un conjunto de páginas web. (Nivel AAA) 2.4.9 Propósito de los enlaces (sólo enlaces): Se proporciona un mecanismo que permite identificar el propósito de cada enlace con sólo el texto del enlace, excepto cuando el propósito del enlace resultara ambiguo para los usuarios en general. (Nivel AAA) 2.4.10 Encabezados de sección: Se usan encabezados de sección para organizar el contenido. (Nivel AAA) 33 de 74
Nota 1: "Encabezados" se usa en sentido general e incluye los títulos y otras formas de agregar encabezados a las distintos tipos de contenido. Nota 2: Este criterio de conformidad se refiere al contenido propiamente dicho, no a los componentes de la interfaz de usuario. Los componentes de la interfaz de usuario se tratan en el Criterio de Conformidad 4.1.2. PRINCIPIO 3: Comprensible La información y el manejo de la interfaz de usuario deben ser comprensibles. Pauta 3.1: Legible y entendible. Haga el contenido textual legible y comprensible. Criterios (Nivel A, AA, AAA) 3.1.1 Idioma de la página: El idioma predeterminado de cada página web puede ser determinado por software. (Nivel A) 3.1.2 Idioma de las partes: El idioma de cada pasaje o frase en el contenido puede ser determinado por software, excepto los nombres propios, términos técnicos, palabras en un idioma indeterminado y palabras o frases que se hayan convertido en parte natural del texto que las rodea. (Nivel AA) 3.1.3 Palabras inusuales: Se proporciona un mecanismo para identificar las definiciones específicas de palabras o frases usadas de modo inusual o restringido, incluyendo expresiones idiomáticas y jerga. (Nivel AAA) 3.1.4 Abreviaturas: Se proporciona un mecanismo para identificar la forma expandida o el significado de las abreviaturas. (Nivel AAA) 3.1.5 Nivel de lectura: Cuando un texto requiere un nivel de lectura más avanzado que el nivel mínimo de educación secundaria una vez que se han eliminado nombres propios y títulos, se proporciona un contenido suplementario o una versión que no requiere un nivel de lectura mayor a ese nivel educativo. (Nivel AAA) 3.1.6 Pronunciación: Se proporciona un mecanismo para identificar la pronunciación específica de las palabras cuando el significado de esas palabras, dentro del contexto, resulta ambiguo si no se conoce su pronunciación. (Nivel AAA) Pauta 3.2: Predecible. Haga que las páginas web aparezcan y se manejen de manera predecible. Criterios (Nivel A, AA, AAA) 3.2.1 Al recibir el foco: Cuando cualquier componente recibe el foco, no inicia ningún cambio en el contexto. (Nivel A)
34 de 74
3.2.2 Al recibir entradas: El cambio de estado en cualquier componente de la interfaz de usuario no provoca automáticamente un cambio en el contexto a menos que el usuario haya sido advertido de ese comportamiento antes de usar el componente. (Nivel A) 3.2.3 Navegación coherente: Los mecanismos de navegación que se repiten en múltiples páginas web dentro de un conjunto de páginas web aparecen siempre en el mismo orden relativo cada vez que se repiten, a menos que el cambio sea provocado por el propio usuario. (Nivel AA) 3.2.4 Identificación coherente: Los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas web son identificados de manera coherente. (Nivel AA) 3.2.5 Cambios a petición: Los cambios en el contexto son iniciados únicamente a solicitud del usuario o se proporciona un mecanismo para detener tales cambios. (Nivel AAA) Pauta 3.3: Ayuda a la entrada de datos. Ayude a los usuarios a evitar y corregir los errores. Criterios (Nivel A, AA, AAA) 3.3.1 Identificación de errores: Si se detecta automáticamente un error en la entrada de datos, el elemento erróneo es identificado y el error se describe al usuario mediante un texto. (Nivel A) 3.3.2 Etiquetas o instrucciones: Se proporcionan etiquetas o instrucciones cuando el contenido requiere la introducción de datos por parte del usuario. (Nivel A) 3.3.3 Sugerencias ante errores: Si se detecta automáticamente un error en la entrada de datos y se dispone de sugerencias para hacer la corrección, entonces se presentan las sugerencias al usuario, a menos que esto ponga en riesgo la seguridad o el propósito del contenido. (Nivel AA) 3.3.4 Prevención de errores (legales, financieros, datos): Para las páginas web que representan para el usuario compromisos legales o transacciones financieras; que modifican o eliminan datos controlables por el usuario en sistemas de almacenamiento de datos; o que envían las respuestas del usuario a una prueba, se cumple al menos uno de los siguientes casos. (Nivel AA)
Reversible: El envío es reversible. Revisado: Se verifica la información para detectar errores en la entrada de datos y se proporciona al usuario una oportunidad de corregirlos. Confirmado: Se proporciona un mecanismo para revisar, confirmar y corregir la información antes de finalizar el envío de los datos.
3.3.5 Ayuda: Se proporciona ayuda dependiente del contexto. (Nivel AAA) 3.3.6 Prevención de errores (todos): Para las páginas web que requieren al usuario el envío de información, se cumple al menos uno de los siguientes casos. (Nivel AAA)
35 de 74
Reversible: El envío es reversible. Revisado: Se verifica la información para detectar errores en la entrada de datos y se proporciona al usuario una oportunidad de corregirlos. Confirmado: Se proporciona un mecanismo para revisar, confirmar y corregir la información antes de finalizar el envío de los datos.
PRINCIPIO 4: Robusto El contenido debe ser suficientemente robusto para que pueda ser interpretado por una amplia variedad de agentes de usuario, incluyendo los productos de apoyo.
Pauta 4.1: Compatible. Maximice la compatibilidad con las aplicaciones de usuarios actuales y futuros, incluyendo las ayudas técnicas. Criterios (Nivel A, AA, AAA) 4.1.1 Procesamiento: En los contenidos implementados mediante el uso de lenguajes de marcas, los elementos tienen las etiquetas de apertura y cierre completas; los elementos están anidados de acuerdo a sus especificaciones; los elementos no contienen atributos duplicados y los ID son únicos, excepto cuando las especificaciones permitan estas características. (Nivel A) Nota: Las etiquetas de apertura y cierre a las que les falte un carácter crítico para su formación, como un signo de "mayor qué", o en las que falten las comillas de apertura o cierre en el valor de un atributo, no se consideran completas. 4.1.2 Nombre, función, valor: Para todos los componentes de la interfaz de usuario (incluyendo pero no limitado a: elementos de formulario, enlaces y componentes generados por scripts), el nombre y la función pueden ser determinados por software; los estados, propiedades y valores que pueden ser asignados por el usuario pueden ser especificados por software; y los cambios en estos elementos se encuentran disponibles para su consulta por las aplicaciones de usuario, incluyendo las ayudas técnicas. (Nivel A) Nota: Este criterio de conformidad se dirige principalmente a los autores web que desarrollan o programan sus propios componentes de interfaz de usuario. Por ejemplo, los controles estándar de HTML satisfacen automáticamente este criterio cuando se emplean de acuerdo con su especificación. Referencias sobre la información obtenida hasta aquí referente a principios, pautas y criterios. Hasta aquí hemos nombrado cada uno de los principios, pautas y cada uno de sus criterios de éxito indicando su nivel de conformidad (A, AA, AAA) esta información ha sido obtenida de la web http://www.sidar.org que pertenece a la Fundación Sidar – Acceso Universal con el objetivo de conseguir que la sociedad de la información en toda Iberoamérica sea accesible. Se refiere a una traducción candidata a ser la Oficial al Español.
36 de 74
Versión original en inglés: http://www.w3.org/TR/WCAG20/ Organización coordinadora de la traducción: Fundación Sidar - Acceso Universal Sitio web: http://www.sidar.org/Coordinadores de la traducción: Emmanuelle Gutiérrez y Restrepo (e-mail: [email protected]) y Carlos Benavidez (e-mail: [email protected]) Traductora: Sofía Benavidez (e-mail: [email protected]) Texto de Principios, Pautas y criterios traducidos en: http://www.sidar.org/traducciones/wcag20/es/#text-equiv Conclusiones hasta el momento sobre WCAG 2.0 A modo de resumen podemos decir que cada Pauta se desarrolla en una serie de Criterios de Éxito, que de forma similar a los puntos de verificación en WCAG 1.0, establecen una serie de criterios de accesibilidad que deben cumplir los contenidos web, y que pueden ser verificados para comprobar el cumplimiento de las Pautas. Los criterios de éxito están clasificados por niveles de conformidad (A, AA, AAA); un mismo criterio puede ocurrir con ligeras diferencias en distintos niveles. Son independientes de la tecnología usada para crear el contenido. Los criterios se han redactado para ser verificados sin ambigüedad, por una herramienta automática o por una persona. Cada criterio de éxito incluye un enlace al apartado correspondiente en los demás documentos de soporte. Además, cada criterio de éxito puede enlazar con diversas Técnicas, que pueden ser de dos tipos: 1. Técnicas de suficiencia: si se sigue esta técnica se cumple con el criterio para el elemento de que se trate. 2. Técnicas complementarias: son técnicas que ayudan a mejorar la accesibilidad, pero que no garantizan el completo cumplimiento de los criterios.
37 de 74
Imagen de una tabla que indica los cuatro principios, pautas y los criterios agrupados según
Niveles de Conformidad con WCAG 2.0 Cuando se adopta WCAG 2.0 partiendo desde el cumplimiento de las WCAG 1.0, se encuentran una serie de diferencias que deben tenerse en cuenta. Para que una página web cumpla con las Pautas 2.0, deben cumplirse también una serie de requisitos que tratan el alcance y la forma de usar las tecnologías, además del Nivel de Conformidad: Nivel de conformidad: de forma similar a las WCAG 1.0, esta versión contempla tres niveles: A, AA y AAA. Sin embargo, no se recomienda la adopción del nivel AAA como requisito u objetivo general para sitios enteros, debido a que con algunos tipos de contenidos no es posible cumplir con todos los criterios. Páginas enteras: la conformidad solo se plantea para páginas web completas, es decir, no se admiten excepciones para partes de la página, aunque se permite el uso de tecnologías sin soporte para la accesibilidad, siempre que no interfieran con el acceso al resto del contenido, y que se ofrezca contenido alternativo equivalente en la misma página o accesible a través de ella. Mientras que para el contenido no conforme en WCAG 1.0 se requiere una página alternativa, con la versión 2.0 se admite que esta alternativa esté dentro de la misma página. También se define con precisión qué se entiende por “página web”. Por otro lado, si se incluye contenido no conforme de una fuente externa, fuera del control del sitio, se puede realizar una declaración de incumplimiento parcial. IGES cuenta con un tipo de contenido llamado “Proceso Java” que obtiene información HTML de fuentes externas como pueden ser publicaciones, anuncios de contratación administrativa y otros. En este caso no podemos garantizar el cumplimiento de estas normas al igual que en otras situaciones que iremos viendo.
38 de 74
Procesos completos: cuando una página forma parte de un proceso (una secuencia de pasos necesarios para completar una tarea), todas las páginas del conjunto deben cumplir al nivel declarado o uno mayor, es decir, una página dada no puede cumplir si otra página en la secuencia no cumple. El ejemplo en este punto podría ser la cumplimentación de una solicitud en varias páginas. Sólo depender de formas de uso de las tecnologías que proporcionen soporte para la accesibilidad: si una tecnología proporciona soporte para la accesibilidad en algunos aspectos pero no en otros, solo se debe depender de los aspectos que disponen de ese soporte. Esto significa que se pueden usar aspectos de las tecnologías que no soporten la accesibilidad, pero no depender de ellos para ofrecer la información; en dichos casos se debe proporcionar una alternativa al contenido no accesible. Un ejemplo sería usar Javascript para alguna cosa en concreto pero proveer de un mecanismo por si estuviese bloqueado para hacer lo mismo pero de otra forma.
No interferir con el contenido o impedir el acceso al mismo: se considera aceptable el uso de tecnologías sin soporte para la accesibilidad, o sin cumplir las Pautas, siempre que se ofrezca contenido equivalente. Sin embargo, en estos casos el uso de la tecnología no debe impedir o interferir con el acceso al resto de la página por parte del usuario. Además la página entera debe ser conforme, tanto con la tecnología no imprescindible activada, como si está desactivada o no soportada. Para el cumplimiento, las Pautas definen cuatro criterios de éxito que son aplicables a todo el contenido de una página web, incluido el contenido no imprescindible, debido a que el incumplimiento de estos criterios puede impedir o interferir con el uso de la página. Estos criterios son el 1.4.2 sobre control de audio, el 2.1.2 acerca de trampas de teclado, el 2.2.2 sobre pausa, parada y ocultación de contenido, y el 2.3.1 sobre el umbral de tres destellos o menos. Cuando se cumple con las Pautas WCAG 2.0, es posible incluir en dichas páginas una Declaración que indique a los usuarios este cumplimiento. En ese caso, las WCAG 2.0 especifican qué condiciones debe cumplir dicha Declaración de Conformidad, que deberá incluir al menos los siguientes elementos: Fecha en que se revisó dicho cumplimiento Título, versión y URI de las Pautas WCAG 2.0
Nivel de conformidad alcanzado (A, AA o AAA) Alcance: enumeración precisa de las páginas que cumplen con las Pautas WCAG 2.0, por ejemplo una lista de URIs o una expresión regular que describa un conjunto de URIs. Listado de las tecnologías de las que depende el contenido.
Además, si se usa un sello, éste debe ir acompañado por la información descrita anteriormente. Declaración de conformidad parcial por contenido externo
39 de 74
Dado un portal del tipo blog, correo electrónico u otro en ocasiones se incluye publicidad de forma dinámica en cuyo caso en el momento de la publicación es imposible conocer a priori si nuestro contenido cumplirá con las normas en cuyo caso existen dos opciones: 1. Se puede determinar la conformidad basándose en la monitorización. Si se monitoriza una página de este tipo y los errores son reparados (el contenido erróneo se elimina o corrige para ser conforme) en un plazo de dos días laborables tras su detección, entonces es posible realizar una declaración de conformidad dado que la página es conforme, excepto para el contenido externo. No es posible realizar una declaración de conformidad si no se puede monitorizar o corregir el contenido no conforme. 2. Se puede incluir una “declaración de conformidad parcial”, indicando que la página no es conforme, pero que lo sería si se eliminaran ciertas partes del contenido. La forma que tomaría esta declaración sería: “Esta página no es conforme, pero sería conforme con WCAG 2.0 en su Nivel X si se eliminaran las siguientes partes del contenido, procedentes de fuentes no controladas.” Además, para el contenido no controlado que se describe en la declaración de conformidad parcial, se debe cumplir también que: El autor no tiene control sobre el contenido. El contenido se describe de forma que los usuarios puedan identificarlo (por ejemplo, no puede ser descrito simplemente como “todas las partes sobre las que no tenemos control”, a no ser que estén claramente marcadas de esa manera). También se podría realizar en casos de portales multilingüe en el caso de que cierto idiomas no cumpliera. En este caso se puede incluir una “declaración de conformidad parcial debida al idioma” cuando la página no es conforme, pero lo sería si existiera soporte para la accesibilidad para todos los idiomas usados en la página. La forma de esta declaración sería: “Esta página no es conforme, pero sería conforme con WCAG 2.0 en su Nivel X si existiera soporte de accesibilidad para los siguientes idiomas:” Diferencias generales con WCAG 1.0 La nueva norma, basada en WCAG 2.0, presenta diferencias sustanciales en la ordenación, estructuración y validación de reglas con respecto a la versión 1.0, aunque muchas de las pautas presentes en la primera versión se mantienen, con algunas variaciones, en la nueva versión. En rasgos generales, las nuevas pautas pretenden mejorar varios puntos que con el paso del tiempo se han presentado como conflictivos para mantener los estándares de accesibilidad. Entre estos apartados podemos destacar los siguientes: -
Se mejora la automatización de la validación de las reglas, haciendo que en muchos casos sean menos interpretables que en la primera versión.
-
Se extiende su aplicación a otras tecnologías, presentes o no en la web, validando no sólo los componentes W3C como CSS y HTML de las mismas.
40 de 74
Además, la organización de los elementos se realiza con otra estructuración, existiendo los 4 Principios fundamentales, que engloban a un conjunto de Pautas o Normas, que presentan una serie de Criterios de éxito, así como unas Técnicas de éxito y ejemplos de fallos comunes. Para la evaluación de accesibilidad de un elemento (independientemente de la tecnología) se pueden comprobar con mayor precisión los distintos criterios, tanto automáticamente como manual. Un mismo criterio de éxito puede aparecer con distintos niveles de conformidad. Por ejemplo, el criterio 1.4.3 Contraste (Mínimo) con Nivel AA y el 1.4.6 Contraste (Mejorado) con Nivel AAA. Son esencialmente lo mismo, pero a nivel AAA es más exigente. Para finalizar, la declaración de cumplimiento de accesibilidad según la WCAG 2.0 debe incluir más información que la presente en la anterior versión. Además de la fecha, versión de la WCAG y nivel de cumplimiento, se debe describir de forma precisa las páginas a las que afecta la declaración, así como una lista de tecnologías de las que depende el contenido. ¿Dónde nos centramos para el paso de WCAG 1.0 a 2.0? Dado que la WCAG 2.0 se puede considerar una ampliación y extensión de las normas en la versión 1.0, es fácil que muchos de los contenidos ya cumplan con la nueva especificación. Por supuesto, esto no implica que deba de ocurrir así, ya que existen nuevos puntos de verificación en la versión 2.0 y otros de la versión 1 han sido modificados o adaptados a la nueva estructura e independencia de la tecnología. A continuación se listan algunos de los elementos que han sufrido cambios y son necesarios revisar para cumplir las nuevas normas. -
Imágenes y mapas Multimedia Script y otros objetos programados Independencia del dispositivo Movimiento y actualización automática Uso de tecnologías W3C Maquetación y presentación Elementos de estructura (encabezados, listas, bloques, etc) Idioma y comprensión del lenguaje Tablas de datos Marcos Formularios Navegación Metadatos
41 de 74
Como afecta WCAG 2.0 a elementos concretos y tecnologías específicas. Aspectos generales. Imágenes y mapas de imagen Las imágenes son uno de los elementos fundamentales en todo contenido web, por lo que su accesibilidad es clave en la percepción global del sitio. En el contexto de las WCAG 2.0, tecnológicamente neutrales, el concepto de “imagen” puede referirse tanto a ficheros bitmap insertados como tal en una página web (PNG, JPG o GIF, por ejemplo), como a imágenes insertadas dentro de otro tipo de documentos o tecnologías, incluyendo también cualquier representación gráfica no textual, como pueden ser gráficos vectoriales, iconos y símbolos o ASCII Art. Por lo tanto, a diferencia de las Pautas WCAG 1.0, las alternativas a las imágenes pueden darse de maneras muy distintas dependiendo de la tecnología que se esté usando, dado que no siempre se insertarán las imágenes mediante una etiqueta HTML. Respecto a los mapas de imagen, además de lo ya expuesto sobre las alternativas textuales, en las Pautas 2.0 se contemplan algunos criterios referidos a la operabilidad con teclado de los mapas de imagen. Recordamos que un mapa de imagen permite definir diferentes zonas "pinchables" dentro de una imagen. Multimedia (audio, vídeo, presentaciones) En este apartado, el término “multimedia” hace referencia a los contenidos que se presentan en formatos no textuales, tales como audio, vídeo, animaciones o presentaciones interactivas, entendidas estas últimas como aquellas presentaciones más o menos simples, donde el usuario tiene un cierto control sobre la visualización del contenido, pero sin mayores posibilidades de interacción. La clave aquí son los distintos formatos multimedia (no textuales) en los que se puede presentar la información, sin llegar a alcanzar la categoría de objetos programados, donde las posibilidades de interactividad y control por parte del usuario son mucho mayores. Recordamos aquí que las Pautas WCAG 2.0 recogen muchos criterios que deben ser tenidos en cuenta para los elementos multimedia, tales como alternativas textuales a dichos elementos, audiodescripción y subtitulado, o la interfaz y el control por parte del usuario de la reproducción de contenido multimedia; además, en esta nueva versión se hace una clara distinción entre el contenido pregrabado y el contenido emitido en directo, aplicándose criterios ligeramente diferentes para uno y otro. A Considerar o o o o
Alternativas textuales al contenido multimedia Audiodescripción y subtitulado Control de reproducción Acceso mediante teclado
Objetos programados (JavaScript y otros) Debido a la neutralidad tecnológica de las Pautas WCAG 2.0, ya no existe distinción entre este tipo de contenidos y los realizados puramente con HTML y CSS. En esta nueva concepción, un
42 de 74
objeto incrustado en una página web, un applet Java o un script pueden ser completamente accesibles sin requerir una alternativa, siempre y cuando la tecnología usada tenga soporte para la accesibilidad y el objeto o script se haya desarrollado de manera accesible. Asimismo, siendo AJAX tan sólo un uso concreto de JavaScript, se trata del mismo modo que el resto de contenidos, pudiendo ser totalmente accesible si la programación se realiza de la forma adecuada. A este tipo de contenidos son aplicables la totalidad de las Pautas WCAG 2.0 Maquetación y presentación Las Pautas WCAG 1.0 estaban orientadas a las tecnologías desarrolladas por el W3C, por lo que hacían referencia explícita al uso de CSS para maquetar y presentar la información (punto de verificación 3.3 en WCAG 1.0), así como a la accesibilidad del contenido en caso de no estar disponibles las hojas de estilo (punto 6.1 en WCAG 1.0). En las WCAG 2.0, tecnológicamente neutrales, esta limitación ha desaparecido, admitiéndose como válida cualquier tecnología que tenga soporte para la accesibilidad, siempre y cuando el desarrollo se haga de manera accesible. A continuación se nombran algunas técnicas habituales de maquetación y otras características relacionadas con la presentación del contenido.
Tablas de maquetación Hojas de estilo Uso del color y contraste Unidades de medida
Encabezados, listas, citas y otros bloques de texto En este apartado se incluyen una serie de criterios relativos al marcado estructural de contenidos, lo que permite identificar la funcionalidad y las relaciones entre los distintos elementos de la página web. Existen algunos cambios desde los puntos de verificación de WCAG 1.0 con respecto a los criterios de éxito WCAG 2.0 ahora más genéricos. En la técnica relativa al uso de encabezados en HTML, se observa una diferencia notable respecto a las Pautas WCAG 1.0, ya que se da la posibilidad explícita de alterar el orden de los distintos niveles de encabezado en una página web. Esto es así porque se entiende que cada sección de una misma página web puede ser considerada como una unidad independiente, y es en estas secciones independientes donde se aplicaría el criterio de seguir un orden correcto de los encabezados; por otro lado, los encabezados se tratan también en el criterio de éxito 2.4.6 (Nivel AA), sobre encabezados y etiquetas, indicando que éstos deben describir el tema o el propósito del contenido al que encabezan o etiquetan. Asimismo, existen diversas técnicas relativas al marcado en HTML de listas, bloques, elementos de formulario, tablas de datos, elementos de énfasis, etc.; en el caso concreto del marcado de citas, por ejemplo, también se contempla específicamente como condición de
43 de 74
fallo el uso de los elementos de cita sólo para provocar efectos visuales, y no con carácter estructural. Por otro lado, en las Pautas WCAG 1.0 existía el punto de verificación 12.3, que indicaba la necesidad de dividir los bloques largos de información en bloques más cortos; en WCAG 2.0 se puede encontrar cierta referencia a esta división en el criterio 2.4.10 (Nivel AAA), relativo a organizar de la información con encabezados de sección. Idiomas y comprensión del lenguaje En las Pautas WCAG 2.0, los criterios relativos al entendimiento del contenido, tanto en lo relativo al idioma como en lo referente al tipo de lenguaje usado, se engloban bajo la Pauta 3.1, que indica que el contenido debe ser legible y entendible. A considerar también el criterio 3.1.3, relativo a la utilización de palabras inusuales, el 3.1.4 relativo a las abreviaturas (similar al punto 4.2 de WCAG 1.0), o el 3.1.5, relativo al nivel de lectura de los usuarios. Sobre el criterio 3.1.4 aun siendo de (Nivel AAA) al igual que su similar punto 4.2 de WCAG 1.0 también era de prioridad 3 en IGES siempre hemos tratado de cumplir con él, por esta razón vamos a comentar algunas detalles a tener en cuenta. Se trata de desarrollar acrónimos y abreviaturas que aparezcan por primera vez en una página, pero veamos cómo se hace en HTML. La idea principal es aportar toda la semántica que podamos a nuestros contenidos. Las etiquetas encargadas son y y su atributo “title” vamos a ver un ejemplo: Abreviatura Tel Acrónimo
RAE
En HTML 5 y XHTML2 queda eliminado a favor de estandarizar únicamente . En nuestros contenidos en mientras el trasiego de versión nosotros seguiremos usando la especificación de HTML 4. Tablas de datos En las WCAG 2.0 se trata en el criterio de éxito 1.3.1 (Nivel A) sobre la información y sus relaciones, donde se requiere que toda la información, estructura y relaciones que se transmitan mediante presentación puedan ser determinados programáticamente, o disponibles en forma de texto. El criterio de éxito 1.3.1 es muy amplio, recogiendo de forma genérica el uso adecuado del marcado estructural de los contenidos. En lo relativo a las tablas, se pueden encontrar referencias específicas en las Técnicas H51 (uso de elementos de marcado de tablas para presentar información tabular), H63 (uso del atributo scope) y H43 (uso de los atributos id y headers para asociar celdas de datos con celdas de cabecera en tablas de datos).
44 de 74
En cuanto al punto de verificación 5.5, relativo a los títulos y resúmenes de tablas de datos, en las WCAG 2.0 ya no hay referencias a esta exigencia, aunque sí se contempla como fallo de cumplimiento el uso del atributo summary en tablas de maquetación, donde su uso es inadecuado (condición de fallo F43). Marcos En WCAG 2.0, los marcos son tratados como cualquier otro contenido, por lo que aplican a ellos todos los criterios de accesibilidad. En cuanto a los puntos de verificación de WCAG 1.0 específicos para marcos, su evolución es dispar. En primer lugar, el punto 12.1, relativo a la necesidad de titular cada marco para facilitar su identificación y navegación, tiene ahora una cierta equivalencia en el criterio de éxito 4.1.2 (Nivel A), que indica que se debe especificar el nombre y rol de los elementos, así como permitir el ajuste de aquellos valores o propiedades que sean relevantes. Por otro lado, también es de aplicación el criterio 2.4.1 (Nivel A), que indica que se deben proporcionar mecanismos para saltar bloques de contenido que se repitan en múltiples páginas. En cuanto al punto 12.2, relativo a la descripción larga de las relaciones entre marcos, en las WCAG 2.0 no hay tal necesidad, además de que en las nuevas versiones de XHTML ya no existe el atributo longdesc para el elemento frame. Por otro lado, otros puntos de verificación de WCAG 1.0 que pueden tener relación con los marcos, como el 1.1, el 6.2 o el 6.5, relativos a las alternativas y al contenido dinámico (entendido el contenido de un marco como tal), no tienen equivalencia en WCAG 2.0 en lo que se refiere a los marcos, ya que si éstos y sus contenidos se realizan de forma accesible no es necesario proporcionar alternativas a los mismos. Formularios La interacción del usuario con el contenido web es uno de los aspectos que más ha evolucionado en las Pautas WCAG 2.0, que incorporan diversos criterios de éxito relativos al control y prevención de errores al introducir datos, el etiquetado de los controles o la presencia de instrucciones para que el usuario sepa cómo debe rellenar los campos, la mayor de los cuales se agrupan bajo la Pauta 3.3, “Ayudar a los usuarios a evitar y corregir errores”. En este sentido, en HTML se pueden incluir las etiquetas de la manera “tradicional”, es decir, usando el elemento LABEL y asociándolo a su control mediante la combinación de atributos for-id, pero también se admite la posibilidad de que la etiqueta se asigne mediante un atributo title en el control, ya que las nuevas Pautas 2.0 consideran válido cualquier método que permita determinar programáticamente el contenido de la etiqueta. Es de señalar también que ya no se considera como un requisito el posicionar la etiqueta de una determinada manera con respecto del control, ya que los agentes de usuario y productos de apoyo actuales son capaces de reconocer la asociación explícita entre etiquetas y controles, sin tener que “adivinar” cuál es la etiqueta en base a su posición. En otras tecnologías como Flash o PDF, las etiquetas se asociarán a los controles utilizando las características de accesibilidad incorporadas en los programas de creación de estos formatos.
45 de 74
Por último, en la nueva concepción de las WCAG 2.0, todos los elementos de la interfaz de usuario deben estar desarrollados de forma accesible siguiendo el criterio de éxito 4.1.2 (Nivel A), que establece que estos elementos deben tener un nombre y un rol que se puedan determinar programáticamente, y en caso de tener alguna propiedad o valor que pueda ajustarse, esto también debe poder hacerse de forma programática. Nota: no es necesario especificar estos parámetros para los elementos de interfaz nativos de HTML, como botones, cuadros de edición, casillas de verificación, botones de radio, etc., ya que están desarrollados desde su concepción de forma accesible, de tal modo que exponen esas propiedades directamente a los navegadores y productos de apoyo; del mismo modo, tampoco es necesario hacerlo para los controles nativos que se incluyen en Flash o en Acrobat, que también están desarrollados con criterios de accesibilidad de forma nativa. Mecanismos de navegación Al igual que en las WCAG 1.0, la nueva versión de las Pautas contiene diversos criterios relacionados con la accesibilidad de los mecanismos y elementos de navegación, desde los que se refieren a elementos concretos dentro de una página web, como enlaces, botones, barras o menús, a aquellos que se extienden a secciones del sitio o a la totalidad del mismo, como pueden ser el mapa del sitio, una interfaz común de navegación o las herramientas de búsqueda. Objetivo de los vínculos / enlaces WCAG 2.0 el criterio 2.4.4 (Nivel A) establece que el propósito de cada vínculo debe poder determinarse programáticamente sin ambigüedad. En este sentido, las nuevas Pautas son menos restrictivas que las anteriores, y se entiende que el propósito del vínculo puede ser deducido no sólo del texto del mismo, sino también uniéndolo a su contexto, por lo que ahora los vínculos del tipo “ver más” o “más información” se pueden considerar correctos. No están permitidos enlaces del tipo banner publicitario que busca llamar la atención sin desvelar la información, para que el usuario sienta la curiosidad de acceder al contenido que se oculta detrás del banner. También podemos relacionarlo con el criterio 1.1.1 (Nivel A), relativo a las alternativas textuales para los elementos no textuales. Organización y estructura de la navegación Nos centramos en menús de navegación globales / comunes a todas las páginas. En las Pautas WCAG 2.0 existen varios criterios de éxito que hacen alusión a la localización de la información y al uso de los mecanismos de navegación de una forma predecible por parte del usuario. En primer lugar, el criterio de éxito 2.4.5 (Nivel AA) indica que deben proporcionarse múltiples vías para que los usuarios puedan localizar una página web dentro de un conjunto de páginas, salvo cuando dicha página sea el resultado de un paso que forma parte de un proceso. Sin embargo, este criterio de éxito no establece ningún requisito sobre mecanismos concretos que
46 de 74
deban usarse, sino que deja abierta la posibilidad de usar distintos sistemas en función de la complejidad y las necesidades del sitio. Algunos de estos sistemas podrían ser:
En sitios pequeños, puede bastar un simple enlace a la página principal, que permite acceder al resto de las páginas del sitio, o un menú de navegación visible en todas las páginas con esa misma función. Si la complejidad del sitio aumenta, un enlace en todas las páginas al mapa del sitio o a una tabla de contenidos puede ayudar a localizar la información rápidamente. En sitios de gran complejidad se puede incluir un sistema de búsqueda mediante palabras clave o de cualquier otro tipo.
Existe relación con:
El criterio de éxito 3.2.3 (Nivel AA) hace referencia a la consistencia en la navegación, indicando que aquellos mecanismos que se repiten en múltiples páginas sigan siempre el mismo orden relativo cada vez que aparezcan, a menos que sea el usuario el que cambie dicho orden. El criterio 3.2.4 (Nivel AA) establece que deben identificarse de forma consistente aquellos elementos que tienen la misma funcionalidad a lo largo de varias páginas.
Redirecciones automáticas Enmarcado dentro del criterio de éxito 2.2.1 (Nivel A), que con un carácter mucho más amplio hace referencia a la capacidad del usuario para ajustar cualquier límite de tiempo existente en el contenido web. Esto significa que el usuario debe poder desactivar, ajustar o extender el tiempo límite establecido, salvo en los casos donde este límite temporal sea fundamental para la correcta interpretación del contenido. (Por ejemplo en un examen). Por otro lado, es de señalar que las Pautas WCAG 2.0 contemplan como válido el uso de redirecciones automáticas con tiempo nulo, esto es, en aquellos casos donde la redirección se produce inmediatamente al entrar en la página, por ejemplo a través de un elemento meta de auto-refresco o mediante una función de JavaScript, entre otros métodos. Ventanas pop-up (emergente) La nueva versión de las Pautas considera la apertura de este tipo de ventanas como “cambios de contexto”, a los que hace referencia en los criterios de éxito 3.2.1 y 3.2.2, ambos de nivel A, relativos a los cambios de contexto que se producen cuando un elemento toma el foco o cuando el usuario realiza alguna entrada de datos. Por otra parte, las WCAG 2.0 mencionan específicamente en el criterio de éxito 3.2.5 (Nivel AAA) varias técnicas de suficiencia de apertura de nuevas ventanas, en las que se avisa al usuario de dicha apertura; en este sentido, se considera válido el uso del atributo target
47 de 74
siempre que el texto del vínculo avise de la apertura de la nueva ventana, así al igual que otras técnicas de mejora progresiva utilizando JavaScript no invasivo. Metadatos En WCAG 2.0 no es un requisito pero favorece el cumplimiento proporcionando información sobre páginas alternativas, diferentes formas de acceder a la información o recursos que faciliten la navegación. Por otro lado, el criterio de éxito 2.4.2 (Nivel A) establece que las páginas deben tener un título que describa su función o contenido. Si bien este criterio no se refiere específicamente al elemento title de las páginas (que se puede considerar un metadato), se considera que proporcionar un título descriptivo mediante este elemento es una técnica de suficiencia válida para este criterio. Documentos PDF Teniendo en cuenta que las Pautas WCAG 2.0 son tecnológicamente neutrales como hemos indicado ya, y que actualmente los PDF tienen soporte para la accesibilidad, no existe en realidad ninguna diferencia entre los documentos PDF y cualquier otro contenido, tratándose únicamente de una tecnología distinta de HTML + CSS. En este sentido, son de aplicación la totalidad de las Pautas WCAG 2.0, e incluso es posible incrustar multimedia dentro de documentos PDF, siempre que se haga de forma accesible. En cualquier caso, dado que el uso más común de PDF es la creación de documentos eminentemente textuales, son de especial relevancia los criterios relativos al marcado estructural de los contenidos (tratados en el apartado Encabezados, listas, citas y otros bloques de texto), así como los concernientes al uso de Imágenes o Tablas de datos. Otro uso frecuente de PDF es la creación de formularios rellenables por el usuario. Veamos muy por encima un resumen de consideraciones, recomendaciones y referencias para poder ampliar sus conocimientos sobre esta tecnología: Consideraciones para documentos PDF. Tiene que ser posible el manejo de forma independiente del tipo de dispositivo y deben ser compatibles con programas lectores de pantalla. No se deben de utilizar como excusa para no hacer documentos HTML+CSS. No abusar de los documentos PDF, use estos en determinados caso, como por ejemplo:
Folletos, documentos legales o similares, destinados principalmente a ser impresos y que deben mantener un formato predeterminado. Información que por su naturaleza es muy extensa (por ejemplo un boletín oficial, unas actas, etc.), ya que es conveniente proporcionar una versión descargable e imprimible que facilite la lectura fuera de pantalla.
En este caso sería interesante proporcionar un esquema o resumen del PDF. Referencia: 48 de 74
Crear documentos PDF accesibles con Adobe Acrobat http://www.adobe.com/es/accessibility/ Recomendaciones Son muy similares a las páginas Web accesibles (HTML). Algunas de ellas:
Proporcionar texto alternativo para todos los elementos no textuales. Proporcionar de forma textual la expansión de una abreviatura o acrónimo la primera vez que aparezca en el documento. Escribir con un lenguaje claro y sencillo. Especificar claramente el destino de los enlaces. No hacer enlaces con un tamaño demasiado reducido que presenten dificultades para las personas con problemas motrices a la hora de pulsarlos. Usar elementos estructurales y aplicarles estilos en lugar de modificar visualmente el texto directamente. No basar la información sólo en el color. Asegurarse de que toda la información disponible con color también lo esté si el color no está disponible. Aplicar suficiente contraste al documento. Un documento PDF escaneado sin haber aplicado el proceso OCR (Reconocimiento óptico de caracteres) no es un documento accesible. Deben de usar etiquetado (TAGGED) para poder presentar un menú que presente una estructura de datos usando cabeceras, pies, listas y el resto de etiquetas. Presentar un orden lógico de lectura. Etc.
Para completar esta información podría ver documentación sobre accesibilidad en PDF´s en http://administracionelectronica.gob.es/ disponible en el área de Accesibilidad del Portal de Administración Electrónica (PAe). http://administracionelectronica.gob.es/PAe/accesibilidad/documentacion http://administracionelectronica.gob.es/pae_Home/pae_Estrategias/pae_Accesibilida d/pae_documentacion/pae_eInclusion_Accesibilidad_de_PDF.html Documentos Word Al igual que en los documentos PDF, podemos aplicar las Pautas WCAG 2.0 como para cualquier otro. Aquí vamos a ser más breves y no repetiremos pues aplicaríamos casi todo lo comentado para los documentos del tipo PDF. Para las nuevas versiones de Microsoft Word (Office 2010) podemos obtener un informe de accesibilidad de un documento.
49 de 74
Imagen de cómo podemos validar la accesibilidad en un documento Word.
El informe es útil pues te va llevando a cada uno de los problemas. Comenta como puedes solucionarlos.
Imagen instantánea del informe de validación de accesibilidad desde Word 2010
50 de 74
Como referencia podemos tomar la siguiente dirección: https://support.office.com/es-es/article/Crear-documentos-Word-accesibles-d9bf3683-87ac47ea-b91a-78dcacb3c66d Adobe Flash Del mismo modo que con los documentos PDF, la tecnología Adobe Flash se trata en las Pautas WCAG 2.0 como cualquier otro contenido web, ya que actualmente esta tecnología dispone de soporte para la accesibilidad. Por lo tanto, son igualmente aplicables todos los criterios de las Pautas WCAG 2.0, no siendo necesario proporcionar una alternativa al Flash siempre y cuando éste se haya desarrollado de manera accesible. Dado que Flash puede usarse para desarrollar sitios web completos, no es posible concretar unos criterios que tengan mayor importancia que otros. No obstante, y tan sólo a modo de recordatorio, se citan a continuación algunos criterios de especial aplicación en determinados casos de uso de la tecnología Flash:
Animaciones sencillas sin interacción por parte del usuario: pueden aplicar los criterios relativos a Imágenes, Multimedia o Destellos, parpadeos y movimiento. Inclusión de vídeo o audio: aplicarán los criterios sobre Multimedia, Destellos, parpadeos y movimiento o Independencia del dispositivo. Aplicaciones con interacción del usuario: son de especial importancia los criterios sobre Objetos programados, Independencia del dispositivo o Formularios.
Como incluir video y audio mediante tecnología Flash Se ha de realizar mediante el elemento OBJECT para incluir el reproductor flash encargado de cargar el video. La ruta al objeto flash se indica mediante el elemento PARAM “movie” en lugar de “src”. Ya que los reproductores Flash utilizan un formato de video propio de Adobe (FLV), se recomienda proporcionar los enlaces de descarga alternativos en otros formatos estándar de video como puede ser MPG o AVI.
Descargar el vídeo de prueba
A tener en cuenta:
51 de 74
El código empleado debe de ser compatible con todos los navegadores. El código debe de estar bien formado, sin errores en el anidamiento de los elementos, apertura y cierre de etiquetas. (Gramaticalmente válido). Se ha de tener especial cuidado con el código ofrecido por Webs para incrustar video pues puede no ser un código HTML válido. Asegurar que se usa el elemento OBJECT para incrustar el vídeo, en detrimento del elemento EMBED. Cerrar adecuadamente los elementos vacíos en XHML, incluyendo para ello un espacio y el carácter “/” al final de su declaración. Las últimas versiones de Flash tienen soporte para la creación de subtítulos.
Esta tecnología la han catalogado como la más adecuada para incluir subtítulos, ya que por una parte se trata de una de la solución más extendida y con mayor soporte de subtitulado, y por otra, permite una fácil integración de subtítulos a través de ficheros externos así como la activación y desactivación de los mismos por parte del usuario, lo que a su vez reduce los costes en tiempos de desarrollo al no ser necesario implementar distintas versiones del mismo vídeo. El problema es que se depende de la presencia y soporte del plugin de Flash en los navegadores para poder reproducir el vídeo. Pero HTML5 será la mejor opción. Se emplea el elemento TRACK para proporcionar los subtítulos. Este elemento permite incluir varias pistas adicionales al vídeo, como metadatos, información de división en capítulos, subtítulos, etc. El problema aquí está en que existen navegadores que no soportan esta versión de HTML. Para incluir un reproductor Flash de audio se utilizará el mismo código que el empleado para un reproductor de vídeo, dado que el tipo de formato del objeto es el mismo (Flash).
Descargar el audio de prueba
Para incrustar un audio en HTML 5 se utilizará el elemento AUDIO, definiendo la ruta y el formato del archivo o fuente a reproducir mediante los atributos src y type respectivamente. Añadiremos como alternativa al audio un enlace para su descarga, que se incluirá fuera del elemento AUDIO para que esté disponible tanto para los usuarios que no pueden reproducir el audio como para los que sí pueden hacerlo.
Descargar el audio de prueba
52 de 74
Accesibilidad para un audio La creación e incorporación de elementos de audio en un sitio web de forma completamente accesible constituye un proceso complejo en el que se pueden llegar a invertir grandes cantidades de tiempo y esfuerzo, por lo que resultará importante priorizar tareas en la ejecución de dicho proceso. Así, en primer lugar se ha de ofrecer la transcripción textual, ya que al tratarse de una alternativa basada en texto puede ser representada a través de cualquier modalidad sensorial (por ejemplo, visión, oído o tacto) e interpretada de diversas formas por los productos de apoyo (leída en voz alta, presentada visualmente o convertida a braille), lo que ayuda a satisfacer las necesidades de distintos grupos de usuarios. Una vez que se ha proporcionado la transcripción textual, y con el fin de mejorar la accesibilidad del elemento de audio, es igualmente recomendable abordar progresivamente los aspectos relativos a la interacción (control de reproducción, uso independiente de dispositivo de entrada y tabulación adecuada). Referencia: Las prácticas correctas para un diseño Flash accesible http://www.adobe.com/es/accessibility/ Herramientas y métodos de validación de accesibilidad Web Para los procesos de verificación y revisión del cumplimiento de las pautas de accesibilidad WCAG 2.0 es conveniente disponer de herramientas de validación automática que provean de mecanismos de revisión directa de aquellas pautas que puedan ser validadas sin la intervención de un técnico. Herramientas Online o o o o o o o o o o
Taw (http://www.tawdis.net/) Wave CynthiaSays Examinator Deque Worldspace Free Analysis AccessMonitor Beta Check the Accessibility SortSite Nibbler Functional Accessibility Evaluator
Herramientas Offline o o o o
aDesigner Sortsite Total Validator Pista accesibilidad
Plug-ins
53 de 74
o o
Wave Hera
Chequeo del contraste del color Existen varias herramientas para comprobar el contraste del color, veamos un ejemplo con el titular de una noticia en CARM.es
Imagen de como obtenemos el color usado en el título de la noticia usando por ejemplo el navegador Google Chrome.
Una vez tengamos los colores para analizar iremos a la dirección siguiente para analizar el contraste y color donde vamos a obtener si pasa los criterios y nivel de conformidad WCAG 2.O. http://snook.ca/technical/colour_contrast/colour.html#fg=004573,bg=FFFFFF
Imagen instantánea del resultado de realizar un check de color y contraste.
54 de 74
Recomendación tras evaluación Total Validator es un validador de HTML, un validador de accesibilidad, un corrector ortográfico y un comprobador de enlaces rotos, todo en una sola herramienta, lo que permite un solo clic de validación de su sitio web. Se puede descargar la herramienta gratuita y validar sus páginas web. https://www.totalvalidator.com/ Como solución alternativa me quedaría con Examinator, que además está en español.
Resultado y beneficios. Los siguientes beneficios se derivan de las actuaciones de cara a la accesibilidad: Doble A. El objetivo específico de llegar al nivel doble-A de conformidad con las normas de accesibilidad. Mejora del canal de comunicación web para llegar a discapacitados. El primer resultado es una ostensible mejora del canal de comunicación web para el colectivo de personas con discapacidad. Ampliado el espectro de ciudadanos al que llega la web. Se amplía el número de usuarios que pueden tener acceso a la web de la organización y éste tiene que ser siempre un objetivo que persigan tanto administraciones públicas como empresas privadas en cualquiera de sus iniciativas. Mejor acceso desde dispositivos diversos. Otro de los resultados que se puede obtener es un acceso mejor desde dispositivos diversos, como pueden ser distintas versiones de navegadores, dispositivos con limitaciones, dispositivos que utilizan sólo algún canal sensorial, etc., como consecuencia de que las normas de accesibilidad recomiendan vías alternativas de la información, acceso a la información desde diversos dispositivos, evitar el uso de marcas HTML no recomendadas por el W3C (World Wide Web Consortium), etc. Código HTML de mayor calidad. Independientemente del objetivo de la accesibilidad, como resultado de todo el proceso de revisión de calidad y de la aplicación de las recomendaciones de las directrices de accesibilidad se ha obtenido un código HTML en las páginas que componen nuestro sitio web de mayor calidad. Ajuste al marco legal. Se consigue ajustarse al marco legal, aunque podríamos considerar que la accesibilidad debería considerarse como una responsabilidad de las organizaciones más que una obligación legal. Camino recorrido hasta cumplir algunos criterios de la triple A y todos los de doble A, ya que todas tareas que se han realizado de concienciación de usuarios, ajuste de la organización, definición de métodos de revisión y control de calidad, procedimientos, etc. En definitiva, dar un paso más para conseguir una mejor organización.
55 de 74
Mejora continua. El trabajo de la accesibilidad es un trabajo de mejora continua al que hay que dar continuidad realizando trabajos para asegurar la continuidad. Estar atentos a cambios. Habrá que estar atentos a cambios de especificaciones en las recomendaciones de accesibilidad de la WAI, seguir trabajando en mejorar nuestros procesos de aseguramiento de la calidad, subsanar los posibles problemas que pudiesen surgir, etc.
El gestor de contenidos IGES ¿Qué es un CMS? Es un Sistema de gestión de contenidos (Content Management System, en inglés, abreviado CMS) permite la creación y administración de contenidos principalmente en páginas web. Consiste en una interfaz que controla una o varias bases de datos donde se aloja el contenido del sitio. El sistema permite manejar de manera independiente el contenido y el diseño. Así, es posible manejar el contenido y darle en cualquier momento un diseño distinto al sitio sin tener que darle formato al contenido de nuevo, además de permitir la fácil y controlada publicación en el sitio a varios autores. El Gestor de contenido IGES mantiene varias plantillas para varios portales de la CARM como pueden ser: http://www.carm.es, http://efiapmurcia.carm.es, https://sede.carm.es, http://www.sefcarm.es, http://planiris2020.carm.es, etc. Es multiportal. Veamos un gráfico donde reducimos mecanismos pero que nos ayudará a entender su funcionamiento en cuanto a perfiles y equipos.
Imagen que muestra un diagrama del Gestor de contenidos IGES (Autores, Supervisores, Otros roles, equipo de desarrollo web)
IGES no es solo un CMS sino que gestiona y mantiene otros procesos que no son típicos de un gestor como pueden ser: solicitudes de cursos, Reserva de aulas, procedimientos y otros
56 de 74
desarrollos de la Guía de servicios, encuestas y encuestas multipregunta, contenidos especiales para la integración de datos de otros portales (procesos proxy), motor de reportes en formato Word nativo y otras muchas ventajas. Estas y otras funcionalidades se han ido desarrollando a necesidad de la CARM siendo un motor abierto en continuo desarrollo y mantenimiento. Los documentos o contenidos creados se depositan en una base de datos central donde también se guardan el resto de datos de la web, cómo son los datos relativos a los documentos (versiones hechas, autor, fecha de publicación y caducidad, etc.), datos y preferencias de los usuarios, la estructura de la web (Clasificación), etc. IGES cuenta con varios de estos tipos de contenidos entre los que vamos a ir nombrando y creando a modo de práctica para ver hasta dónde puede afectar la accesibilidad a estos. Entrada al Gestor de pruebas desde la dirección: https://iges.carmpru.es
Entrada al Gestor de Contenidos IGES desde el entorno de pruebas.
Ruta de trabajo: http://www.carmpru.es/web/pagina?IDCONTENIDO=22502&IDTIPO=100&RASTRO=c$m Usuario: aci00 / aci00 Contenido Archivo Una vez validados en IGES, tenemos un menú en la parte izquierda desde donde podremos crear cada uno de los contenidos sobre los que tengamos permiso para poder hacerlo. Elegiremos la opción de Archivos > Insertar Archivo Cumplimentaremos los datos iniciales antes de subir el fichero en cuestión.
57 de 74
Imagen inicial de cumplimentación de datos para cualquier tipo de contenido.
Aceptaremos la opción y entraremos a la ficha para introducir las características del tipo de contenido seleccionado. En este nuevo mantenimiento el menú de la izquierda ha cambiado ofreciendo esta vez una serie de acciones que podremos realizar para nuestro contenido.
Imagen ficha general del contenido archivo. Se muestra el menú de acciones a la izquierda.
Para poder subir el fichero seleccionamos “Modificar”
58 de 74
Imagen que muestra el botón “Seleccionar archivo” desde donde se puede seleccionar el fichero para poder subir a base de datos.
La siguiente opción sería poder clasificar este contenido en la estructura de datos deseada. En nuestro caso un menú habilitado para ello como vemos en la imagen.
Imagen que muestra el mantenimiento de clasificar
En la siguiente opción de menú obligatoria (marcadas en rojo las acciones obligatorias) podremos obtener una página.HTML sobre la cual podremos hacer un test de accesibilidad.
59 de 74
Para descargar la herramienta en versión descargable de TAW3 (WCAG 1.0) se ha de realizar desde http://www.tawdis.net/tools/accesibilidad/desktop/?lang=es donde tendremos que cumplimentar un formulario de contacto. Es totalmente gratuita.
Imagen test de accesibilidad de la herramienta TAW3 (WCAG 1.0)
Tras descargar el fichero HTML lo que realmente estamos haciendo es evaluar la plantilla que tiene asignado el contenido. En este caso la plantilla por defecto “Detalle archivo”.
60 de 74
Imagen que muestra la opción de aplicar plantilla sobre un contenido de tipo archivo
¿Cómo realizamos entonces un test de accesibilidad sobre un documento PDF? Existen varias herramientas para ello que a continuación nombramos:
Adobe Acrobat Pro (es de pago) Check the Accessibility of a PDF Document PDF-Accessibility-Checker (PAC) Deque Worldspace Free Analysis Tingtun Checkers
Veamos cómo hacemos un test de accesibilidad con Adobe Acrobat Pro. Desde el menú “Avanzadas > Accesibilidad > Comprobación Completa”
Imagen instantánea del informe de accesibilidad generado por Adobe Acrobat Pro del fichero subido a IGES con anterioridad.
Como alternativa gratuita desde la dirección siguiente http://www.access-for-all.ch/en/pdfwerkstatt/pac-pdf-accessibility-checker.html podemos descargar una herramienta para poder 61 de 74
realizar test de accesibilidad a documentos PDF de forma local evitando que los ficheros suban a lugares externos.
Muestra el resultado del test del documento subido recientemente a IGES
Este documento es un documento escaneado y la mejor opción sería aplicar desde Adobe Acrobat Pro y desde el menú “Documento > Reconocimiento de texto OCR” para pasar todo lo reconoce como imágenes a texto de esta forma no solo tendríamos la oportunidad de tener un fichero accesible si no que reduciríamos su peso en Mbytes. En concreto el fichero seleccionado tiene muy mala calidad y es imposible mejorar. De los ficheros evaluados he conseguido algunos que parcialmente son accesibles con este software de test. Se puede incluir una ficha en el archivo de tal forma que podemos añadir el índice o dar alguna explicación sobre el archivo. Veamos un ejemplo:
62 de 74
Imagen que muestra como añadir texto en la ficha del archivo dado de alta en IGES
Para mostrar dicha ficha en el portal debemos modificar la plantilla por defecto en este caso seleccionamos la plantilla “Detalle archivo”
Imagen de como se muestra la ficha de un archivo mostrando la descripción escrita.
63 de 74
Contenido imagen El proceso es igual al del archivo, en este caso no repetiremos el procedimiento pero si vamos a ver algunos detalles interesantes.
Imagen que muestra como se ve un contenido de tipo imagen si tiene cumplimentado el campo descripción.
Veamos cómo afecta a los test de accesibilidad. Para WCAG 1.0 pasa las tres prioridades. Para WCAG 2.0 también cumple todo los criterios en el nivel AA.
64 de 74
Imagen que ofrece el resultado de un test de accesibilidad WCAG 2.0 que cumple los criterios de accesibilidad nivel AA.
Recuerde no añadir un texto alternativo como “imagen” trate de ser conciso; Imagine a una persona invidente o dificultades visuales en la situación en la que un lector de pantalla le está leyendo lo que lleva el atributo “title” y le dice “imagen”. Para los casos de gráficos como hemos visto o en caso de la misma similitud es interesante use el campo descripción para poder aportar toda la información necesaria. Contenido simples La operativa de cómo crear y clasificar para todos los contenidos es igual, en el caso de este tipo de contenido es donde más nos extenderemos por ser de formato libre donde las plantillas y mecanismos por parte del equipo de desarrollo pierden el control. Hemos creado un documento simple que con la ayuda de su editor incorporado HTML ( TinyMCE Version: 3.5.1.1) no se ajusta del todo a las normas WCAG 2.0; luego debemos llevar especial cuidado.
Imagen de un contenido simple usando el editor HTML y con la creación de una tabla simple de siete columnas y cinco filas.
A continuación vamos a realizar un test al contenido que hemos creado, para ello desde el programa Total Validator tendremos que introducir la URL del contenido u obtener el contenido desde el gestor para poder evaluar (dependiendo si lo tenemos publicado):
65 de 74
Imagen instantánea del informe de salida de la herramienta test Total Validator y una imagen de la tabla publicada.
Observamos que hemos obtenido dos errores de nivel A. Si hacemos clic sobre los enlaces que hacen referencia a P876 y P879, nos envía a una página donde encontramos unas columnas que nos indican (código, criterio y nivel, descripción). P876
P879
WCAG2 1.3.1 (A)] Proporcionar un Proporcionar un atributo descriptivo de resumen descriptivo de las tablas de compendio de tablas de datos complejas. datos complejas Esto debe ser una descripción adecuada y no una escueta. Ver http://www.w3.org/TR/WCAG20-TECHS/ … [WCAG2 1.3.1 (A)] Proporcionar una Usa la etiqueta de HTML . O los descripción de las tablas de datos atributos “title” o “summary” de la etiqueta
Vamos a solucionar desde el editor de IGES este problema; editamos el contenido y vamos a seleccionar toda la tabla y hacemos clic en el botón “Insertar una nueva tabla” una vez pulsado el icono se muestra una ventana donde nos encontramos dos pestañas; hacemos clic en la pestaña con nombre “Avanzado” y vamos a cumplimentar el campo con nombre “Resumen”, hacemos clic en “Actualizar” y “Aceptar” en la ficha del contenido. Lo que hemos realizado sin tener quizás conocimientos de HTML es aplicar el atributo “summary”. Lo podemos ver con la herramienta para desarrolladores que cuenta para ello Google Chrome pulsando F12.
66 de 74
Imagen que muestra una instantánea de la herramienta para desarrolladores de Google Chrome para poder ver el código HTML sincronizado con un objeto, en este caso una tabla.
Si volvemos a lanzar el test observaremos que hemos resuelto el problema de accesibilidad. Vamos a profundizar usando estilos donde observamos la importancia de la semántica en el código HTML (escribir bien HTML y según las reglas). Es de suma importancia separar los datos del lenguaje de presentación.
Imagen tomada desde el mantenimiento de un contenido simple donde se observa como modificar el atributo “Clase” de una tabla mediante el editor que proporciona IGES.
67 de 74
Tras modificar el contenido y probando a cambiar el valor del atributo “Clase” podemos observar lo poco que se ha modificado el lenguaje HTML y cuanto se ha modificado la presentación (valores: ficha, fichadatos).
Imagen instantánea del contenido publicado usando varios valores del atributo clase de la tabla.
Los contenidos simples por su versatilidad son los contenidos más propensos a tener problemas con la accesibilidad, vemos ahora un ejemplo de cómo insertar una imagen dentro de un contenido simple. Podemos decir que un contenido simple es como un documento Word. Desde el botón “Insertar / editar imagen” hacemos clic, nos abrirá una ventana donde podremos indicar la dirección de la imagen o buscar. En nuestro caso vamos a buscar una imagen, hacemos clic en el botón “buscar” cumplimentamos el campo nombre con la información a buscar “Estadística” y hacemos clic en “Buscar”, ahora seleccionamos la imagen deseada y hacemos clic en “Seleccionar”. Volvemos a la ventana “Insertar / editar imagen” donde podremos cumplimentar algunos valores para los campos como alineación y hacemos clic en el botón “Insertar”.
68 de 74
Imagen que muestra la secuencia de instantáneas para buscar y añadir una imagen.
Imagen que muestra la instantánea de un contenido simple con accesos a contenidos de imágenes con descripción ampliada de la misma.
69 de 74
A continuación vamos a ver un contenido simple donde se hace uso de títulos h1, h2, h3 párrafos, uso de listas, enlaces e imágenes. Observamos que el contenido simple ofrece la posibilidad de ampliar la información de la primera imagen a través del enlace “Ver información detallada del gráfico” que nos lleva al contenido imagen donde se da una información detalla. En segundo lugar se ofrece una lista donde se informa del uso según otros datos y que permite ir al contenido imagen donde se detalla mucho más la información mediante un gráfico y explicación de datos. Otros contenidos y Plantillas El resto de contenidos del portal están gestionadas por el equipo de desarrollo que mantiene IGES, estas plantillas ya son testeadas en cuanto a accesibilidad y diseño se refiere por este equipo. Esta vez el usuario no escribe texto HTML si no que el usuario introduce datos y el equipo de desarrollo obtiene los datos escribiendo el código HTML y usando estilos para mostrar la información. Por ejemplo el tipo de contenido encuesta.
Imagen que muestra la ficha del tipo de contenido encuesta y como se ve publicada.
70 de 74
Multiportales El gestor de contenidos IGES, permite usar un mismo contenido en varios portales por su método de clasificación. ¿Cómo se muestra con distinto aspecto entonces? Cada portal tiene su hoja de estilos propia, cuando guardamos la información se hace en un mismo contenedor de datos usados por todos. Como los contenidos en teoría están correctamente escritos en lenguaje HTML sin contener nada de estilos y usando HTML semántico esto hace posible que las hojas de estilo CSS y plantillas sean las encargadas de la presentación correcta de cada uno de los portales.
Referencias y bibliografía W3C WCAG 2.0 http://www.w3.org/TR/WCAG20/ Traducción de la WCAG 2.0 http://www.sidar.org/traducciones/wcag20/es/ PAE Accesibilidad http://administracionelectronica.gob.es/pae_Home/pae_Estrategias/pae_Accesibilida d/pae_normativa/pae_eInclusion_Normas_Accesibilidad.html Evaluación de la WCAG 2.0 y herramientas (Olga Contreras) http://olgacarreras.blogspot.com.es/2007/02/wcag-20.html http://olgacarreras.blogspot.com.es/2012/07/nueva-version-de-la-norma-une139803.html
Glosario de Términos
AJAX: Acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML). AVI: (siglas en inglés de Audio Video Interleave) es un formato contenedor de audio y video lanzado por Microsoft en 1992. CMS: Sistema de gestión de contenidos. CSS: Hoja de estilos en cascada. CTS: (Common Technical Specifications) Especificaciones técnicas comunes. FLV: Flash Video. HTML: Siglas en inglés de HyperText Markup Language (lenguaje de marcas de hipertexto). MPG: Nombre de un grupo de estándares de codificación de audio y vídeo. OCR: El reconocimiento óptico de caracteres. RAE: Real Academia Española. UNED: Universidad Nacional de Estudios a Distancia.
71 de 74
W3C: World Wide Web Consortium (especificaciones, líneas maestras, software, herramientas para guiar a la red a su máxima productividad). WAI: Web Accessibility Initiative. WYSIWYG: What You See Is What You Get. Lo que ves es lo que obtienes. XHTML: Siglas del inglés eXtensible HyperText Markup Language. XHTML es básicamente HTML expresado como XML válido. XML: Siglas en inglés de eXtensible Markup Language ("lenguaje de marcas Extensible")