Usable y accesible

Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

2012-04-08T21:39:00.002+02:00

El 27 de marzo (de 2012) el W3C/WAI publicó el primer borrador de la "Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)" (según la traducción que hace la nota de prensa del W3C España), en inglés "Website Accessibility Conformance Evaluation Methodology 1.0".

Este borrador de trabajo es un primer esbozo y, como se indica, puede ser actualizado, reemplazado o quedar obsoleto en cualquier momento. Por otra parte algunas de sus secciones están todavía sin desarrollar. Sin embargo, es un documento de gran interés para los consultores de accesibilidad que solo está disponible en inglés. El objetivo de este artículo es difundirlo y resumirlo en castellano, actualizándolo a medida que se publiquen nuevas versiones.

Hasta el 27 de abril se pueden enviar comentarios sobre este primer borrador, que son públicos y se pueden consultar en "public-wcag-em-comments@w3.org Mail Archives".

WCAG-EM pretende proporcionar una metodología armonizada internacionalmente para la evaluación de sitos web (incluyendo aplicaciones web y sitios web para dispositivos móviles) en conformidad con las WCAG 2.0

Es independiente del tamaño del sitio web o de la tecnología con la que se construye el mismo. Es además independiente de herramientas de evaluación de accesibilidad, navegadores web o productos de apoyo concretos.

Debido a que generalmente no es factible ni conveniente evaluar cada una de las páginas de un sitio web, resulta fundamental emplear un método fiable para determinar la conformidad global de un sitio web. En el documento se especifican los pasos concretos para definir el alcance de la evaluación, seleccionar una muestra representativa, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

Esta metodología se utiliza para una exhaustiva evaluación de la conformidad de sitios web de acuerdo sobre las WCAG 2.0 Para la revisión preliminar de un sitio que permita identificar los errores más evidentes recomiendan "Preliminary Review of Websites for Accessibility", publicado en la web de la WAI

La metodología se aplica siempre a un sitio web completo sin exclusiones u omisiones de páginas que sirvan a la finalidad y funcionalidad del sitio, y que por tanto forman parte de la navegación, el diseño y los procesos completos del sitio. Sin embargo sí que se permite aplicar a ámbitos claramente separables de un único sitio web, como podría ser la parte pública y la parte privada del mismo.

Se especifica el conocimiento que debería tener el evaluador y que se puede resumir en un profundo conocimiento de las WCAG 2.0, sobre cómo evaluar la accesibilidad y sobre el diseño de web accesibles, y por tanto conocedores de los siguientes recursos:

"Evaluating Websites for Accessibility", una suite de documentos de la WAI que constituye la metodología a seguir para evaluar la accesibilidad de un sitio Web y asegurar la calidad de los procedimientos. Lo traté con detenimiento en el artículo "Metodología para la evaluación de la accesibilidad Web: 'Evaluating Web Sites for Accessibility' de la WAI "
Web Content Accessibility Guidelines (WCAG) 2.0, y todos los documentos asociados ("How to Meet WCAG 2.0 (Quick Reference)", "Understanding WCAG 2.0" y "Techniques for WCAG 2.0")
Accessible Web Design (Designing for Inclusion), y que incluye documentos como: "Essential Components of Web Accessibility", "How People with Disabilities Use the Web", "Developing Websites for Older People", "Web Content Accessibility and Mobile Web" o "Involving Users in Web Projects for Better, Easier Accessibility".

La metodología puede ser llevada a cabo por un evaluador de forma individual o por un equipo de revisión. Se indica que la participación de personas con discapacidad y de personas mayores, aunque no es obligatoria, ayuda a identificar barreras de accesibilidad adicionales.

Tras esta introducción, que se corresponde con un resumen de los apartados 1 y 2 de la WCAG-EM, en el apartado 3 se definen los pasos del procedimiento de evaluación.

Se indica que los detalles de estos pasos pueden variar ligeramente dependiendo del tipo de sitio, el propósito de la evaluación, y el proceso utilizado por el evaluador. Algunos de los pasos también pueden solaparse o llevarse a cabo en paralelo, pero es importante que se tengan en cuenta todos los pasos para garantizar una evaluación fiable. También es importante documentar claramente cada paso para garantizar unos resultados verificables y justificar la declaración de conformidad.

Los pasos son:

Paso 1. Definir el alcance de la evaluación

El alcance se debería definir de acuerdo con quienes han encargado la evaluación para asegurar unas expectativas comunes. Se divide en los siguientes subpasos:

Paso 1a: definir el alcance exacto sin contradecir las limitaciones que se han indicado en el ámbito de aplicación de la metodología. Esto puede requerir conocer la propiedad o el proceso de desarrollo de algunas partes del sitio, y tener que llevarse a cabo a la vez que el paso 2 (navegar por el sitio web)
Paso 1b: definir el objetivo de la evaluación, que puede ser:
- Basic conformance: sólo se identifica si un sitio es o no conforme sin proporcionar información adicional (adecuado por ejemplo si solo se quiere verificar la declaración de conformidad)
- Detailed review: identifica si un sitio web es o no conforme y se proporciona más información sobre los errores identificados, como puede ser el número de errores y su ubicación.
- In-Depth analysis: identifica si un sitio web es o no conforme y se analizan con detalle los errores identificados, incluyendo la descripción de los errores y las sugerencias de soluciones.
- Other: se puede establecer otro objetivo pero debe definirse claramente y con exactitud.
Paso 1c: definir cuál el nivel de adecuación (A, AA, AAA) que se va a evaluar, que puede ser AAA aunque el objetivo a alcanzar sea el nivel A o AA (para tener una visión más completa de la accesibilidad del sitio o para mejorar tipos de contenidos concretos: las tablas, formularios, etc.)
Paso 1d: definir el contexto de uso del sitio web, quién lo usa y cómo lo usa. Es importante identificar si es un sitio público o no (por ejemplo una intranet) Se debe definir el conjunto mínimo de navegadores web y productos de apoyo con los que se va a realizar la evaluación (y que puede variar significativamente en función de si es un sitio público o una intranet, según el idioma, la ubicación geográfica o el público objetivo del sitio)
Paso 1e (opcional): definir las técnicas a utilizar que pueden ser las definidas en "Techniques for WCAG 2.0" pero no obligatoriamente estas. Este paso se puede superponer con el paso 2 (explorar el sitio web), y en todo caso las técnicas exactas que se han usado para evaluar la conformidad con las WCAG 2.0 deben estar documentadas en el paso 5 (informar de los resultados de la evaluación)

Paso 2. Explorar el sitio web

El evaluador debe poder acceder a todas las páginas. Este paso permite comprender mejor el uso y funcionalidad del sitio; y además ayuda a identificar las páginas relevantes o con problemas que son candidatas a incluirse en la muestra a analizar.

Se divide en los siguiente subpasos:

2a: identificar las páginas clave del sitio. Se indican como tales: la home, la página de login y otras páginas de entrada; el mapa web, la/s página/s de contacto, ayuda, información legal; las páginas similares que son enlazadas desde todas las páginas (cabecera, pie o menú de navegación); así como las diferentes plantillas
2b: identificar las funcionalidades clave del sitio, incluyendo las tareas que los usuarios deben llevar a cabo para realizar una funcionalidad (por ejemplo, "selección y compra de un producto", "registrar una cuenta en el sitio", etc.)
2c: identificar diferentes tipos de páginas (no plantillas como en el paso 2a), con diferentes estilos, layout, estructuras y funciones, que a menudo son generadas por diferentes plantillas y escritas por diferentes personas:
- Páginas web con diferentes estilos, layout, estructura, navegación, interacción y diseño visual;
- Páginas con contenido diverso, como los formularios, tablas, listas, encabezados, multimedia y scripts;
- Páginas con diferentes componentes funcionales, tales como selector de fechas, lightbox, slider, y otros;
- Páginas que utilizan diversas tecnologías, tales como HTML, CSS, Flash, JavaScript, PDF, Silverlight y WAI-ARIA;
2d: identificar las tecnologías de las que se depende (según el concepto de las WCAG 2.0: el contenido no puede ser conforme si dicha tecnología se desconecta o no es soportada), que pueden ser HTML, CSS, Flash, JavaScript, PDF, Silverlight, WAI-ARIA, SMIL, SVG, etc.

Paso 3. Seleccionar una muestra representativa

Se debe seleccionar una muestra de páginas que represente a todo el sitio. El tamaño de la muestra dependerá del tamaño y complejidad del sitio.

Los subpasos de los que se compone son:

3a: incluir las páginas principales del sitio. Tienen que formar parte de la muestra todas las plantillas y todas las páginas relevantes (la home, la página de login y otras páginas de entrada; el mapa web, la/s página/s de contacto, ayuda, información legal; las páginas similares que son enlazadas desde todas las páginas como la cabecera, pie o menú de navegación) identificadas en el paso 2a.
3b: incluir al menos dos páginas diferentes (si procede) de las identificadas en:
- el paso 2b: páginas con funcionalidades clave
- el paso 2c: diferentes tipos de páginas
- el paso 2d: páginas con diferentes tecnologías
En sitios complejos puede hacer falta seleccionar más de dos páginas de cada tipo; otras veces una misma página puede ser representativa de varias de estas características.
Debería seguirse siempre este proceso de selección, aunque en re-evaluaciones puede ser útil seleccionar parte de la muestra de una evaluación anterior para comparar el resultado.
3c: incluir otras páginas relevantes para la accesibilidad o las personas con discapacidad:
- Páginas con información y ayuda sobre el uso de la página web o pertinentes para la accesibilidad;
- Páginas especialmente populares y las que se utilizan comúnmente como páginas de entrada al sitio;
- Mensajes de error del servidor web (por ejemplo, la página de error 404) o de una aplicación web;
3d: incluir en la muestra procesos completos. Es decir, todas las páginas de un proceso, no se puede seleccionar solo una página del proceso.

Paso 4. Auditar la muestra seleccionada

Esta sección no está todavía redactada. Los subpasos propuestos (aun sin desarrollar) son:

4a: comprobar para la más amplia variedad de casos de uso
4b: utilizar cuando sea posible las "WCAG 2.0 Techniques"
4c: evaluar la accesibilidad según las técnicas utilizadas y las características de accesibilidad identificadas
4d (opcional): archivar las páginas auditadas (en un pantallazo, guardando una copia, etc.) para futuras referencias o controversias.
4e (opcional): registrar las herramientas y métodos de evaluación

Paso 5. Informar de los resultados de la evaluación

Esta sección no está todavía redactada. Los subpasos propuestos (aun sin desarrollar) son:

5a: proporcionar documentación para cada paso
5b (opcional): proporcionar una declaración de accesibilidad
5c (opcional): proporcionar una puntuación
5d (opcional): proporcionar información sobre los errores identificados
5e (opcional): proporcionar sugerencias para solucionar los errores
5f (opcional): proporcionar un informe legible por máquinas (como EARL)

Plantilla para el informe

El objetivo del apéndice C es ofrecer un ejemplo de plantilla, con la idea de tener tres diferentes niveles de presentación de informes. Se ofrece un ejemplo por cada uno de los objetivos posibles de la evaluación especificados en el paso 1b.

En el caso más completo, los contenidos que debería ofrecer el informe serían:

Resumen
Terminología
Fecha de la declaración de conformidad y validez en el tiempo
Fecha de la evaluación
Persona que hizo la evaluación
Directrices, versión y URI: "Web Content Accessibility Guidelines 2.0 en http://www.w3.org/TR/2008/REC-WCAG20-20081211/"
Nivel de conformidad testeado (A,AA,AAA) y si dicho nivel de conformidad es satisfecho
Descripción concisa de las páginas, con una lista de URI para las cuales se hace la declaración, indicando si los subdominios están incluidos en la declaración
Lista de los criterios de conformidad cumplidos más allá del nivel de conformidad alcanzado
Descripción del sitio que ha sido evaluado, incluyendo una descripción general de lo que está y no está incluido
Listado de las tecnologías de las que se depende y una lista de aquellas que están excluidas de la evaluación (pero disponibles en el sitio evaluado)
Declaración parcial de conformidad (si se trata de una evaluación de conformidad)
Resultados, por cada directriz y criterio de conformidad, indicando:
- si lo pasa o no
- la frecuencia y alcance del problema, si se da en toda la muestra o el listado de páginas en el que se encuentra
- descripción de los problemas existentes y las barreras para los usuarios o enlaces a estas descripciones en la web del W3C/WAI
- descripción de las técnicas
- listado de agentes de usuario, incluidos productos de apoyo, que se utilizaron durante la evaluación, indicando su versión
- listado de las páginas de la muestra
Disclaimer

Artículos relacionados:

Herramienta de ayuda para realizar una consultoría de accesibilidad web

2012-01-25T14:04:00.003+01:00

Servicio relacionado: Consultoría de accesibilidad web

Comparto con vosotros una herramienta personal que he creado para ayudar a realizar el informe resultante de una consultoría de accesibilidad web de acuerdo a las WCAG 1.0 y la Norma UNE 139803. Al final del artículo tenéis la descarga.

Novedad febrero 2012. Incluyo una nueva versión para validar de acuerdo a las WCAG 2.0

Consultar otros materiales de apoyo en la zona de descargas

Qué es y qué no es

NO es una herramienta para realizar una revisión automática de la accesibilidad web de un portal.

Es una herramienta que permite ir recogiendo los datos obtenidos durante la revisión automática y manual del sitio de acuerdo a la Norme UNE 139803, que es un poco más exigente que las WCAG 1.0 (ver diferencia entre las WCAG 1.0 y la Norma UNE 139803), y que te genera información de utilidad para realizar el informe.

Cuando redactas el informe que refleja los resultados de la consultoría hay dos apartados claves:

el análisis detallado donde incluyes por cada punto de verificación y página de la muestra qué se pretende evaluar y cómo se ha evaluado, qué errores se han cometido, cómo solucionarlos técnicamente y cómo evitarlos en el resto del portal. Este apartado debe estar orientado a los desarrolladores que van a realizar los cambios.
el resumen de la evaluación, que está destinado a las personas que han contratado la consultoría y que no tienen por qué tener conocimientos técnicos. En este resumen se indica de manera concisa y clara, sin entrar en aspectos técnicos, cuáles son los principales problemas en base a su criticidad y recurrencia, el nivel de adecuación alcanzado por la muestra y por cada una de sus páginas, etc.

Los datos que genera la herramienta que comparto son especialmente útiles para ese resumen de la evaluación. Genera un resumen del nivel de adecuación A y AA (tanto de la muestra en general como de cada una de sus páginas) datos estadísticos y gráficas que permiten resumir y presentar de forma concisa y muy gráfica los resultados. También nos ayuda a nosotros a identificar con rapidez cuáles son los puntos de verificación y las páginas que presentan más problemas.

Descripción de la herramienta

Está en formato Excel. Todos los campos están protegidos salvo aquellos que se deben ir rellenando. Es una herramienta de uso personal que he decidido compartir, así que su funcionamiento y organización están basados en mi manera habitual de trabajar.

La Excel está dividida en cuatro pestañas:

Pestaña 1: General

En esta pestaña se rellenan los datos generales sobre la web a analizar:

Fecha: rango de fechas entre las que se realiza la evaluación
Web: URL de la web que se analiza
Cliente: cliente para el que se realiza la consultoría
Evaluador: persona que lleva a cabo la evaluación
Nº de páginas de la muestra: nº de páginas que componen la muestra a evaluar. Está pensada para un máximo de 15.
Datos de las páginas de la muestra: alias por el cual haremos referencia a esa página y su URL. El alias que demos a cada página de la muestra será el que automáticamente se adjudique en el resto de la Excel para identificar a esa página.

Pestaña 2: A

La labor que debe hacer el evaluador en esta pestaña es indicar por cada una de las páginas de la muestra y por cada uno de los puntos de verificación de nivel A si dicha página cumple, no cumple o no se aplica el correspondiente punto de verificación que está analizando.

Por tanto por cada punto de verificación de nivel A y cada página de la muestra encontramos las siguientes columnas:

el punto de verificación a evaluar
el nivel de dicho punto. Se indica si es A, si es A sólo según la Norma UNE 139803, o si sólo es A en determinado contexto
un listado con las páginas de la muestra. El nombre que aparecerá será el alias que se le ha dado a cada página en la primera pestaña.
un desplegable por cada página para indicar si dicha página cumple con el punto de verificación. Es lo que debe rellenar el evaluador a medida que avanza en el análisis de accesibilidad de las páginas. Los valores disponibles son:
- Sí: la evaluación manual (o automática cuando sea posible) determina que cumple dicho punto de verificación.
- No: la evaluación manual (o automática cuando sea posible) determina que no cumple dicho punto de verificación.
- No se aplica: cuando el punto de verificación no es aplicable a la página porque no es posible una respuesta "sí" o "no". Por ejemplo, el punto de verificación 1.2 dice “Proporcione vínculos redundantes en formato texto para cada zona activa de un mapa de imagen del servidor”, si la página analizada no tiene mapas de imagen de servidor, no puedes indicar que se han proporcionado vínculos para cada zona activa ni que no se han proporcionado, simplemente no se aplica porque no se utilizan mapas de imagen de servidor.
un desplegable para indicar si la muestra en su conjunto cumple el punto de verificación. Los valores disponibles son los mismos que en el caso anterior. El evaluador deberá especificarlo en base a:
- si alguna de las páginas no cumple el punto de verificación, la muestra en su conjunto no lo cumple
- si el punto de verificación no se aplica a todas las páginas, dicho punto no se aplica a la muestra en su conjunto
- sí ninguna de las páginas no cumple el punto el punto de verificación (es decir, sólo hay páginas que lo cumplen o en las que no se aplica), la muestra en su conjunto cumple el punto de verificación

Para hacerlo más visual y localizar con más facilidad el tipo de datos insertados, en función del valor especificado se estable un código de color:

¿Que información nos genera esta pestaña?

En la imagen anterior se ve que por cada punto de verificación nos incluye un resumen del número de páginas de la muestra que cumple, no cumplen o en las que no se aplica dicho punto de verificación.

El grueso de la información generada la encontramos a la derecha de las columnas especificadas anteriormente:

Los datos que proporciona son:

una tabla resumen del cumplimiento de nivel A de la muestra en general. El nº de puntos que se cumplen, no se cumplen o no se aplican y qué porcentaje suponen respecto al número de puntos que hay que cumplir. Se ofrece el porcentaje de cumplimiento y no cumplimiento tanto teniendo en cuenta los puntos no aplicables como sin tenerlos en cuenta.
gráfico que refleja también el resultado del porcentaje de cumplimiento y no cumplimiento del nivel A de la muestra. Para la realización del gráfico no se tienen en cuenta los puntos no aplicables, es decir, a la hora de hacer la estadística se restan del número de puntos que hay que cumplir.

una tabla resumen por cada una de las páginas de la muestra. Por cada página podemos ver el número de puntos de nivel A que cumple, no cumple o no se aplican, y el porcentaje que suponen respecto al número de puntos que se han de cumplir. Se ofrece el porcentaje de cumplimiento y no cumplimiento tanto teniendo en cuenta los puntos no aplicables como sin tenerlos en cuenta.

gráfico de barras que refleja también el porcentaje de cumplimiento y no cumplimiento del nivel A de cada página de la muestra. Para la realización del gráfico no se tienen en cuenta los puntos no aplicables, es decir, a la hora de hacer la estadística se restan del número de puntos que hay que cumplir.

Esta información nos permite conocer el nivel de adecuación de la muestra y de cada página. Nos permite además localizar de forma visual las páginas que más problemas tienen.

Pestaña 3: AA

El funcionamiento y los datos que genera son equivalentes a la pestaña A pero para los puntos de verificación de nivel AA.

Los datos se generan para los puntos de verificación AA y para los puntos de verificación A+AA.

Los primeros son sólo a modo informativo y sirven también de base para calcular los realmente importantes, los datos A+AA.

Para alcanzar el nivel de adecuación AA es necesario cumplir con los puntos de verificación A y AA, por tanto los gráficos y estadísticas que nos informan del nivel de adecuación AA de la muestra son los datos A+AA.

Pestaña 4: Por puntos de verificación

Esta pestaña nos da una perspectiva global de los puntos de verificación que más problemas están generando. Por cada uno de ellos, en una tabla, agrupados por nivel A o AA, se indica el nº de páginas de la muestra que lo cumplen, no lo cumplen o en las que no se aplica.

Se generan una serie de gráficas que permiten identificar cuáles son los más o lo menos problemáticos.

Descarga de la herramienta

La descarga es gratuita.

Descarga de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 1.0/Norma UNE 139803. Archivo excel .XLSX de 85.6 KB

Descarga de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0. Archivo excel .XLSX de 84 KB

Esta prohibido su uso comercial y su distribución sin permiso del autor.

Servicio relacionado: Consultoría de accesibilidad web

Artículos relacionados:

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA

2011-02-27T22:54:00.003+01:00

Como consultor de usabilidad y accesibilidad es fundamental, cuando formas parte del grupo de trabajo que va a desarrollar una aplicación Web, conocer el marco metodológico del Diseño Inclusivo para incluir los requisitos de accesibilidad y usabilidad a lo largo de todo el proceso de desarrollo. Ello permitirá crear aplicaciones usables y accesibles cuya calidad perdure en el tiempo.

El objetivo de este artículo es difundir el marco metodológico AWA para el desarrollo de aplicaciones web accesibles, pues es un excelente ejemplo de metodología de Diseño Inclusivo que ayuda a comprender las bases en las que se debe asentar un desarrollo que tenga la accesibilidad y la usabilidad presentes en todas las fases del proceso.

Para ampliar información o contactar con su autora recomiendo acceder directamente a su web: AWA (Accessibility for Web Applications) También recomiendo su presentación Tutorial: Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software (PDF)

Índice del artículo

Introducción: marco metodológico AWA
Pre-requisitos para la aplicación de AWA
Fases y actividades
Estructura del soporte metodológico AWA
Checklist de seguimiento del cumplimiento de requisitos y mecanismos
Casos reales: portal corporativo con Drupal

Introducción: marco metodológico AWA

AWA (Accessibility for Web Applications) es el marco metodológico para el desarrollo de aplicaciones web accesibles elaborado por Lourdes Moreno es su tesis doctoral: “AWA, Marco metodológico específico en el dominio de la accesibilidad para el desarrollo de aplicaciones Web”, 2010 [PDF, 8.5 MB].

El objetivo del trabajo es ofrecer un soporte metodológico para incorporar los requisitos de accesibilidad en todo el proceso de desarrollo de una aplicación web, aportando sistematización y un enfoque DCU que situé al usuario como protagonista. El marco de trabajo es el Diseño Inclusivo que involucra a los usuarios con necesidades especiales y a expertos en este tipo de necesidades y discapacidades. El estándar de referencia a lo largo del trabajo son las WCAG (1.0 y 2.0) y el cumplimiento de las mismas en las páginas web finales de la aplicación Web.

Uno de los errores habituales es afrontar la revisión de la accesibilidad cuando el desarrollo está muy avanzado, siendo más costoso y complicado aplicar los requisitos necesarios. Por otra parte, cuando la accesibilidad no se ha sistematizado en el desarrollo es mucho más difícil mantenerla durante el ciclo de vida de la aplicación Web.

Los objetivos finales son pues:

conseguir que las páginas web finales generadas por la aplicación sean accesibles según las WCAG y usables desde el punto de vista del usuario,
garantizar la calidad, es decir, que esta accesibilidad sea estable en todo el ciclo de vida de la aplicación web.

Es una propuesta flexible para que pueda ser aplicada a cualquier proceso de desarrollo de software que cumpla con los pre-requisitos mínimos.

Pre-requisitos para la aplicación de AWA

La aplicación de esta metodología tiene como pre-requisito que la aplicación siga una arquitectura de modelo de más de dos capas (MVC) donde la lógica de negocio esté separada de la presentación, pues la separación de la presentación, la estructura y el contenido es un requisito imprescindible del diseño accesible. Además asegurará que las funcionalidades implementadas sólo en cliente (como AJAX) no dejen de funcionar.

Por otro la lado, la tecnología cliente deberá estar basada en estándares del W3C (XHTML, CSS, etc.) y tecnología servidor que no deje código en el lado del cliente (a excepción de AJAX que podrá ser utilizado junto con soluciones WAI-ARIA).

Fases y actividades

Presupone un proceso de desarrollo con un enfoque iterativo y un ciclo de vida incremental, cuyas fases y actividades son:

Comunicación con el cliente:

Análisis de negocio: identificación de metas y objetivos de la aplicación.
Actividad de formulación: captura de requisitos que involucre a todos los participantes.

Planificación:

Estimación de costes.
Evaluación de riesgos.
Planificación del desarrollo para definir tareas y plazos de cada incremento (plan de iteración)

Ingeniería:

Análisis:
1. Definición de requisitos técnicos, identificación de elementos de contenido y análisis del diseño gráfico.
2. Requisitos de interacción: relación de los elementos de contenido y su funcionalidad asociada.
3. Análisis de navegación: mecanismos de navegación que se van a proporcionar.
Diseño:
1. Diseño del contenido y diseño gráfico.
2. Diseño de la estructura y el comportamiento de la aplicación en sí, incluyendo arquitectura, navegación e interfaz.
Modelado: creación de modelos antes de la construcción.

Construcción:

Implementación: de los modelos procedentes de la fase de ingeniería para construir la aplicación Web. Integración con software intermedio.
Pruebas: para asegurar la calidad:
1. Verificación: comprobación de que la aplicación es correcta desde la perspectiva del diseñador en relación al contenido, arquitectura, presentación, interfaz y navegación
2. Validación: comprobación de que la aplicación hace y tiene la apariencia que el cliente esperaba.

Despliegue:

Evaluación e interacciones de cambios.

Estructura del soporte metodológico AWA

Componentes

AWA_Organización

Mecanismos para integrar planes y políticas de accesibilidad en la organización y equipo de desarrollo.

Se articula en torno a la elaboración de un Plan de accesibilidad (creación del grupo de accesibilidad, determinar la política de accesibilidad con el nivel de conformidad deseado, mecanismos para compartir el conocimiento sobre accesibilidad y plan de formación, seleccionar tecnologías accesibles, etc.) y la Gestión de la accesibilidad (procesos a nivel interno pero también externo como la elaboración de requisitos para proveedores externos o la gestión de sugerencias de los usuarios)

Consultar mapa conceptual de AWA_Organización

AWA_Interacción

Mecanismos para integrar un enfoque de DCU con inclusión, teniendo como instrumento base el estándar ISO 13470:1999 (PDF, p.121) que se introduce en las páginas 121 y siguientes.

Se articula en torno a dos principios fundamentales:

Involucrar a todos los usuarios, incluyendo al usuario con discapacidad en todo el proceso
Considerar las características del usuario con discapacidad y la diversidad de contextos de uso en la Web.

Engloba técnicas de usabilidad con inclusión como: perfiles de usuario, personas, escenarios, prototipo, tormenta de ideas, cardsorting, evaluación heurística y cuestionarios, entrevistas y encuestas, que se detallan en las páginas 129 y siguientes.

Consultar mapa conceptual de AWA_Interacción

En este capítulo 5 me parece muy interesante la tabla de correspondencia entre los criterios heurísticos de usabilidad y los criterios de conformidad de las WCAG 2.0 (PDF) (tabla que se explica en las páginas 155 y siguientes). Recurso muy útil para saber qué aspectos de la accesibilidad se están teniendo en cuenta cuando la usabilidad se incluye en un proyecto.

AWA_WCAG

Abstracción de las WCAG (1.0 y 2.0) de manera que su tratamiento pueda ser incluido desde el inicio del proceso de desarrollo de una aplicación Web.

Puesto que no todos los requisitos pueden ser incorporados desde el diseño se distingue estos (AWA_WCAG Diseño) de los que son a nivel de implementación (AWA_WCAG Implementación: presentación con CSS, acceso por teclado, cambio de contexto o compatibilidad con terceras tecnologías) y de los que han sido definidos para ser incorporados en la actividad de evaluación (AWA_WCAG Evaluación)

Consultar los mapas conceptuales de AWA_WCAG para las actividades de diseño, implementación y evaluación

Requisitos

AWA_Requisitos

Como resultado se definen unos requisitos de accesibilidad que tienen tres objetivos principalmente:

seguir las WCAG 1.0 y 2.0,
seguir un enfoque DCU con Inclusión
tener en cuenta la gestión de la accesibilidad considerando los requisitos de accesibilidad desde la organización como punto de partida.

En la notación de los requisitos se incluye el componente, por ejemplo: AWA_Requisito_{Organización} PLAN 01.02: Declaración de Política de accesibilidad

Los AWA_Requisitos_WCAG que hay que incorporar en la actividad de diseño se describen en las páginas 150 y siguientes, incluyendo por cada uno una tabla de correspondencia con las WCAG 1.0 y las WCAG 2.0. También se pueden consultar estas tablas accediendo en la web a cada una de las pautas WCAG 1.0 y WCAG 2.0

Consultar una tabla simplificada de correspondencias entre las WCAG 1.0, las WCAG 2.0, los AWA_Requisitos y los grupos de usuarios beneficiados.

Los AWA_Requisitos activan mecanismos de accesibilidad denominados AWA_Mecanismos.

Mecanismos

AWA_Mecanismos: Articulan la incorporación de los AWA_Requisitos desde el inicio del proceso. En la notación de los requisitos se incluye el componente, por ejemplo AWA_Mecanismo_{Organización} PLAN 01.02/02: Determinar Declaración de Política de Conformidad.

Checklist de seguimiento del cumplimiento de requisitos y mecanismos

Consultar checklist de seguimiento del cumplimiento de requisitos y mecanismos (PDF)

Casos reales

En el capítulo 7 se explican casos reales de aplicación, uno de ellos el de la web del Centro Español de subtitulado y Audiodescripción (CESyA) gestionada con Drupal.

Se explica el enfoque de Diseño Inclusivo en la captura de requisitos combinando las técnicas de perfiles de usuario, personas y escenarios.

Se detalla la utilización de la técnica Card Sorting (manual abierta, automática con WebSort y manual cerrada) para adecuar la arquitectura de la Información al modelo mental de los usuarios.

La elaboración de un prototipo de bajo coste y reuniones Visual Brainstorming antes de abordar el diseño gráfico, así como la elaboración posterior de un prototipo software funcional, evaluándolo por expertos (evaluación heurística) y mediante pruebas de usuarios con y sin discapacidad (consultar cuestionarios a los participantes en el test de usuarios y a los testers (PDF)).

Aplicando todo lo anterior se crearon las plantillas de Drupal y se validó su accesibilidad.

Me parecen fundamentales todos los mecanismos que se llevaron a cabo en Drupal para asegurar que la inclusión de contenido a través del gestor diera lugar a contenido accesible y por tanto páginas que cumplen los niveles de conformidad AA.

Para ello se incluyó un editor de contenido con criterios de accesibilidad que transformara los datos introducidos en código válido. Por ejemplo, al incluir una noticia se pide el título (que se incluirá como encabezado), el idioma (aplicará en el código la identificación del idioma si no se corresponde con el idioma de la página), etc.

Me gustaría destacar las características y restricciones que debe tener el editor de contenido de un CMS para que el contenido resultante sea accesible:

Edit text: permite escribir texto plano e incluye una opción guiada donde no se puede incluir tags (X)HTML
Specify language: puedes seleccionar el idioma mediante una select.
Add header: permite incluir un encabezado de un nivel específico, pero si existe un nivel de encabezado ya definido que englobe el actual documento, el nivel relativo se ajustará a ese nivel global, siendo relativo a éste. Se puede especificar también su idioma.
Add image: siendo obligatorio la URI y el texto alternativo, y opcionalmente el longdesc
Add multimedia: permite incluir vídeo siendo obligatoria la URL, el recurso de subtitulado y audiodescripción, y su lenguaje.
Add link: siendo obligatorio la URI y pudiendo incluir un title y el lenguaje de la página de destino.
Add abbreviation: que permita incluir un contenido con texto abreviado, pudiendo especificar su idioma.
Add acronym: permite incluir un acrónimo, pudiendo especificar su idioma.
Add list: añade una lista de diversos tipos.
Add table: permite incluir una tabla, indicando filas, columnas, encabezados, resumen, etc..
Add form: añade un formulario, permitiendo incluir los elementos típicos de formularios HTML mediante “Add element”. “Specify action” permite indicar la acción que realizará el formulario al ser enviado.
Finish editing: finaliza la edición del contenido, comprobando que éste cumple con las especificaciones definidas y lo inserta en el sistema de persistencia, quedando a la espera de una revisión de accesibilidad (AWA_Requisito_WCAG EVA 01) para su publicación definitiva.

Esta revisión manual del contenido incluido en el editor para que pueda publicarse tiene en cuenta los puntos de las tabla de la página 241.

Artículos relacionados:

Artículos recomendados

Diseño Inclusivo: Marco Metodológico para el Desarrollo de Sitios Web Accesibles

Reseña "Just Ask: Integrating Accessibility Throughout Design"

2009-11-10T12:30:00.017+01:00

Artículos relacionados:

En este artículo voy a resumir los puntos esenciales del libro "Just Ask: Integrating Accessibility Throughout Design" de Shawn Lawton Henry (2007), el cual está disponible en versión online en español ("Simplemente pregunta: Integración de la accesibilidad en el diseño").

El libro trata sobre los fundamentos de la inclusión de la accesibilidad en los procesos de Diseño Centrado en el Usuario (UCD).

Este libro es recomendado como guía de referencia por la WAI.

Matizan, como también se hace a menudo a lo largo del libro, que incluir a las personas con discapacidad en la evaluación reporta muchos beneficios pero no determina por sí mismo si un sitio es accesible, siempre debe combinarse con la evaluación conforme a las WCAG.

Principios básicos

Integrar la accesibilidad al principio y a lo largo de todo el proyecto.
Tener en cuenta la accesibilidad al principio en un proyecto de diseño es mucho más fácil, eficaz y barato que hacerlo posteriormente.
Contar con la participación de personas con discapacidad en tu proyecto
Los estándares y pautas son sólo una parte de la ecuación en lo que se refiere al adecuado desarrollo de productos accesibles. La otra parte es comprender los problemas de accesibilidad, y la mejor forma de hacerlo es trabajar con personas con discapacidad para saber cómo interactúan con tus productos.
Relacionarse con personas con discapacidad. Recomendaciones para relacionarse con las personas con discapacidad

Contexto: Accesibilidad en el Diseño Centrado en el Usuario

En este capítulo se introducen los conceptos básicos de accesibilidad, usabilidad y DCU.

El objetivo de incorporar la accesibilidad al Diseño Centrado en el Usuario es seguir un "proceso de creación de productos (dispositivos, entornos, sistemas y procesos) que sean usables para personas cuyas capacidades estén dentro del segmento más amplio posible y que se encuentren en situaciones (entornos, condiciones y circunstancias) dentro del espectro más amplio posible, siempre y cuando sea práctico desde el punto de vista comercial".

El proceso de Diseño Centrado en el Usuario se divide en tres fases principales: análisis, diseño y evaluación.

El DCU es un proceso para diseñar productos usables y la accesibilidad de los interfaces de usuario puede considerarse un subgrupo dentro de la usabilidad. Por tanto, se deduce que los diseñadores pueden utilizar el DCU para diseñar productos que sean accesibles. En la práctica, las técnicas de diseño accesible encajan bien con los procesos de DCU ya establecidos.

Después de añadir y adaptar algunos aspectos, los equipos de diseño pueden utilizar las prácticas típicas del DCU para centrar el diseño en la accesibilidad. Integrar la accesibilidad al DCU significa que los diseñadores deben tener en cuenta la muestra de usuarios y situaciones más amplia posible.

Análisis

Es la primera fase de un proceso de DCU.

Ten cuidado y no des por sentado que los comentarios de una persona con discapacidad se pueden aplicar a todas las personas con discapacidad. Una persona que tenga una discapacidad no tiene por qué saber necesariamente cómo van a interactuar otras personas con su misma discapacidad con esos productos, ni tiene por qué saber lo suficiente sobre otras discapacidades como para poder proporcionar consejos válidos sobre otros problemas de accesibilidad.

En este apartado se aborda cómo tener en cuenta los aspectos relacionados con la accesibilidad en la definición de perfiles de grupos de usuarios, en la creación de personajes y en la creación de escenarios.

Diseño

Es la segunda fase de un proceso de DCU.

Los diseñadores de productos a los que se les exige que cumplan con unos estándares de accesibilidad específicos suelen pasar directamente a la parte técnica del estándar sin llegar a entender los problemas de accesibilidad. Intentar cumplir con los estándares de accesibilidad sin entender qué es la accesibilidad no es sólo frustrante, sino que no da resultado.

[...]

Usar estándares y pautas te ayudará a garantizar que se tienen en consideración todos los problemas de accesibilidad y contar con la colaboración de personas con discapacidad te ayudará a abordarlos de una forma eficiente y eficaz.

[...]

Evaluar prototipos iniciales te ayudará a validar ciertos aspectos del diseño que funcionan correctamente y a encontrar barreras potenciales de accesibilidad en un momento en el que todavía es relativamente fácil y poco costoso arreglarlas.

Evaluación

Es la tercera fase de un proceso de DCU.

La evaluación de la accesibilidad suele verse limitada a la comprobación de la conformidad con los estándares de accesibilidad.

La conformidad con estos estándares es importante: en algunos casos es un requisito legal y en otros es sólo una buena forma de comprobar que se han tenido en cuenta, adecuadamente, todos los problemas de accesibilidad.

Sin embargo, cuando se presta atención solamente a los aspectos técnicos de la accesibilidad, el factor de la interacción humana puede llegar a perderse. Los métodos de evaluación de la usabilidad pueden comprobar la accesibilidad usable para garantizar que tus soluciones de accesibilidad son usables para las personas con discapacidad.

Técnicas de filtrado

Las técnicas de filtrado implican la utilización de estrategias de adaptación, dispositivos de ayuda y tecnologías de apoyo.

Por ejemplo, que un diseñador de software apague su monitor y utilice un lector de pantalla para interactuar con su aplicación o que un especialista en usabilidad utilice un puntero bucal o desenchufe su ratón para hacerse una idea de cómo de usable es su producto para las personas que no puede usar los brazos o las manos.

Las técnicas de filtrado no son simulaciones de discapacidades. Es probable que a las personas con discapacidad les resulte más fácil utilizar el producto que a las personas que estén utilizando técnicas de filtrado.

Se utilizan porque son fáciles, rápidas y económicas y identifican problemas potenciales de diseño en la fase inicial, lo que evita altos costes de rediseño y retrasos en el proceso.

Por ejemplo en "Preliminary Review of Web Sites for Accessibility" de la WAI se citan determinadas técnicas de filtrado.

Planificación de las pruebas de usabilidad

Los cuatro grupos más habituales de discapacidades (visuales, auditivas, físicas y cognitivas) no son suficientes para categorizar las características de los participantes en un estudio de usabilidad, debido a la diversidad que existe dentro de cada categoría (la discapacidad puede ser temporal o permanente, puede haber nacidocon ella o no, pueden usar diferentes tecnologías de apoyo, etc.).

Por otra parte, el número de participantes con discapacidad que forman parte de una prueba de usabilidad concreta suele estar determinado por los limitados recursos de un proyecto.

Teniendo en cuenta estas dos variables, el autor nos da una serie de consejos sobre la selección de las personas, siendo importante recalcar que hay que evitar cometer el error de pensar que un participante los representa a todos.

Cómo completemento proporciona un Formulario de selección de participantes que se utiliza para determinar si un participante potencial encaja con las características de usuario definidas en el protocolo de la prueba de usabilidad

A la hora de decidir dónde se realizan las pruebas de usabilidad es importante tener en cuenta las tecnologías de apoyo, por ejemplo puede que los participantes no sepan cómo configurar las tecnologías de apoyo en tu laboratorio para poder trabajar, porque están acostumbrados a que funcionen de una forma determinada en sus sistemas.

También es importante planificar el tiempo y los descansos en base a las características de cada discapacidad.

Preparación de las pruebas de usabilidad

En este capítulo se dan muchos consejos prácticos para la preparación de las pruebas (instalaciones, materiales, etc.)

Realización de las pruebas de usabilidad

En este capítulo se abordan las cuestiones que permitirán realizar con éxito las pruebas (acondicionamiento de la sala, orientación del participante, recogida de datos, etc.)

Elaboración de informes

Para analizar los datos y realizar informes sobre un estudio de usabilidad que ha contado con participantes con discapacidad, hay que tener en cuenta las siguientes consideraciones:

Distinguir entre los problemas de usabilidad (es decir, que influyen a todos los usuarios por igual, independientemente de sus características) y de accesibilidad (es decir, reducen el acceso de las personas con discapacidad a un producto).
Incluir parámetros relevantes del estudio, por ejemplo las estrategias de adaptación y tecnologías de apoyo que utiliza cada usuario y su experiencia con productos similares.
Tener cuidado con las categoriaciones y las comparaciones, especialmente si la amplitud del muestreo es pequeño.
Elaborar conclusiones claras. Hay que dejar claro qué afirma el informe y qué no. Por ejempplo, unos resultados positivos en las pruebas de usabilidad no garantizan que el producto sea accesible para todas las personas con discapacidad, ni que cumpla los estándares de accesibilidad.
Utilizar un lenguaje apropiado para referirse a las personas con y sin discapacidad.

Lista de verificación para las pruebas de usabilidad

Este apartado es muy útil porque resume todos los puntos tratados en los capítulos referidos a la fase de Evaluación en una checklist.

Recursos

Selección de recursos y enlaces de interés (no se actualiza desde 2004)

Artículos relacionados:

Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI

2009-06-19T21:29:00.010+02:00

Artículos relacionados

"Evaluating Web Sites for Accessibility" es una suite de documentos de la WAI que constituye la metodología a seguir para evaluar la accesibilidad de un sitio Web y asegurar la calidad de los procedimientos.

El objetivo de este artículo es dar a conocer y resumir estos documentos en español.

Índice

Examen preliminar de la accesibilidad de un sitio Web
Evaluación de la conformidad de accesibilidad de un sitio Web
Metodología para la evaluación de contextos específicos
Inclusión de los usuarios en la evaluación de la accesibilidad Web
Selección de herramientas de evaluación de la accesibilidad Web
Listado y búsqueda de herramientas de evaluación de la accesibilidad Web
Uso combinado de expertos para evaluar la accesibilidad Web
Plantilla para informes de evaluación de accesibilidad

Examen preliminar de la accesibilidad de un sitio Web

Describe una metodología para identificar rápidamente posibles problemas de accesibilidad en un sitio Web. Consta de cinco pasos:

Seleccionar una muestra representativa de páginas.

Examinar las páginas usando navegadores gráficos haciendo las siguientes pruebas:
- Desactivar las imágenes y comprobar que existe para ellas una alternativa adecuada.
- Desactivar el sonido y comprobar que el contenido del audio está disponible a través de texto equivalente.
- Comprobar que se puede aumentar el tamaño de fuente y que la página es usable con un tamaño de fuente grande.
- Probar con diferentes resoluciones de pantalla y/o con diferentes tamaños de ventana para verificar que el desplazamiento horizontal no es necesario.
- Visualizar o imprimir la pantalla en escala de grises y observar si el contraste es suficiente.
- Utilizar el teclado para navegar a través de los enlaces y controles de formulario, asegurándose de que se puede acceder a todos los vínculos y controles y que los vínculos indican claramente a dónde conducen.
Examinar las páginas con un lector de pantalla y un navegador sólo texto para comprobar que toda la información está disponible y en un orden significativo.
Utilizar al menos dos herramientas de evaluación automática para analizar las páginas de la muestra.
Resumir los resultados obtenidos indicando:
- Los diferentes tipos de problemas detectados, pero también los aspectos positivos que se han encontrado.
- El método por el cual se detectaron los diferentes problemas, indicando claramente que no se trata de una evaluación completa de la conformidad de accesibilidad.
- Incluir recomendaciones sobre medidas de seguimiento, la realización de un análisis completo y las maneras de abordar los problemas identificados.

Evaluación de la conformidad de accesibilidad de un sitio Web

Describe la metodología a seguir para determinar si un sitio Web cumple con las normas de accesibilidad (Web Content Accessibility Guidelines (WCAG)).

Los pasos son los siguientes:

Determinar el alcance de la evaluación: el nivel de conformidad (A,AA,AAA) a evaluar, la muestra representativa de las páginas que se van a analizar y la URL base que incluye todas las páginas a analizar en las revisiones automáticas (si no es posible por el tamaño del sitio o su naturaleza dinámica, seleccionar una muestra ampliada de páginas representativas).
Utilizar herramientas de evaluación de la accesibilidad Web:
- HTML Validation service;
- HTML Tidy;
- CSS Validation service;
- MathML Validator.
- Usar al menos dos herramientas de evaluación automática de la accesibilidad en la muestra de páginas seleccionadas y al menos una herramienta a través de todo el sitio Web (o en la selección ampliada).
Evaluación manual de la muestra de páginas:

Aplicar la checklist de accesibilidad a las páginas de la muestra.
Examinar las páginas usando navegadores gráficos (descripción en el apartado anterior)
Examinar las páginas con un lector de pantallas y un navegador sólo texto para comprobar que toda la información está disponible y en un orden significativo.
Leer y evaluar el contenido de las páginas, ¿el texto es claro, sencillo y adecuado al propósito del sitio?

Resumir los problemas y las mejores prácticas identificadas para cada tipo de página, con una URL de ejemplo y el método por el que fueron identificados. Recomendar la reparación de los problemas de accesibilidad detectados, la ampliación de los aspectos positivos y el mantenimiento y seguimiento del sitio.

Metodología para la evaluación de contextos específicos

La evaluación durante el proceso de desarrollo es esencial pues los problemas de accesibilidad detectados de manera temprana son más fáciles de corregir. Para una evaluación eficaz durante el proceso de desarrollo es necesario:
- Establecer claramente los requisitos de accesibilidad para el nivel de conformidad deseado.
- Participación en las reuniones iniciales de planificación del sitio.
- Acordar un calendario de revisión durante el proceso de desarrollo.
- Proporcionar información sobre métodos de evaluación para que los desarrolladores pueden hacer por lo menos una evaluación preliminar por su cuenta.
Seguimiento. Para facilitar que un sitio mantenga el nivel de conformidad en el futuro se recomienda:
- Una declaración clara del nivel de conformidad esperado y el alcance del sitio Web al que esto se aplica.
- Identificar claramente las personas responsables del seguimiento del sitio y los procedimiento a seguir para convertir rápidamente en conformes las páginas no conformes.
- Definir unas expectativas claras con respecto a la frecuencia, el método y el alcance de las evaluaciones.
- Establecer un proceso de validación y evaluación de todas las páginas modificadas y los nuevos tipos de páginas antes de que se añadan al sitio.
- Software para facilitar la evaluación.
- Incorporar en el sitio una dirección para la información sobre accesibilidad.
- Establecer pruebas automáticas o semi-automáticas para identificar los problemas hallados en la evaluación global.
Evaluación de los sitios Web "heredados", no activos, que pasa por identificar al propietario, su obligación o interés por hacerlo accesible, etc.
Evaluación de páginas Web generadas dinámicamente:
- Plantillas
  
  Evaluar la accesibilidad de las plantillas estáticas según las WCAG. Añadir un mínimo de contenido textual a las plantillas y volver a evaluar.
- Contenido
  
  Evaluar la capacidad del sistema de gestión de contenidos para almacenar y generar información de accesibilidad. ¿Permite incorporar contenido alternativo a imágenes, sonidos y vídeos? ¿Las tablas pueden generarse con los recursos de accesibilidad? ¿Genera (X)HTML válido?
- Plantillas y contenido combinado.
  
  Las páginas que se generan como resultado de una consulta a una base de datos deben ser capturadas y evaluadas por medio de las WCAG ¿Las páginas generadas conservan las características de accesibilidad?

Inclusión de los usuarios en la evaluación de la accesibilidad Web

La inclusión de personas con discapacidad en la evaluación de la accesibilidad durante el desarrollo contribuye a entender mejor los problemas de accesibilidad y aplicar las soluciones más eficaces.

Inclusión efectiva de los usuarios.

Partiendo de la base de que las evaluaciones previas de accesibilidad detectan los principales problemas de accesibilidad, se puede involucrar a los usuarios de muy diversas maneras, desde evaluaciones informales (preguntando por ejemplo a un usuario que use un lector de pantalla sobre un tema concreto) hasta un test de usuarios formal optimizado para problemas de accesibilidad.

En cualquier caso es más efectivo realizar evaluaciones informales a lo largo de todo el proceso que realizar un test formal al final del mismo.

Se debería buscar unas cuantas personas con discapacidad e incluirlas en todo el proceso de desarrollo para completar tareas en prototipos y discutir con ellos los problemas de accesibilidad.

Examinar cuidadosamente todos los votos y evitar el supuesto de que los comentarios de una persona con una discapacidad se aplican a todas las personas con discapacidad. Una persona con una discapacidad no sabe necesariamente cómo otras personas con la misma discapacidad interactúan con la Web, ni saben lo suficiente sobre otras discapacidades para proporcionar orientación sobre otras cuestiones de accesibilidad.
Incluyendo diversos usuarios

Hay que tener en cuenta que hay muchos tipos de discapacidad y los usuarios utilizan diferentes tecnologías asistivas. Es también muy importante tener en cuenta no sólo su experiencia en Internet sino también con determinada tecnología asistiva. Del mismo modo, es imprescindible tener claro cuál es el público objetivo del sitio.

Para seleccionar de forma correcta a los usuarios se recomienda leer "Planning Usability Testing"
Analizar los problemas de accesibilidad.

La accesibilidad Web depende de varios factores, incluyendo los navegadores Web, las tecnologías de asistencia (AT) y el contenido Web. Para cualquier problema de accesibilidad es necesario determinar qué componentes son los responsables. Por ejemplo, si un usuario tiene problemas con una tabla de datos, puede ser porque el código (X)HTML no está marcado correctamente, o porque a los usuarios que usan una AT no se les facilita la lectura de los datos efectivamente o porque el usuario no sabe utilizar correctamente la AT.

Además de encontrar los problemas de accesibilidad, la evaluación con usuarios con discapacidad revela los problemas generales de usabilidad que afectan a todos los usuarios, incluidos aquellos sin discapacidades.
Conclusiones y presentación de informes.

La combinación de la participación de los usuarios con la evaluación de la conformidad según las WCAG asegura que la amplia gama de cuestiones de accesibilidad están cubiertas.

Los informes deben incluir el ámbito del estudio y los parámetros de evaluación, tales como los métodos de prueba y las características del usuario. Por ejemplo, si el estudio incluyó sólo las pruebas de usabilidad con los participantes que son ciegos, su informe debe aclarar que no se evalúa la conformidad con las WCAG y que no se aplica a todas las personas con discapacidad. Así, el informe puede ayudar a los lectores a sacar las conclusiones apropiadas.
Optimización de los test de usuario para los problemas de accesibilidad.

A la hora de definir específicamente pruebas de usabilidad para encontrar los problemas de accesibilidad, el protocolo será diferente del de un típico test de usuarios, por ejemplo:
- La técnica "think-aloud" facilitará mucho la interacción.
- La recogida de datos se centrará en la comprensión de los errores relacionados con los problemas de accesibilidad, en lugar de centrarse en el tiempo o la satisfacción de los usuarios.
- Las tareas se centrarán en áreas específicas de preocupación para los posibles problemas de accesibilidad, en lugar de en los problemas generales de uso del sitio.

Selección de herramientas de evaluación de la accesibilidad Web

En algunos casos, las herramientas de evaluación son propensas a producir resultados falsos o engañosos. Los resultados de las herramientas de evaluación no deben ser utilizados para determinar los niveles de conformidad, salvo que se lleven a cabo por evaluadores experimentados que entienden las capacidades y limitaciones de las herramientas con el fin de alcanzar resultados exactos.

Las herramientas de evaluación de la accesibilidad Web no puede determinar la accesibilidad de sitios web, sólo pueden ayudar a hacerlo.

Listado y búsqueda de herramientas de evaluación de la accesibilidad Web

Uso combinado de expertos para evaluar la accesibilidad Web

Los evaluadores de accesibilidad deben tener conocimientos sobre:
- Tecnologías Web y especificaciones y estándares del W3C.
- Herramientas de la validación de las tecnologías Web.
- WCAG y técnicas asociadas.
- Metodología de la evaluación de la accesibilidad Web.
- Uso de una amplia variedad de herramientas de evaluación de la accesibilidad Web.
- Conocimientos sobre las tecnologías de asistencia y estrategias de adaptación ("How People with Disabilities Use the Web ")
- Inclusión de las personas con discapacidad en la evaluación de accesibilidad.

Plantilla para informes de evaluación de accesibilidad

Presenta un formato recomendado para la comunicación de los resultados de una evaluación de accesibilidad Web de acuerdo con las WCAG 1.0.

Artículos relacionados

Más accesible a pesar de Blogger (2)

2008-10-15T09:00:00.000+02:00

Este artículo es continuación de Más accesible a pesar de Blogger (1). El objetivo de esta serie de artículos es explicar el proceso que he seguido para intentar hacer más accesible mi bitácora en Blogger, algo que a veces no resulta nada fácil.

Lo cierto es que, aunque en el primer artículo me encontré frustada una y otra vez por los impedimentos a la accesibilidad que Blogger me imponía, esta vez no he tenido tantos problemas (tampoco es que me haya ayudado en mucho).

Como conclusiones de esta revisión voy extrayendo una serie de buenas prácticas a la hora de crear artículos con Blogger, de manera que el resultado sea más accesible, y una serie de tareas programadas que permitan realizar una revisión de los artículos ya publicados mejorando así su accesibilidad.

El proceso que he seguido se puede reproducir en cualquier sitio, no es específico para blogs realizados con Blogger.

Hoy abordo el tema de los atajos de teclado, la página de accesibilidad y personalización y los enlaces, tareas que he realizado en siete días, ordenadas en función del tiempo que he conseguido restarle a mi familia y a Morfeo. Aun habrá más puntos que revisar en futuras entradas.

Día 1: Atajos de teclado

El punto 9.5 de las WCAG (Web Content Accessibility Guidelines) recomienda incluir atajos de teclado para los enlaces importantes.

La Administración Pública del Reino Unido tiene definido un estándar de teclas rápidas en la guía para desarrolladores (Web handbook). Como defiende Accesibilidad Web y Alan en "Atajos de teclado en documentos Web" me ha parecido adecuado seguir esa convención.

Blogger no incluye el atributo accesskey en sus plantillas por defecto ni favorece su inclusión, es necesario ponerlo manualmente en la plantilla.

Para que los usuarios conozcan los atajos de teclado utilizados he realizado dos tareas:

En el title del enlace he indicado su tecla de acceso rápido.
En la página de accesibilidad he indicado todos los atajos que hay en la página y cómo acceder a ellos en los distintos navegadores.

Por cierto, me encantaría que todos los navegadores implementaran los atajos de teclado como Opera (Mayúsculas+Esc):

Día 2: Página "Accesibilidad"

Hoy voy a crear una de página de accesibilidad y personalización. Tal y como propone Emmanuelle Gutiérrez y Restrepo en "Navegación Semántica o Meta Navegación" la incluyo en la navegación semántica de la página mediante rel="personalizar".

En esta página, además de reflejar las intenciones de que el blog sea accesible para todos y las acciones que estoy llevando a cabo para ello, incluyo información importante como es:

El listado de atajos de teclado y cómo acceder a ellos en los distintos navegadores.
Información sobre cómo modificar el color o el tamaño del texto. Más información en el apartado "Menú superior 'Saltar a'" de "Enlaces más accesibles" de este artículo.

Días 3-7: Enlaces más accesibles

Este apartado aborda el tema fundamental de los enlaces, que son al fin y al cabo la base de nuestras páginas. Hay diversas tareas que se deben realizar para asegurar la accesibilidad de nuestros enlaces, yo las he dividido en cinco días.

Día 3: Enlaces rotos

En primer lugar compruebo que no haya enlaces rotos, puesto que las páginas externas a las que enlazo en los artículos han podido desaparecer.

Existen distintos validadores online: Link Analyser, W3C Link Checker,
links-rotos.com, etc.

El que me parece que da una información más útil es el W3C Link Checker

Una buena práctica es leer siempre un par de veces el artículo antes de publicarlo, revisando todos los enlaces que se incluyen. Añado como tarea programada revisar una vez al mes los enlaces para asegurarme de que ninguno ha dejado de existir.

Sería una buena propuesta para los desarrolladores de Blogger que incluyeran alguna herramienta automática con este propósito.

Día 4: Estilo de los enlaces

El objetivo de hoy es revisar que los enlaces tengan un estilo adecuado para ser reconocidos como tales sin problemas. Por ello los enlaces del blog tienen las siguientes características (1):

tienen un color diferente al del texto, en este caso azul, puesto que me parece que ayuda a identificarlos claramente como enlaces
el color del enlace tiene suficiente contraste con el color del fondo
están subrayados
los enlaces visitados tienen otro color, algo que es de gran ayuda cuando se busca información en un sitio y que no se respeta en muchos de ellos. He elegido un color morado, como es estándar "de facto", puesto que un problema que me encuentro en algunos sitios es que no se sabe qué color de los enlaces se corresponde con aquellos que ya se han visitado y cuál con los que no.

Día 5: Acceso mediante teclado, orden de tabulación y enlaces "saltar a"

Hoy me toca revisar que los enlaces sean accesibles sin ratón, es decir, utilizando sólo el teclado, y que además lo sean en el orden adecuado.

Una vez hecha esta comprobación decido buscar una solución a lo pesado que resulta navegar con el tabulador por culpa de la gran cantidad de enlaces que tiene la página.

Para ello creo dos nuevos tipos de menú:

Menú superior "Saltar a"

Al comienzo de la página, basándome en la solución de la web de la WAI (Web Accessibility Initiative), he incluido un menú con tres opciones:

"Saltar al contenido", que permite ir directamente al contenido del artículo sin tener que pasar por todos los enlaces de interés de la columna izquierda. Esta opción es mejor que modificar el orden de tabulación lógico mediante el atributo TABINDEX. Por otro lado, ¿por qué ocultar nuestros enlaces de saltar navegación? Estoy de acuerdo con jlvelazquez.net, revindiquemos los enlaces de saltar navegación accesibles para todos los usuarios.
"Ir al menu", que permite saltarse la columna izquierda y el contenido y acceder directamente al menú del blog en la columna derecha.
"Cambiar el color y tamaño del texto", siguiendo de nuevo el ejemplo de la WAI, he decidido incluir este enlace que informa al usuario de cómo puede cambiar en su navegador el tamaño y color de la fuente. Esta alternativa es mucho más adecuada que los típicos iconitos como explica muy bien Juan Carlos García en "Botones para cambiar el tamaño de letra"

Enlaces "Saltar a" bajo las columnas de contenido

Siguiendo de nuevo la decisión de no ocultar los enlaces, he incluido debajo de cada columna un enlace visible que permita saltar con fluidez de unas columnas a otras.

Día 6: Texto e idioma de los enlaces. Parámetro "title"

El punto de verificación 13.1 de las WCAG (Web Content Accessibility Guidelines) dice:

13.1 Identifique claramente el objetivo de cada vínculo. [Prioridad 2]

El texto del vínculo tiene que tener significado suficiente cuando sea leído fuera de contexto (por sí mismo o como parte de una secuencia de vínculos). También debe ser conciso.

Por ejemplo, en HTML, escriba "información sobre la versión 4.3" en lugar de "pincha aquí". Además de textos de vínculos claros, los desarrolladores de contenidos deben aclarar el objetivo de un vínculo con un título informativo del mismo (por ejemplo, en HTML, el atributo "title"),

En primer lugar compruebo si el texto de los enlaces es significativo y si es necesario complementarlo con el parámetro title. Textos no significativos serían los típicos "pulse aquí", "comentabamos por aquí", que fuera de contexto no sabríamos a donde enlazan (recordemos que el usuario puede utilizar para navegar el listado de enlaces que le proporciona su agente de usuario: JAWS, Opera, Firefox, etc.)

Por la misma razón es necesario que no haya enlaces con el mismo texto pero que apunten a recursos diferentes, lo cual crearía confusión al usuario, especialmente si los lee fuera de contexto como en el caso anterior.

Como explica Emmanuelle Gutiérrez y Restrepo en Enlaces significativos no basta con añadirles el atributo title, es necesario que su literal sea diferente, pues hay agentes de usuario como JAWS que no muestran el atributo title en la relación de enlaces.

Como colofón de este artículo imprescindible, Emmanuelle concluye:

Los enlaces en una página deben ser concisos, significativos y únicos para cada destino, tal como piden las directrices de accesibilidad. Es decir: no ser demasiado largos, ser claros en cuanto a qué se encontrará el usuario si los selecciona o ejecuta (no ambigüos como el típico: "pincha aquí") lo que ayudará a quienes naveguen por enlaces y a quienes tengan deficiencias cognitivas, y un texto dado que conforme un enlace, si vuelve a aparecer en la página debe apuntar exactamente al mismo recurso.

El atributo title está para transmitir información complementaria sobre a dónde apunta el enlace, pero no tiene como misión especial el diferenciar unos enlaces de otros, pues las características del usuario, del agente que utilice o del contexto de uso, pueden hacer que el valor de dicho atributo no llegue nunca al usuario.

Incluso en el caso de que todos los agentes de usuario habilitaran la navegación secuencial, indicando tanto el contenido como el título del elemento, siempre habrá usuarios que no podrán o no querrán hacer uso de ella y que seguirán necesitando claridad, que los enlaces sean significativos. Por ejemplo, algunas personas con determinados tipos de deficiencia cognitiva. Porque se podría alegar que el contexto sería suficiente para diferenciar enlaces iguales (como en el caso del ejemplo 0) pero la experiencia demuestra que esto no es así para muchos usuarios (personas mayores, personas con deficiencias cognitivas, etc.) y el problema se acentúa cuando la persona se ayuda de un lector de pantalla o navegador parlante, pues ha de escuchar continuamente y tras una pausa un mismo texto repetidas veces.

Hay que tener en cuenta que el usuario puede que no esté leyendo la portada del blog o un artículo concreto, sino que puede estar leyendo todos los artículos de un mes o de una etiqueta, por ello hay que comprobar que en estos casos tampoco haya enlaces con el mismo texto pero diferente ruta.

También hay que tener en cuenta que Opera, al solicitar la vista de enlaces (Control+Alt+L), si hay dos o más enlaces con nombres distintos pero que apuntan al mismo recurso, sólo muestra el primero, por tanto también hay que evitar combinación.

Me encuentro dos problemas en Blogger:

Cuando se ven varios artículos en una página, si estos tienen el mismo número de comentarios, el literal del enlace a los comentarios será el mismo (por ejemplo "3 comentarios"). Para solucionarlo he incluido a continuación del texto por defecto del enlace (<data:top.commentLabelPlural/>) el texto "en el artículo" seguido del título del artículo (que se inserta con el código <data:post.title/>)
Cuando se visualiza un artículo con comentarios, hay diversos enlaces de una misma papelera "Eliminar comentario" que apuntan a distintas rutas. ~~Me ha sido imposible modificar esto en Blogger.~~ (Nota 16/10/08: obstáculo superado con el código que se explica en los comentarios) Lo mismo me ocurre con los ~~iconos en forma~~ caracteres flecha ▼ del menú "Archivo por fecha"

Por último reviso si se identifica correctamente el idioma del texto del enlace mediante el atributo lang y si se identifica claramente el idioma de la página a la que enlaza con el atributo hreflang.

Después de revisar estos puntos en la plantilla los añado como buenas prácticas y los incluyo dentro de las tareas programadas para revisar los artículos del blog.

Blogger no facilita la inclusión del atributo "title" ni advierte de problemas como los de las anclas o títulos repetidos o de enlaces con el mismo texto y ruta diferente o viceversa (que pueden no estarlo cuando creas un artículo concreto y sí estarlo cuando ves un mes o una etiqueta completa). Sería una buena recomendación a los desarrolladores de Blogger que advirtieran automáticamente de ello.

Día 7: Nuevas ventanas

El punto de verificación 10.1 de la pauta 10 de las WCAG (Web Content Accessibility Guidelines) 1.0 nos dice:

10.1 Hasta que las aplicaciones de usuario permitan desconectar la apertura de nuevas ventanas, no provoque apariciones repentinas de nuevas ventanas y no cambie la ventana actual sin informar al usuario. [Prioridad 2]

Por ejemplo, en HTML, evite usar un marco cuyo objetivo es una nueva ventana.

En las WCAG 2.0 podemos leer:

3.2.5 Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)

The intent of this Success Criterion is to encourage design of Web content that gives users full control of changes of context. This Success Criterion aims to eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of forms after selecting an item from a list, etcetera. Such unexpected changes of context may cause difficulties for people with motor impairments, people with low vision, people who are blind, and people with certain cognitive limitations.

No se debe por tanto utilizar ventanas nuevas, por ello decido eliminar todos los target="blank" que haya incluido a mano en los enlaces (pues no es una opción de Blogger).

Una vez eliminados de la plantilla lo recojo como buena práctica e incluyo en las tareas programadas revisarlo en los artículos ya publicados.

Hay una excepción. Vozme proporciona una versión hablada de los artículos, pero lo hace en ventana nueva. Se advierte de ello al usuario en el atributo "title" del enlace.

Tareas programadas para revisar el blog

Revisar los siguientes puntos en los artículos del blog:

Revisar que no haya estilos definidos mediante los atributo "style" o "border" fruto de la inserción de imágenes, textos en negrita, etc.
Revisar que las imágenes tenga un atributo "alt" correcto y en su caso un atributo "longdesc" adecuado acompañado de un enlace "D".
Revisar que los cambios de idioma en el texto se especifican mediante el atributo "lang".
Revisar que las abreviaturas y los acrónimos estén definidos (con la etiqueta correcta) al menos la primera vez que se usan, y en este caso que se haya expandido también su significado en el propio texto.
Eliminar los target="_blank" de los enlaces
Verificar que el texto de los enlaces es conciso, significativo (no ambiguo como 'pulse aquí') y único.
Comprobar que se ha añadido el atributo title a los enlaces que necesitan información complementaria para que usuario sepa con qué se encontrará cuando lo pulse.
Comprobar que no hay enlaces con el mismo texto y distinta ruta o con distinto texto pero con la misma ruta, ni siquiera cuando se complementen con el atributo title.
Verificar que se ha incluir el atributo lang en los enlaces cuando el idioma del texto del enlace sea diferente al idioma del documento y el atributo hreflang cuando el idioma del recurso al que enlaza sea diferente al idioma del documento
Comprobar que no hay anclas iguales en distintos artículos, pues al verse en una misma página (por ejemplo si están etiquetados igual) colisionan

Revisar una vez al mes:

Vínculos rotos con W3C Link Checker

Comprobar:

La adecuación o no de crear CSS específicas para impresión, dispositivos móviles, etc. alojadas en otro servidor.

Buenas prácticas para crear artículos accesibles

Escribir el artículo en modo "Redactar", pasando al modo "Edición de HTML" sólo para incluir etiquetas o atributos no contemplados en el editor.
Validar la sintaxis XHTML al terminar el nuevo artículo.
Si se insertan imágenes eliminar los atributos "border" y "style" que incluye Blogger
No utilizar los botones del editor de Blogger para poner el texto en negrita o itálica, sino incluir las etiquetas adecuadas manualmente.
Añadir a las imágenes un atributo "alt" adecuado y caso de ser necesario un atributo "longdesc" más un enlace "D".
Indicar los cambios de idioma en el texto mediante el atributo "lang".
Etiquetar adecuadamente abreviaturas y acrónimos la primera que aparecen en el texto, expandiendo también su significado en el propio texto.
Leer el artículo varias veces antes de publicarlo comprobando todos sus enlaces.
No utilizar target="_blank" en los enlaces
El texto de los enlaces debe ser conciso, significativo (no ambiguo como 'pulse aquí') y único.
Se debe añadir el atributo title a los enlaces cuando sea necesario añadir información complementaria para que usuario sepa con qué se encontrará cuando lo pulse.
No se deben incluir enlaces con el mismo texto y distinta ruta o con distinto texto pero con la misma ruta, ni siquiera cuando se complementen con el atributo title.
Se debe incluir el atributo lang a los enlaces cuando el idioma del texto del enlace sea diferente al idioma del documento y el atributo hreflang cuando el idioma del recurso al que enlaza sea diferente al idioma del documento
No repetir el título de los artículos, para serie como las de Imprescindibles, Noticias, etc. numerarlas.
Evitar que un artículo se llame como una etiqueta para evitar enlaces iguales con rutas diferentes.
Utilizar siempre anclas con un nombre único e irreptible para que no colisionen con las de otros artículos cuando se visualicen en una misma página. El código único a utilizar será: fecha_nº, por ejemplo, 01_10_08_1

Tareas para futuras revisiones

Estructura interna de las páginas (encabezados, elementos bien utilizados, etc.)
Medidas relativas
Usabilidad

Notas

(1)La única excepción es el título de los artículos (que linca con el enlace permanente de ese artículo) puesto que me parecía que se perdía legibilidad.

Más accesible a pesar de Blogger (1)

2008-10-01T09:00:00.000+02:00

Artículos relacionados
[15-10-08] Más accesible a pesar de Blogger (2)

Olga y la accesibilidad persiguen a Blogger, pero Blogger corre más deprisa.

Decidí hace unos días que no publicaba ningún artículo más hasta que no hubiera revisado a fondo el blog, tarea que llevo postergando demasiado tiempo.

Este post recoge una crónica resumen de dicha revisión, de mis peleas con Blogger, así como una serie de tareas programadas (que consisten en revisar cada día uno de mis artículos ya publicados chequeando determinados puntos) y unas buenas prácticas que se han de seguir para escribir artículos más accesibles a pesar de Blogger.

Comparto todo ello con vosotros por si a alguien le es de utilidad. El orden de las tareas lo he decidido en función del tiempo libre que disponía cada día, y aunque la revisión podría haber abarcado muchos más puntos (al final del artículo incluyo una lista para futuras revisiones), es todo lo que esta vez ha dado de si mi tiempo.

Os agradecería que me dejarais en los comentarios cualquier propuesta de mejora de diseño, usabilidad o accesibilidad para incorporarlas a futuras revisiones.

ÍNDICE

Día 1: Revisión del código XHTML (eXtensible Hypertext Markup Language)
Día 2: Revisión de estilos y CSS (Cascading Style Sheets)
Día 3: Revisión de imágenes
Día 4: Revisión de idioma
Día 5: Revisión de color
Día 6: Revisión automática con TAW (Test de accesibilidad web)
Día 7: Revisión en distintos navegadores, resoluciones y dispositivos
Día 8: Revisión de abreviaturas y acrónimos
Día 9: Revisión de la navegación semántica
Día 10: Revisión de los scripts
Tareas programadas para revisar el blog
Buenas prácticas para crear artículos accesibles
Tareas para futuras revisiones

DÍA 1: Revisión del código XHTML

Hoy he decidido revisar la sintaxis XHTML del blog y para ello voy a utilizar la herramienta del W3C (Consorcio World Wide Web) Markup Validation Service.

Imagino que el blog no va a tener demasiados problemas de este tipo, puesto que Blogger no te permite guardar la plantilla ni publicar los artículos con errores de sintaxis.

Sin embargo mi sorpresa es mayúscula: el validador anuncia más de 300 errores. Horrorizada los agrupo y comienzo a revisarlos.

Identifico tres tipos de errores:

Errores tipo 1: errores en la sintaxis de los comentarios

Por ejemplo que no se ha cerrado alguna etiqueta o que estas se han escrito en mayúsculas. No puedo (ni debo) modificar los comentarios, de modo que me es imposible corregir estos errores. Por supuesto el comentarista no tiene la obligación de saber XHTML, debería ser Blogger el que se preocupara de corregir este tema.

Errores tipo 2: duplicación de etiquetas

Si el artículo lo has creado en modo "Edición de HTML" y se te ha ocurrido incluir elementos "p", Blogger duplica estos elementos al publicar el artículo. Por otra parte, cualquier retorno de carro lo convierte en un elemento "br".

Por tanto añado como buena práctica escribir siempre en modo "Redactar" y no utilizar el modo "Edición de texto" mas que para añadir los elementos o atributos que el editor no permite (abreviaturas, acrónimos, cambios de edioma, etc.)

Errores tipo 3: rutas dinámicas

El resto de los errores se refieren a las rutas dinámicas en los atributos "href" que contienen símbolos &. La solución es sustituirlos por & pero Blogger los vuelve a publicar como &, de modo que, frustada, me he de resignar con la gran cantidad de errores de sintaxis que esto provoca. ¿Alguna idea para solucionarlo?

DÍA 2: Revisión de estilos y CSS

Hoy he decidido centrarme en la revisión de los estilos y las CSS.

En primer lugar elimino cualquier estilo definido directamente en los elementos mediante el atributo "style". En este punto me encuentro con el primer problema: cada imagen insertada por Blogger contiene una serie de estilos definidos directamente en el elemento mediante el atributo "style" y el atributo "border".

Apunto como buena práctica eliminar ambos atributos de todas las imágenes insertadas en los futuros artículos y añado como tarea programada la revisión de este punto en los artículos ya creados.

También es importante señalar que si utilizas los botones de Blogger para poner un texto en negrita o en itálica, te incluye un atributo "style" en vez de la etiqueta adecuada. Por ello añado como buena práctica no utilizar los botones del editor de Blogger sino incluir las etiquetas correspondientes manualmente.

A continuación pruebo que se puede aumentar el tamaño del texto del blog y reviso mediante la Web Accessibility Toolbar de Explorer que el blog es perfectamente legible sin estilos.

Por último compruebo la sintaxis de los estilos con el validador del W3C CSS Validation Service. Encuentro varios errores que puedo corregir, por ejemplo en la plantilla se habían definido atributos no permitidos como "break-word".

Sin embargo me encuentro con dos problemas insalvables:

Problema 1

La página sigue dando bastantes errores de CSS que no puedo corregir. Estos errores se encuentran en unas CSS cuya llamada se inserta dinámicamente en las páginas y a las cuales no tengo acceso.

Problema 2

Blogger no permite recoger los estilos de la plantilla en una CSS sino que los inserta en cada una de las páginas.

Me gustaría tener CSS diferentes para los distintos dispositivos (móviles, TV, impresión, etc.) así que apunto como tarea programada estudiar la creación de las mismas alojándolas en otro servidor.

DÍA 3: Revisión de imágenes

Hoy quiero revisar las imágenes del blog. En primer lugar me aseguro de que las imágenes decorativas estén definidas en la CSS y las imágenes que sean significativas tengan un atributo "alt" o "longdesc" adecuado (1).

Blogger no obliga a incluir un atributo "alt" a las imágenes que se insertan en los artículos, ni tampoco facilita la inclusión del atributo "longdesc", de modo que, aunque soy cuidadosa en este aspecto, incluyo este punto como buena práctica. Para corregir posibles deslices pasados añado una tarea programada para revisar los artículos ya publicados.

A continuación reviso mediante la Web Accessibility Toolbar de Explorer que efectivamente el blog se ve correctamente con la ausencia de imágenes.

DÍA 4: Revisión de idioma

Hoy decido revisar si está correctamente especificado el idioma en el blog. Para ello compruebo que la plantilla tenga indicado el idioma y la codificación correctamente como expliqué en el artículo "Plantilla base XHTML". Aquí encuentro el primer problema, Blogger incluye como primera línea de la plantilla la codificación UTF-8 siendo esta imposible de modificar.

<?xml version="1.0" encoding="UTF-8" ?>

Aunque he tenido cuidado en señalar el cambio de idioma en el texto mediante el atributo "lang", Blogger tampoco facilita esta práctica, así que incluyo este punto como buena práctica y añado como tarea programada revisarlo en los artículos ya publicados.

Por otra parte, Blogger no permite indicar el cambio de idioma en el título o en el etiquetado de los artículos, puesto que pinta el elemento en vez de interpretarlo.

DÍA 5: Revisión de color

Hoy quiero centrarme en comprobar que no haya información basada en el color. Utilizo en primer lugar la herramienta Vischeck que simula la visualización de las páginas por personas con problemas de ceguera cromática.

A continuación, mediante la Web Accessibility Toolbar de Explorer, compruebo que el blog sea legible en escala de grises y reviso el contraste de color. Me veo obligada a cambiar el color de algún texto que no ofrecía suficiente contraste con el fondo.

DÍA 6: Revisión automática con TAW

Hoy me centro en la revisión automática de la accesibilidad con la herramienta TAW. El blog presenta dos errores que no puedo corregir:

Error de prioridad 1

Blogger inserta automáticamente una barra de herramientas en la parte superior de las páginas. Esta zona es un "iframe" que no presenta texto alternativo en el cuerpo del elemento.

Como no puedo acceder al cuerpo del "iframe" me tengo que conformar con incluir un elemento "noframes".

Error de prioridad 2

El problema se encuentra de nuevo en este "iframe". El validador detecta que utiliza unidades de medida absolutas en lugar de unidades de medida relativas.

Me siento bastante frustrada de no poder corregir estos errores, ¿alguna idea? ¿escribir a los desarrolladores de Blogger?

DÍA 7: Revisión en distintos navegadores, resoluciones y dispositivos

El 99% de las visitas que recibo son mediante cinco navegadores (en este orden): Firefox, Internet Explorer, Chrome, Safari y Opera; y con tres sistemas operativos: MAC, Linux y Windows.

Compruebo en primer lugar que no tengo problemas para visualizar el blog en ninguno de estos navegadores y sistemas operativos.

Después reviso su visualización en dispositivos móviles, para ello utilizo diferentes emuladores (ver Mis validadores)

A continuación lo reviso en un navegador sólo texto como Lynx.

Como la página es muy extensa, para mejorar la navegación incluyo tres enlaces: "Ir al contenido", "Ir a enlaces de interés" e "Ir al menú", que permiten saltar a determinados contenidos con agilidad.

También compruebo que el contenido es accesible con distintas resoluciones. Por último reviso la impresión de las páginas. Estas se imprimen correctamente con Explorer, Opera y Chrome, sin embargo no se imprime bien desde Firefox.

Me gustaría crear un CSS especial para la impresión, que permitiera además aprovechar mejor el papel imprimiendo sólo el contenido del artículo, sin embargo Blogger no permite subir ficheros CSS, así que apunto como tarea programada estudiar la creación de dicha CSS alojándola en otro servidor.

DÍA 8: Revisión de abreviaturas y acrónimos

El tema de las abreviaturas y acrónimos es un tanto peliagudo, más aun si no se tiene claro qué es una abreviatura y qué es un acrónimo y encima se leen los ejemplos erróneos que aparecen en las Técnicas de HTML para las Pautas de Accesibilidad del Contenido Web 1.0 o en la especificación de HTML 4.01.

Para aclarar este tema no hay mejor referencia que el artículo de SIDAR "Abreviaturas versus Acrónimos". En él, además de aclarar la diferencia entre abreviatura y acrónimo y por tanto cuándo se debe utilizar el elemento "abbr" y cuando el elemento "acronym" (2), se especifica que:

Las abreviaturas y los acrónimos deben marcarse con su etiqueta correspondiente al menos la primera vez que se usan en el texto. La primera vez que se usan también debe expandirse su significado en el propio texto. Por ejemplo, "La ONU (Organización de Naciones Unidas) ha decidido...".
Deben marcarse siempre las abreviaturas en las cabeceras de las tablas.
Es una práctica recomendable recoger en una lista, en página aparte o en la misma, todas las abreviaturas y acrónimos para que el lector pueda acudir a ella en caso de duda.

Por otro lado hay que añadir que las abreviaturas de uso común, recogidas en el diccionario de la Real Academia de la Lengua, no requieren ser marcadas, puesto que los lectores de pantalla deberían incluirlas (y suelen hacerlo) en sus diccionarios.

Como no estoy segura de lo rigurosa que he sido en la aplicación de estas normas, decido añadirlas como buenas prácticas en la preparación de post futuros y como tarea programada que me permita revisarlo en los artículos pasado.

Por último, Blogger no permite indicar acrónimos o abreviaturas en el título o en el etiquetado de los artículos, puesto que pinta el elemento en vez de interpretarlo.

DÍA 9: Revisión de la navegación semántica

La plantilla no contiene ningún vínculo definido que permita la navegación semántica, tal y como recomienda el punto de verificación 13.2 de las WCAG 1.0 (Web Content Accessibility Guidelines).

En Plantilla base XHTML explico en detalle cómo y para qué agregar esta información a las páginas.

Como se ve en la imagen, la barra de navegación semántica de Explorer tiene ahora los botones activos. Me hubiera gustado también añadir los vínculos al "artículo anterior" y al "artículo siguiente" pero no he encontrado en Blogger la etiqueta que permita añadir esta ruta automática a la plantilla, ¿alguna idea?.

DÍA 10: Revisión de scripts

Un 6% de los navegadores con los que me visitan no son compatibles con javascript o no lo tienen habilitado, por ello hoy he decidido desactivar los scripts (en las preferencias del navegador) para revisar si se puede interactuar correctamente con el blog.

Compruebo que la búsqueda en el blog funciona y que la agenda sigue siendo accesible.

Como se aprecia en la imagen, aparece un mensaje advirtiendo de que se puede consultar la agenda en formato texto pulsando un enlace. La agenda es un "iframe" a cuyo contenido no tengo acceso, por tanto no puedo modificar el mensaje que aparece. Hubiera deseado mejorar la redacción del mismo y que el texto del enlace fuera diferente a la ruta.

Al final he decidido incluir un enlace siempre visible (señalado en la imagen con una flecha) a la versión texto de la agenda, de este modo, los usuarios que por ejemplo no pueden visualizar los "iframes", o que a pesar de tener activo el javascript utilicen tecnologías asistivas que le impidan acceder al contenido de la agenda, no tengan problemas en consultarla.

Por otro lado, todos los artículos tenían al final una opción "escuchar este post". Este enlace fallaba cuando los artículos eran demasiado extensos (lo cual es muy habitual en mí) de modo que lo he cambiado por "escucha el texto seleccionado". Estas funcionalidades las proporciona vozme.com mediante un "script" que hay que incluir en la plantilla. Este script no tiene una alternativa accesible, de modo que no me ha quedado más alternativa que advertir de esta circunstancia en el elemento "noscript".

Al final de cada artículo hay también una serie de iconos que permiten añadir el artículo a Digg, Technorati, etc.

La única manera de incluir en sus enlaces la dirección dinámica del artículo fue mediante javascript, de modo que añado un elemento "noscript" con dichas direcciones para que sean accesibles sin el javascript activo.

Por último me doy cuenta de que no aparece el icono de las estadísticas, puesto que el "script" que proporciona StatCounter pinta la imagen. Como las estadísticas son de carácter privado y por tanto su ausencia no resta funcionalidad a la página, no le doy mayor importancia. Tampoco aparece el tooltip de Coloriuris, pero como la información de esa ventanita está disponible en la página a la que enlaza el icono, la ausencia de esta ventana no resta accesibilidad a la página.

Tareas programadas para revisar el blog

Revisar los siguientes puntos en los artículos del blog:

Revisar que no haya estilos definidos mediante los atributo "style" o "border" fruto de la inserción de imágenes, textos en negrita, etc.
Revisar que las imágenes tenga un atributo "alt" correcto y en su caso un atributo "longdesc" adecuado acompañado de un enlace "D".
Revisar que los cambios de idioma en el texto se especifican mediante el atributo "lang".
Revisar que las abreviaturas y los acrónimos estén definidos (con la etiqueta correcta) al menos la primera vez que se usan, y en este caso que se haya expandido también su significado en el propio texto.

Estudiar la adecuación o no de crear CSS específicas para impresión, dispositivos móviles o TV alojadas en otro servidor.

Buenas prácticas para crear artículos accesibles

Escribir el artículo en modo "Redactar", pasando al modo "Edición de HTML" sólo para incluir etiquetas o atributos no contemplados en el editor.
Validar la sintaxis XHTML al terminar el nuevo artículo.
Si se insertan imágenes eliminar los atributos "border" y "style" que incluye Blogger
No utilizar los botones del editor de Blogger para poner el texto en negrita o itálica, sino incluir las etiquetas adecuadas manualmente.
Añadir a las imágenes un atributo "alt" adecuado y caso de ser necesario un atributo "longdesc" más un enlace "D".
Indicar los cambios de idioma en el texto mediante el atributo "lang".
Etiquetar adecuadamente abreviaturas y acrónimos la primera que aparecen en el texto, expandiendo también su significado en el propio texto.

Tareas para futuras revisiones

Atajos de teclado
Estructura interna de las páginas (encabezados, elementos bien utilizados, etc.)
Medidas relativas
Enlaces (enlaces rotos, nuevas ventanas, "title", orden de tabulación, revisar enlaces con el mismo literal, colores de los enlaces, acceso mediante ratón, enlaces tipo "pulsar aquí, comentamos por aquí", etc.)

NOTAS

(1) Como por ejemplo en la imagen del artículo "Disciplinas relacionadas con la Usabilidad", que tiene atributo "alt", "longdesc" y un enlace "D".

(2) El truco para saber si la forma abreviada que vamos a utilizar es una abreviatura o es un acrónimo está en ver si la traducimos, si va terminada en punto o si conserva la tilde (en cuyo caso será una abreviatura como por ejemplo: Sr., págs.) o si por el contrario la leemos tal cual está escrita, no va terminada en punto ni conservan la tilde (en cuyo caso es un acrónimos como W3C, XHTML)

Artículos relacionados
[15-10-08] Más accesible a pesar de Blogger (2)

Documentos que recomiendo conocer (1)

2008-07-29T18:00:00.002+02:00

Artículos relacionados
[15-11-08] Documentos que recomiendo conocer (2)

1
"Guía Web 2.0". La Guía Web 2.0 es el instructivo gubernamental orientado a mejorar la usabilidad en los sitios del Gobierno de Chile. Se puede descargar en PDF.

2
"Web Accessibility for Older Users: A Literature Review" del W3C.

Ese documento contiene análisis y revisiones de recomendaciones y artículos relacionados con las necesidades de las personas de edad avanzada y la accesibilidad web requerida por los efectos de esa avanzada edad en las personas, comparándolas con las necesidades de las personas ya descritas en las Pautas de Accesibilidad para el Contenido en la Web.

Vía Torres Burriel

Artículo relacionado: "Análisis de usabilidad de los portales en español para personas mayores" de NSU.

3
"Sistemas y esquemas de evaluación de la conformidad para requisitos de accesibilidad", informe realizado en el grupo europeo Project Team CEN/BTWG 185 "e-Accessibility".

Artículo relacionado: "Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España" en este blog.

4
"El imperativo de la accesibilidad: Implicaciones de la Convención de Derechos de las Personas con Discapacidad para las Tecnologías de la Información y la Comunicación" de G3ict, Iniciativa Global para las Tecnologías de la Información y la Comunicación inclusivas.

Trata de los retos y oportunidades que supone la aplicación de la Convención en lo referente a la accesibilidad de las TIC.

5
"Decálogo de León", conclusiones de la Conferencia Europea EDeAN (European Design for all e-Accessibility Network) que se celebró en León (España) los días 12 y 13 de junio de 2008 y en la que participaron más 200 expertos y representantes de organismos nacionales y europeos.

6
UNE 139804:2007. Requisitos para el uso de la lengua de signos en redes informáticas

7
WCAG Samurai Errata for Web Content Accessibility Guidelines (WCAG) 1.0

Artículos relacionados
[15-11-08] Documentos que recomiendo conocer (2)

Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España

2007-05-10T19:58:00.052+02:00

Última actualización: 14 de mayo de 2012

Índice

¿Qué es una certificación?
¿Qué certificaciones de accesibilidad web existen en España?
- 2.1. Certificación "Accesibilidad TIC" de AENOR
- 2.2. Certificación "Euracert"
Sello de Calidad de Internet IQ
Metodología de Revisión de la Accesibilidad de la WAI
Metodología de Evaluación de Conformidad con la Accesibilidad en Sitios Web (WCAG-EM) del W3C (para evaluar de acuerdo a las WCAG 2.0, primer borrador de marzo de 2012)
Metodología para la inclusión de la accesibilidad en todas las fases de desarrollo de un sitio web
Otras etiquetas habituales

1. ¿Qué es una certificación?

La Organización Internacional de Normalización (ISO) define certificación como

atestación por tercera parte relativa a productos, procesos, sistemas o personas, entendiéndose por atestación la actividad que se basa en la decisión tomada luego de la revisión y consiste en autorizar y emitir una declaración de que se ha demostrado que se cumplen los requisitos specificados. Esta declaración puede ser un certificado o una marca de conformidad.
En todos los casos la declaración garantiza a los usuarios de la evaluación de la conformidad que se cumplen los requisitos especificado. Para que la certificación se realice en forma imparcial debe ser realizada por una tercera parte, es decir un organismo independiente de los respectivos intereses del proveedor del objeto de la certificación (primera parte) y del usuario de la certificación (segunda parte).
Los requisitos especificados, a los que hace mención la definición de certificación, pueden estar contenidos en normas, especificaciones técnicas, reglamentos u otros documentos normativos.

2. ¿Qué certificaciones de accesibilidad web existen en España?

2.1 Certificación "Accesibilidad TIC" de AENOR

A comienzos de 2007 AENOR (Asociación Española de Normalización y Certificación) lanzaba la certificación "Accesibilidad TIC" web en colaboración con:

la Fundación CTIC (Centro Tecnológico de la Información y la Comunicación), constituida por un patronato de empresas del sector tecnológico y por el Gobierno del Principado de Asturias, que alberga la Oficina Española del W3C y es creadora del TAW (Test Accesibilidad Web).
ESI (European Software Institute) que forma parte de la Corporación Tecnológica Tecnalia y fue creada por la Comisión Europea con el apoyo del Gobierno Vasco.

AENOR calificó en febrero de 2007 a tres técnicos de European Software Institute (ESI-Tecnalia) como evaluadores expertos en la norma UNE de Accesibilidad Web.

5 de febrero de 2007 [...] Estos especialistas trabajarán como inspectores cualificados de acuerdo a los procedimientos vigentes en la certificación de productos y según los requisitos deontológicos establecidos por AENOR, especialmente, en lo relativo a la independencia para asumir labores de asesoramiento y consultoría. [En Fundación CTIC]

La Fundación CTIC tenía anteriormente su propia metodología para la evaluación web y ofrecía servicios de consultoría, auditoría y certificación de accesibilidad con el sello:

[..] hemos desarrollado una metodología de evaluación y soporte basada en los estándares y especificaciones del W3C para detectar y corregir problemas de accesibilidad y estandarización, mediante la combinación de herramientas de revisión automática y manual. [En Fundación CTIC]

Junto con ESI también otorgaba el sello de "Certificación Internacional de Accesibilidad Web" que definían como "una certificación internacional independiente basada en las pautas WCAG 1.0 (Web Content Accesibility Guidelines) del W3C (World Wide Web Consortium), elaborada en base a una metodología de evaluación e inspección que permite detectar problemas de accesibilidad combinando herramientas de revisión automática y manual". El sello de esta certificación era:

Estas dos certificaciones y sellos han desaparecido, ya que como se ha indicado, actualmente las dos fundaciones están implicadas en la certificación "Accesibilidad TIC" de AENOR.

La certificación "Accesibilidad TIC" de AENOR certifica en base a la Norma UNE 139803:2004 Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos Web) aprobada mediante Resolución 2855 de fecha 2005-01-25 de la Dirección General de Desarrollo Industrial. (B.O.E. nº 43-2005 de fecha 2005-02-19).

Una norma es un documento público al que pueden acceder todas las personas interesadas, previo pago de un pequeño canon. El organismo normalizador pertinente, en este caso AENOR, es el garante de la disponibilidad del documento y su estabilidad, asegurando un proceso formal de cambio.
Podemos garantizar que la norma es plenamente compatible con las Directrices de Accesibilidad para el Contenido Web 1.0 del WAI, e incluso contiene un anexo en el que se presenta la equivalencia entre los puntos de la norma española y los de dichas directrices.
La redacción de la norma actual y por tanto revisión de la anterior se llevó a cabo en el seno del Grupo de Trabajo 3 del AEN/CTN139/SC8 [...] coordinado por Emmanuelle Gutiérrez y Restrepo, Directora General de la Fundación Sidar. En dicho grupo participan representantes de instituciones, organismos públicos y empresas privadas diversas, cuya relación puede consultarse en la página del Subcomité.
[En Sidar]

La Norma UNE 139803 es compatible con las WCAG 1.0: si se hace un sitio web conforme con la prioridad 1 y 2 de las WCAG 1.0 también se cumple con casi todos requisitos de la norma UNE. En el anexo A de la Norma se detalla la relación que hay entre los puntos de verificación de las WCAG 1.0 y los requisitos de la Norma UNE 139803. Sin embargo hay que tener en cuenta 3 puntos que cambian de prioridad.

En vez de hacer una traducción literal, se volvió a redactar cada requisito, partiendo de la experiencia y de la ingente documentación existente sobre la accesibilidad en la web, incluyendo el borrador de las WCAG 2.0. Aportan sus propios ejemplos y aclaraciones (que son mera información y no obligan a nada).

Hay que recordar que la legislación española exige el cumplimiento de las prioridades 1 y 2 de dicha Norma, aunque se indica que se podrán certificar con normas técnicas españolas, normas aprobadas por organismos de normalización europeos y en su defecto por otras normas internacionales aprobadas por organismos oficiales de normalización. Sería, por tanto, igual de válida la certificación de AENOR que la certificación Euracert.

La certificación de AENOR sigue un proceso que consiste en evaluar un sitio web, combinando sistemas de revisión automática con metodologías de inspección manual, garantizando entre otras cosas: el orden lógico de presentación en pantallas para lectura lineal, alto contraste, tamaño de textos, impresión amigable, accesibilidad de los contenidos textuales, etc. Sólo certifica niveles de conformidad AA y AAA y ofrecen dos tipos de certificación:

“Certificado AENOR - Marca N de Accesibilidad TIC”: para obtener este certificado es necesario, además del cumplimiento de las Pautas de Accesibilidad, que la organización haya implantado y mantenga un Sistema de Gestión de la Accesibilidad. Se hace un seguimiento semestral de la certificación.
“Certificado de conformidad con la Norma 139803”: se otorga a aquellas organizaciones que únicamente desean demostrar la conformidad de su sitio Web con los requisitos de la Norma de referencia (UNE 139803) de manera puntual. No tiene seguimiento de la certificación ni por tanto garantía de continuidad.

El 9 de mayo de 2007 se anunciaba que ocho webs estrenaban este certificado de accesibilidad:

Las primeras páginas web en España que han obtenido el certificado de accesibilidad son los portales de la Agencia Valencia de Turismo, del Ayuntamiento de Ermua, del Ayuntamiento de Gijón, del Ayuntamiento de Zaragoza, de CajAstur, del Centro Europeo de Empresas e Innovación de Vizcaya, de la Diputación Foral de Vizcaya y del Gobierno del Principado de Asturias. [En Fundación CTIC]

Loïc Martínez Normand, presidente del grupo de normalización AEN/CTN139 en AENOR, que asistió al acto de presentación de los certificados oficiales de accesibilidad web de AENOR, puntualizó en la lista de accesoweb que AENOR sólo audita, nunca participa en actividades de desarrollo ni ayuda a corregir los problemas, y que sólo certifican los niveles AA y AAA. Más información en la presentación de AENOR Certificación Accesibilidad TIC

El 20 de enero de 2010, Loïc Martinez Normand explicó en el "Módulo 1: WCAG 2.0 Armonización" de las Jornadas SIDAR 2010 que existe una solicitud formal de la Administración para la actualización de la Norma de acuerdo a las WCAG 2.0

Se señaló además que está previsto que la Norma mantenga el mismo nombre, por lo tanto, una vez aprobada, no será necesario modificar la ley, sino que desde ese momento será obligatorio cumplir con las WCAG 2.0

Loïc explicó que el deseo de AENOR no es reinterpretar las WCAG 2.0 como se hizo con las WCAG 1.0 y la actual Norma, sino que desean que la nueva Norma sea igual al 99% con las WCAG 2.0

Por último, comentó que en ese momento se vivía un parón porque la Comisión Europea ha pedido que no se publiquen nuevas normas hasta que se defina a nivel europeo el estándar de requisitos funcionales de accesibilidad para compras públicas de TIC accesible, que es posible que incorporen las WCAG 2.0

2.2 Certificación Euracert

Durante el año 2006 se publicó el esquema europeo de certificación CWA N°15554 y la metodología europea de evaluación de la accesibilidad web (UWEN, Metodología de Evaluación Web Unificada).

En demanda de la Comisión Europea, el proyecto Support-EAM (Supporting the creation of an a eAccesibility Mark, entre cuyos partners está Tecnosite o BrailleNet) lanzó y condujo unas jornadas de trabajo en el CEN (European Commitee for Standardization), en la que participaron 39 organizaciones de 16 países de Europa que produjo un acuerdo (CWA nº 15.554:2006) el 15 de abril de 2006.

Publicaron un documento que presenta el esquema de certificación de la accesibilidad de la Web en Europa "Especificaciones para el esquema de la evaluación de la conformidad y marca de calidad sobre accesibilidad Web": [CEN Workshop Agreement (CWA) N°15554 “Specifications for a Web Accessibility Conformity Assessment Scheme and a Web Accessibility Quality Mark"].

Presentado por el CEN como un acuerdo europeo de primer nivel sobre cómo esquemas estándar de evaluación comúnmente utilizados en Europa pueden ser aplicados en la evaluación de la conformidad de la accesibilidad Web.

Este acuerdo refleja tres tipos de peticiones que fueron identificadas:

Declaración de conformidad por proveedores (de acuerdo con la ISO/IEC 17050)
Inspección (de acuerdo con la ISO/IEC 17020)
Certificación de productos (de acuerdo con la ISO/IEC 45015)

En el mismo año se presenta UWEN 1.0 (Unified Web Evaluation Methodology), la metodología europea de evaluación de la accesibilidad web. El objetivo fue ser totalmente compatible con las pautas de WCAG 1.0. En la actualidad, la UWEM se limita a las pautas de prioridad 1 y 2 y presenta un método único tanto para la evaluación por un experto humano como de manera automática por interfaces de máquinas.

La última versión es la UWEN 1.2 y hay un plan para adaptarla a las WCAG 2.0 todavía sin ejecutar que dará lugar a la UWEN 2.0.

La UWEN fue el resultado del esfuerzo conjunto de tres proyectos europeos aunados en un grupo llamado WAB Cluster. 23 organizaciones europeas participan en estos tres proyectos europeos cuyos nombres son EIAO (para la creación de un observatorio de la Web), Support EAM (Supporting the creation of an a eAccesibility Mark, un proyecto de certificación ) y BenToWeb (para el desarrollo de herramientas de evaluación)

La metodología ha sido concebida para cumplir los siguientes requisitos:

Conformidad técnica con los documentos de técnicas y las recomendaciones existentes de la Iniciativa de Accesibilidad a la Web (WAI)
Independencia con respecto a instrumentos y navegadores
Interpretación única
Replicabilidad
Traducción
Conformidad con la reglamentación europea

En la metodología se incluyen datos sobre:

La definición y el muestreo de un sitio Web.
El informe, la interpretación y la integración/agregación de los resultados de las pruebas.

La UWEN se encuentra disponible es españo en Metodología Unificada de Evaluación Web (UWEM 1.0.) y se puede ampliar información sobre la misma en Esquema de Certificación y Sello de Calidad, Support EAM

Esta metodología UWEN es la utilizada por la certificación Euracert.

A nivel europeo había ya varias metodologías de evaluación previas a la UWEN: AccessiWeb ([ACCESSIWEB]), Drempelvrij.nl ([DREMPELVRIJ]) o en España MEWA ([MEWA, Metodología Web Accesible MEWA]). MEWA era la metodología de Technosite (o Fundosa Teleservicios, empresa perteneciente a la Fundación ONCE, de la que depende el portal Discapnet), que ofrecía servicios de consultoría, auditoría y certificación de accesibilidad con el sello:

Gracias al trabajo sobre armonización hecho a nivel europeo por organizaciones especializadas en accesibilidad Web y con el respaldo de la Comisión Europea, actualmente existen recursos sobre accesibilidad Web considerados como referencias:
recomendaciones internacionales: WCAG 1.0 de WAI,
una metodología de evaluación (UWEM): la versión 1.0 de la UWEM ofrece una interpretación de las WCAG 1.0 de WAI (prioridades 1 y 2),
un esquema de evaluación de la conformidad: el Acuerdo Adoptado en el workshop CEN es un documento que describe las "Especificaciones para un esquema sobre evaluación de la conformidad y una marca de calidad sobre accesibilidad Web". 3 esquemas sobre evaluación de conformidad son presentados:

Inspección por terceras partes,
Certificación por terceras partes,
Autodeclaración.
[En Euracert]

A comienzos del año 2007, ONA (Bélgica), Technosite (España) y la Asociación BrailleNet (Francia), que como dijimos tenían metodologías propias de evaluación, lanzan la etiqueta Euracert, la primera etiqueta de certificación de accesibilidad de sitios web a nivel europeo, diseñada sobre las bases de estas referencias con objeto de permitir el reconocimiento de sitios web etiquetados en otros países. Define un marco general que permite un reconocimiento mutuo entre organizaciones que trabajan sobre las pautas y recomendaciones internacionales. Para ser una organización Euracert autorizada es necesario:

publicación en línea de la metodología UWEM y la tabla de correspondencia entre su metodología y las UWE en su idioma nacional.
firma de una Carta de entendimiento con un Socio de Euracert (consultar la página Listado de Socios) en las bases de la UWEM y el Acuerdo Adoptado en el workshop CEN.
dar la posibilidad a cada nuevo sitio web etiquetado de obtener la etiqueta Euracert como añadido a su etiqueta nacional.

[En Eurocert]

En este contexto Tecnosite establece una correspondencia entre su metodología MEWA y la UWEN 1.0 con la correspondiente “Tabla de correspondencia MEWA/UWEN”. Bankinter fue la primera primera entidad financiera en lograr la certificación europea de accesibilidad web 'Euracert' el 11 de abril de 2007:

Bankinter se ha convertido en la primera entidad financiera en lograr la certificación europea de accesibilidad web 'Euracert', que acredita que las páginas de Internet del Banco cuentan con los estándares más elevados de accesibilidad y cumplen en ese sentido con las pautas establecidas por las diferentes ganizaciones especializadas y con el respaldo de la Comisión Europea, lo que significa que son accesibles para el mayor número de personas, independientemente de sus limitaciones. La etiqueta Euracert cubre los dos niveles contemplados por la Comisión Europea para la metodología unificada de Evaluación de Accesibilidad Web (UWEM 1.0), niveles A y AA según pautas WCAG 1.0 W3C/WAI. [En Technosite]

3. Sello de Calidad de Internet IQ

iQUA (Agencia de Calidad de Internet, con socios como el Consejo Audiovisual de Cataluña, el Consejo Audiovisual de Andorra, el Consejo Audiovisual de Navarra y Red.es, y con más de mil entidades asociadas, otorga el sello de calidad IQ.

El sello de calidad IQ consiste en un logotipo que se inserta en las páginas web y que acredita que éstas cumplen con los estándares de calidad requeridos por IQUA.
IQUA otorga el sello de calidad basándose en el código de conducta de la Agencia, previa auditoría de la página web para comprobar si cumple con todos los estándares de calidad (criterios que se emplean en las auditorías para la obtención del sello de calidad IQ).
IQUA se reserva el derecho a realizar auditorías aleatorias de las páginas web a las que se haya otorgado el sello IQ, para comprobar si siguen cumpliendo con los niveles de calidad exigidos.
Asimismo, los usuarios de Internet podrán denunciar ante IQUA las presuntas no-conformidades que detecten en páginas que tengan el sello de calidad IQ. En ambos casos, cuando se detecte que la página web no mantiene la calidad exigida, se concederá un plazo para subsanar las no-conformidades. Si éstas persisten, IQUA invalidará el sello de calidad.

Los criterios que se emplean en las auditorías para la obtención del sello de calidad “IQ” incluye, no sólo aspectos de usabilidad o accesibilidad:

Aspectos legales: cumplimiento de la LSSI-CE (Ley de Servicios de la Sociedad de la Información y el Comercio Electrónico (LSSI-CE), de la LOPD (Ley Orgánica de Protección de Datos) y de la Ley de Propiedad Industrial e Intelectual.
Accesibilidad: "cumple unos mínimos de accesibilidad, siguiendo los estándares del W3C)"
Se hará un chequeo para comprobar si se han tenido en cuenta los criterios de Accesibilidad (revisión mediante T.A.W y pruebas de navegación con JAWS).
Nota: Se considera que un sitio web es accesible siempre que satisfaga el nivel AA y que se aplique en su totalidad la prioridad 2 de las pautas WAI. Deberán cumplirse en la medida de lo posible (la propia página web debería ser accesible), si bien, IQUA considera válido que disponer de una versión (reducida) de la página web lternativa que sea accesible.
[En Iqua]
Usabilidad: "la información se visualiza correctamente y dispone de las herramientas necesarias para su visualización)"
Identificación: "la web está claramente identificada"
Contenidos: "los contenidos cumplen unos mínimos de calidad"
Seguridad: "dispone de mecanismos para garantizar las transacciones"

El sello se puede ver por ejemplo en Caixa Penedès enlado con un certificado “Otorgado, por su cumplimiento del código de conducta de IQUA”.

Es muy criticada la manera de insertar este sello en las páginas, mediante un script, sin información alternativa ni siquiera en el noscript, y la manera en que se abre (con un window.open) en una ventana de tamaña fijo y sin barras herramientas o de navegación.

La verdad es que en lo referente a accesibilidad este sello se queda, a mi juicio, bastante cojo, no hay más que pasar por el TAW las páginas que certifica.

4. Metodología de Revisión de la Accesibilidad de la WAI

validación automática de la accesibilidad
validar la sintaxis del lenguaje de marcas
validar la CSS
utilizar diferentes navegadores gráficos y versiones, con distintas configuraciones (sin ratón, sin script, sin CSS, sin marcos, sin gráficos, etc.)
utilizar otros tipos de navegadores solo-texto (Lynx), lector de pantalla (Jaws), un navegador con conversión texto-voz, una pantalla pequeña, etc.
revisar la gramáticas y la ortografía
revisar la claridad, simplicidad y legibilidad del contenido
revisión por usuarios discapacitados noveles o expertos

Más información en "Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI"

5. Metodología de Evaluación de Conformidad con la Accesibilidad en Sitios Web (WCAG-EM)

Lo trato con detalle en el artículo Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

6. Metodología para la inclusión de la accesibilidad en todas las fases de desarrollo de un sito web

El Diseño Inclusivo es un marco metodológico mejorado a partir del Diseño Centrado en el Usuario (DCU) que intenta satisfacer las necesidades de un mayor rango de usuarios que aquellos representados por el 'usuario medio', involucrando a usuarios con necesidades especiales (ver "Diseño Inclusivo: Marco Metodológico para el Desarrollo de Sitios Web Accesibles", Yusef Hassan Montero y Francisco J. Martín Fernández, 2003)

El proceso de Diseño Inclusivo sigue las mismas fases reiterativas que el DCU, esto es, un continuo Diseño-Prototipado-Evaluación (ver Reseña "Just Ask: Integrating Accessibility Throughout Design", reseña en español del libro recomendado como guía de referencia por la WAI)

Una de las metodologías de Diseño Inclusivo más sólidas es AWA (Accessibility for Web Applications) que explico en detalle en el artículo Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA

7. Otras etiquetas habituales

Hay muchos organismos y empresas privadas que ofrecen certificaciones, auditorías, consultorías, informes o evaluaciones de accesibilidad, así como es cada vez más habitual que las empresas incluyan la accesibilidad como un requisito imprescindible al desarrollar aplicaciones web.

Si una empresa realiza éstas labores es necesario que especifique claramente la metodología que utiliza, el curriculum de los profesionales que realizan la revisión, las herramientas automáticas y los dispositivos en los que hace la validación, la muestra de páginas utilizada, etc. Por otro lado, se hace imprescindible un seguimiento para asegurar que el portal siga siendo accesible.

Las etiquetas más habituales que se incluyen en las páginas son:

7.1 Símbolo internacional de la accesibilidad Web

Expresa el compromiso de esa web por intentar ser accesible para todos. Actualmente no se suele utilizar.

7.2 Logotipos de validación del W3C

Los logotipos oficiales del W3C se pueden ver en "Validation icons" del W3C, que incluye entre otros los de validación de sintaxis CSS o (X)HTML como En "Logos and icons" el W3C indica que los iconos se distribuyen bajo licencia de modo que no pueden modificarse, es decir, hay que utilizar los oficiales. También indican que deben enlazar con la validación de la página en el correspondiete revisor automático del W3C.

7.3 Logotipos de validadores automáticos de accesibilidad

Los validadores automáticos de accesibilidad más utilizados en España son:

TAW (Test Accesibilidad Web)

HERA

Se pueden incluir estos logotipos para indicar que la revisión automática de dicha herramienta verificó determinado nivel de adecuación. También es habitual encontrar el icono de revisión con Bobby, sin embargo este revisor es estadounidense y es específico para la sección 508 (Normas de Accesibilidad Electrónica y para la Tecnología de la Información).

7.4 Logotipos del nivel de Conformidad con las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0)

La inclusión de estos iconos es una declaración del autor de la página en la que se insertan de que ésta se ajusta al nivel correspondiente de las Directrices de Accesibilidad para el Contenido Web 1.0 del W3C.

Cada uno de ellos debe enlazar con la página correspondiente del W3C. El W3C no verifica las declaraciones, sino que son los proveedores de contenido los responsables únicos del uso de estos logos. Por omisión, un icono de conformidad se refiere a una única página. Si la declaración pretende aplicarse o incluir más de una página, el icono de conformidad debe ir acompañado de información explícita del alcance, explicando qué páginas cubre la declaración.

Tenga en cuenta, por favor, que el uso de este logo no depende de una revisión automática. No existe aún ninguna herramienta que pueda hacer una revisión completa de todos los puntos de verificación que hay en las directrices, y una revisión automática completa en el futuro puede seguir siendo difícil o imposible. Por ejemplo, algunos puntos de verificación se basan en una interpretación de qué información es "importante" o en si el texto equivalente para un elemento no textual es exacto. También es posible que un revisor de la accesibilidad automático presente "falsos negativos" o "falsos positivos" debido al tipo de marcado en una página. Por estas razones, los logos de esta página se usan sólo para indicar una declaración de conformidad hecha por el autor de la página, no una conformidad conseguida mediante un validador automático. [En W3C]

7.5 Logotipos del nivel de Conformidad con las Directrices de Accesibilidad para el Contenido Web 2.0 (WCAG 2.0)

Como indica el W3C en "W3C Web Content Accessibility Guidelines 2.0 Conformance Logos", para promover la accesibilidad de las páginas web se ofrece la posibilidad de incluir los iconos de adecuación a las WCAG 2.0

Tal y como se indica no se deben modificar los logotipos. Por defecto, un icono de conformidad se refiere a una sola página, de lo contrario el icono de conformidad deberá ir acompañado de la información explícita de cuáles son las páginas a las que se refiere. Más información en: WCAG 2.0 Niveles y declaraciones de conformidad WCAG 2.0

7.6 Sello GESAccesibilidad

GESAccesibilidad surge como resultado del proyecto Sistema de gestión de la accesibilidad web (TSI-020100-2008-355 y TSI-020100-2009-316), proyecto de desarrollo experimental financiado por el Ministerio de Industria, Turismo y Comercio dentro del Subprograma Avanza I+D en 2008 y 2009, liderado por Taller Digital de la Universidad de Alicante en colaboración con la Fundación Biblioteca Virtual Miguel de Cervantes.

El sello lo tiene por ejemplo la web del Síndic de Greuges de la Comunitat Valenciana.

7.7 Sello Universal Accesskey

Lo otorga accesskey.org Lo tiene por ejemplo footyboots4kids.com

7.8 Sello MobileOk del W3C

El objetivo de las Mobile Web Best Practices 1.0 (recomendación desde julio de 2008) es servir de pautas para mejorar la experiencia de usuario en la navegación web a través de dispositivos móviles.

El W3C mobileOK Basic Test es el esquema para evaluar la conformidad de un sitio web de acuerdo con las Mobile Web Best Practices. Es utilizado por el validador automático online del W3C W3C mobileOK Checker. Como en todo validador automático, sólo se evalúan aquellos puntos que pueden verificarse de forma automática, los demás deberán ser verificados de forma manual.

La nota de agosto de 2009 W3C mobileOK Scheme 1.0 señala que los proveedores pueden identificar sus páginas como mobileOK, es decir, que pasan el validador automático y por tanto las pruebas básicas en él implementadas. En ese caso pueden añadir el icono:

Consultar "W3C mobileOK Logo and Policy"

Más información sobre las MWBP y su relación con las WCAG en: Accesibilidad y usabilidad móvil: web móvil y app nativa