WCAG Evaluation Methodology (WCAG-EM) 2.0 del W3C

Han pasado 14 años desde que reseñé el proceso de la primera versión de la WCAG-EM 1.0 (2012-2014) en el artículo "Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) 1.0".

Esta semana, el 23 de julio de 2026, se ha publicado la nueva versión de la WCAG-EM del W3C: WCAG Evaluation Methodology (WCAG-EM) 2.0.

En Europa, incluida España, las auditorías de accesibilidad se realizan conforme a la EN 301 549, que incorpora los criterios de nivel A y AA de las WCAG junto con otros requisitos adicionales. Aun así, la metodología resulta perfectamente extrapolable a la norma europea.

Índice de contenidos:

• ¿Qué es la WCAG Evaluation Methodology (WCAG-EM) 2.0?
• ¿Qué conocimientos hay que tener para aplicar correctamente la WCAG-EM?
• Tipos de productos que se pueden evaluar y factores que pueden influir
• Pasos de la metodología
• Qué no dice la WCAG-EM 2.0 (afirmaciones incorrectas en redes sociales)
• Referencias

¿Qué es la WCAG Evaluation Methodology (WCAG-EM) 2.0?

La WCAG-EM proporciona una metodología para la evaluación de todo tipo de productos digitales de acuerdo con las WCAG. Es decir, describe un proceso para evaluar en profundidad si una muestra representativa de un producto digital cumple con los criterios de accesibilidad. La metodología no especifica estos criterios y es independiente de herramientas de evaluación, navegadores web o tecnologías de asistencia específicos.

La gran novedad de esta versión 2.0 es que no solo tiene en cuenta los sitios web, como la versión 1.0, sino que puede aplicarse a cualquier producto digital, como una aplicación móvil o un quiosco interactivo.

¿Qué conocimientos hay que tener para aplicar correctamente la WCAG-EM?

La WCAG-EM ofrece una guía para realizar evaluaciones de accesibilidad siguiendo un mismo método, evitando errores habituales y obteniendo resultados más comparables.

Para aplicar correctamente la WCAG-EM se requieren conocimientos sólidos sobre:

• las WCAG y cómo evaluar el contenido conforme a ellas,
• diseño accesible,
• tecnologías de asistencia y estrategias de adaptación,
• cómo las personas con diferentes discapacidades utilizan los productos digitales y los problemas habituales que se encuentran,
• técnicas, herramientas y métodos de evaluación para identificar las barreras que enfrentan las personas con discapacidad.

La metodología no abarca la inclusión de personas con discapacidad. Sin embargo, lo recomienda encarecidamente:

La participación de personas con discapacidad (que no sean evaluadores experimentados ni formen parte de un equipo de revisión) puede ayudar a identificar barreras de accesibilidad adicionales que no se detectan fácilmente solo con la evaluación de expertos. Si bien no es un requisito para utilizar esta metodología, se recomienda encarecidamente que los evaluadores involucren a personas reales con una amplia gama de capacidades durante el proceso de evaluación.

Recurso relacionado: Involving Users in Evaluating Web Accessibility

Por último, recordemos que existe una herramienta de apoyo, la WCAG-EM Report Tool que se espera que se actualice a la WCAG-EM 2.0 a final de año.

Artículo relacionado: WCAG-EM Report Tool. Herramienta de generación de informes de una evaluación de accesibilidad

Tipos de productos que se pueden evaluar y factores que pueden influir

El documento incluye una lista no exhaustiva de los diferentes tipos de productos digitales con los que se podría aplicar esta metodología, así como las peculiaridades de cada uno de ellos:

• Sitios web de diferentes tamaños: para los sitios web con muchas páginas se puede utilizar el procedimiento de muestreo para evaluar mediante una muestra representativa; por su parte, los sitios web sencillos se podrían evaluar en su totalidad
• Aplicaciones web: suelen ser más complejas e interactivas, con gran cantidad de contenido y funcionalidades que se generan dinámicamente. Por ello, su evaluación suele requerir más tiempo, esfuerzo y un conjunto de datos más amplio. Entre ellas se encuentran los clientes de correo electrónico, los editores de documentos, las redes sociales, las plataformas para compartir vídeos y las plataformas de reservas.
• Aplicaciones nativas, híbridas y multiplataforma: las pantallas de la muestra se pueden identificar mediante capturas o descripciones de la ruta que conduce hasta ellas.
• Interfaces de quioscos, de terminales de autoservicio o de decodificadores: si la interfaz se puede probar en un navegador aplicarían las consideraciones para aplicaciones web. Cuando se evalúa la interfaz mientras se ejecuta en un terminal, la muestra se puede identificar con capturas de pantalla, fotos o descripciones de la ruta que conduce hasta ellas.
• Documentos: si se evalúa un documento, se suele abarcar todo el documento o partes específicas del mismo, según su complejidad. También puede abarcar varios documentos. Se puede utilizar el título del documento y, posiblemente, el nombre del archivo para especificar la muestra.

Por otra parte, hay varios factores que pueden influir en una evaluación y que se tienen en cuenta en la metodología, entre ellos:

• el tipo de producto digital: por ejemplo, sitio web, aplicación móvil, quiosco, documento;
• el tamaño de un producto digital, su complejidad y las tecnologías que utiliza: por ejemplo, HTML, WAI-ARIA, PDF, EPUB;
• el grado de conocimiento que tienen los evaluadores sobre cómo se diseñó y desarrolló el producto, y
• el propósito principal de la evaluación: por ejemplo, emitir una declaración de accesibilidad, planificar un proceso de rediseño o realizar una investigación.

Pasos de la metodología

Los pasos de la metodología siguen siendo 5 como en la WCAG-EM 1.0.

Estos pasos en español son:

1. Definir el alcance: qué se incluye en la evaluación; el objetivo de la evaluación; y el nivel de conformidad con las WCAG (A, AA, AAA).
2. Explorar el producto: identificar las vistas, funcionalidades, tipos de contenido, diseños, tecnologías de las que depende la accesibilidad u otros elementos que sean relevantes para las personas con discapacidad .
3. Seleccionar la muestra representativa: orientación sobre cómo seleccionar una muestra representativa y una muestra de control cuando no es factible evaluar todas las vistas de un producto digital.
4. Evaluar la muestra: para determinar el cumplimiento con las WCAG.
5. Informe de resultados: recopilar e informar sobre los resultados de la evaluación; formular declaraciones de conformidad; y calcular una puntuación.

Paso 1. Definir el alcance

El primer paso es definir el alcance, habitualmente con la participación de quien encarga la evaluación.

¿Qué hay que hacer en el paso 1?

1. Definir qué producto digital se va a evaluar y qué partes de ese producto se incluyen en la evaluación, de forma que quede claro si cada vista forma parte o no de su alcance.
2. Seleccionar el nivel de conformidad con las WCAG 2 que se utilizará en la evaluación: A, AA o AAA.
3. Definir los navegadores web, las tecnologías de asistencia y otros agentes de usuario con los que las funcionalidades del producto digital deben ser compatibles desde el punto de vista de la accesibilidad. Recordemos que las WCAG 2 no predefinen qué combinaciones de funciones y tecnologías deben ser compatibles.
4. Definir los requisitos adicionales de la evaluación acordados entre la persona evaluadora y quien encarga la evaluación (opcional). Por ejemplo, pruebas con personas con discapacidad, informe detallado con todos los errores y soluciones, etc.

Paso 2. Explorar el producto

Una vez definido el alcance debemos conocer el producto para comprender su uso, su propósito y sus funcionalidades, lo cuál nos permitirá después seleccionar la muestra.

¿Qué hay que hacer en el paso 2?

1. Identificar las "common views" del producto, que también pueden ser estados específicos de las mismas. Se entiende por "view", según el glosario de la metodología, una página web, un documento, un software o una vista (cuadro de diálogo modal o no modal, mensajes de error, párrafos que se expanden, etc.)
2. Identificar las funcionalidades esenciales del producto.
3. Identificar los tipos de contenido, teniendo en cuenta que los que presentan diferentes estilos, diseños, estructuras o funcionalidades también pueden ofrecer un nivel de accesibilidad diferente.
4. Identificar las tecnologías utilizadas de las que depende la accesibilidad (HTML, CSS, JavaScript, SVG, WAI-ARIA, PDF, EPUB, etc.) También se podrían identificar herramienta(s) de autor, sistema(s) de diseño, frameworks, bibliotecas, lenguajes de programación nativos, etc.
5. Identificar otros elementos que sean relevantes para las personas con discapacidad y para la accesibilidad del producto digital que no se hayan identificado en el paso 2.1.

Paso 3. Seleccionar la muestra representativa

En esta fase se selecciona la muestra que se va a evaluar, salvo que el producto pueda evaluarse por completo, como suele ocurrir con una aplicación móvil, un documento o un quiosco.

En productos con un gran número de páginas o pantallas, como un portal web, una buena selección de la muestra nos permite evaluar el nivel de accesibilidad con un grado razonable de confianza.

El tamaño de la muestra depende de las características del producto: tamaño, antigüedad, complejidad, grado de interactividad, forma en la que se genera o implementa el contenido, variedad de contenidos o funcionalidades, etc.

Por otra parte, una selección cuidadosa puede reducir significativamente el tamaño de la muestra.

¿Qué hay que hacer en el paso 3?

1. Seleccionar una muestra de evaluación que represente todas las (1) "common views", (2) las funcionalidades esenciales, (3) los tipos de contenido, (4) las tecnologías utilizadas de las que depende la accesibilidad y (5) los demás elementos relevantes.
2. Seleccionar una muestra aleatoria e incluirla en la evaluación como muestra de control. El tamaño debe ser de un 10% de la muestra estructurada.
3. Incluir en la muestra todas las páginas o pantallas que formen parte de un proceso completo. Recordemos siempre que no se debe evaluar una página de un proceso, por ejemplo un proceso de compra, sin evaluar el resto de páginas de ese proceso.

Paso 4. Evaluar la muestra

En esta fase se evalúa en detalle la muestra seleccionada de acuerdo a los cinco requisitos de conformidad de las WCAG 2. Como se ha indicado, se presupone un conocimiento profundo de las WCAG 2 para llevar a cabo la evaluación.

Recurso recomendado: libro gratuito WCAG 2.2 de forma sencilla" de Olga Revilla y Olga Carreras.

¿Qué hay que hacer en el paso 4?

1. Comprobar que cada elemento de la muestra que no forme parte de un proceso completo, ni corresponda a la última página o pantalla de dicho proceso, cumple los cinco requisitos de conformidad de las WCAG 2 para el nivel de conformidad definido. En esta fase se evalúan todos los componentes de la página o pantalla sin interactuar con ellos. Es decir, sin activar funciones, introducir datos ni iniciar ningún proceso. Las interacciones y los procesos completos se evaluarán en el paso siguiente.
2. Comprobar que todas las interacciones de los procesos completos cumplen los cinco requisitos de conformidad de las WCAG 2 para el nivel de conformidad definido. No es necesario volver a evaluar todo el contenido de cada página o pantalla, sino únicamente los elementos que cambian a lo largo del proceso.
3. Comprobar que la muestra aleatoria no contiene tipos de contenido ni resultados de evaluación que no estén representados en la muestra estructurada.

Paso 5. Informe de resultados

En este paso se prepara el informe. Sin embargo, los pasos de la metodología no son estrictamente lineales, de modo que lo habitual es que el informe se elabore a la vez que se realiza la evaluación.

Por tanto, si bien los resultados de la evaluación se presentan al final del proceso, su documentación se lleva a cabo durante la evaluación.

¿Qué hay que hacer en el paso 5?

1. Documentar los resultados de cada paso. Esta documentación no tiene por qué ser pública, toda o parte de la misma puede ser privada del evaluador.

   El tipo de informe dependerá de lo que se haya acordado con el cliente en la fase 1. Hay que tener en cuenta que la documentación de los resultados de la evaluación, las descripciones claras de los problemas, los pasos para reproducirlos, la gravedad de los hallazgos, las capturas de pantalla y/o los vídeos pueden ayudar a los equipos a resolver los problemas con mayor rapidez.

2. Conservar una copia de los elementos evaluados y registrar las herramientas, los navegadores web, las tecnologías de asistencia, el resto del software y los métodos utilizados durante la evaluación (opcional).
3. Elaborar una declaración de conformidad en la que se describan los resultados de la evaluación de conformidad (opcional).
4. Proporcionar una puntuación global (opcional). Aunque una puntuación puede orientar y mostrar la evolución en el tiempo, también puede resultar engañosa. En España es habitual usar la puntuación que proporciona el informe IRA.

   Hablé de los problemas de este tipo de métricas en Vídeo: Masterclass en abierto "De la teoría a la práctica"

5. Proporcionar informes de los resultados de la evaluación en un formato legible por máquina (opcional), como EARL (Evaluation and Report Language).

Qué no dice la WCAG-EM 2.0 (afirmaciones incorrectas en redes sociales)

En los días posteriores a la publicación de la WCAG-EM 2.0 he leído diversas afirmaciones incorrectas, inexactas o simplificaciones.

Para evitar que se propaguen, en este apartado recopilo las que voy encontrando y explico por qué no son correctas.

Aclaración 1. Afirmación incorrecta

[la WCAG-EM] "describe un proceso para comprobar si un sitio web grande cumple con las WCAG"

Por qué es incorrecta:

La WCAG-EM 2.0 no se limita a sitios web grandes ni sirve únicamente para determinar si un sitio web cumple las WCAG. La metodología puede aplicarse a todo tipo de portales web, sea cual sea su tamaño, y a distintos tipos de productos digitales.

Aclaración 2. Afirmación incorrecta

“WCAG-EM 2.0 acaba de publicarse como borrador”

Por qué es incorrecta:

La WCAG-EM 2.0 no se ha publicado como borrador, sino como una W3C Group Note. Este tipo de publicación indica que el documento ha sido finalizado por el grupo de trabajo para su propósito, que no forma parte del proceso de estandarización del W3C y que, por lo tanto, no existen versiones posteriores como Candidate Recommendation o W3C Recommendation.

Aclaración 3. Afirmación incorrecta

“Selecciona un grupo reducido [de páginas] que incluya: La página de inicio y la página de contacto”

Por qué es incorrecta:

La WCAG-EM 2.0 no exige explícitamente que la muestra incluya la página de inicio ni una página de contacto. No la confundamos con la metodología del Observatorio de Accesibilidad Web que sí obliga a incluir determinadas páginas como estas.

Aclaración 4. Afirmación subjetiva

“el W3C nos ha sorprendido con otra publicación” [la WCAG-EM]

Por qué es subjetiva:

La WCAG-EM 2.0 ha seguido el proceso habitual de elaboración de una W3C Group Note, con un proceso transparente y un borrador público anterior. De hecho, la estabamos esperando.

Aclaración 5. Simplificación

“Selecciona una muestra representativa (El núcleo de WCAG-EM)”

Por qué es una simplificación:

La WCAG-EM 2.0 indica que cuando el producto tiene pocas páginas o pantallas, se auditan todas, por lo que este paso no sería necesario y, por tanto, no sería el nucleo de la WCAG-EM.

Aclaración 6. Afirmación confusa

Hay una frase de la metodología [...]: “Ninguna herramienta ni ninguna revisión experta sustituye probar con personas con discapacidad”.

Por qué es confusa:

Tal y como está expresado, puede parecer que hacer pruebas con personas usuarias es parte de la metodología.

Lo que dice es: La participación de personas con discapacidad (que no sean evaluadores experimentados ni formen parte de un equipo de revisión) puede ayudar a identificar barreras de accesibilidad adicionales que no se descubren fácilmente únicamente mediante una evaluación de expertos. Aunque no es un requisito para utilizar esta metodología, se recomienda firmemente que los evaluadores involucren a personas reales con una amplia gama de capacidades durante el proceso de evaluación".

Referencias

Documentación de interes del W3C:

• WCAG Evaluation Methodology (WCAG-EM) 2.0
• WCAG-EM Overview: WCAG Evaluation Methodology
• WCAG-EM Report Tool

Artículos relacionados:

• AuditTool WCAG 2.2. Herramienta para auditorías de accesibilidad de acuerdo a las WCAG 2.2, 2023
• EN 301 549: Norma Europea de Accesibilidad para Productos y Servicios de Tecnologías de la Información y Comunicación (TIC) V3.2.1 (2021-03). En español UNE-EN 301549:2022
• WCAG 2.2 (recomendación - octubre 2023) Todas las novedades de la nueva versión de las WCAG.
• ISO 30071. Code of practice for creating accessible ICT products and services - Inclusive Design for Organizations - Inclusive Design for Products, 2026
• De los héroes de la accesibilidad al modelo de madurez, 2026
• Qué es un ACR (Accessibility Conformance Report) realizado con una plantilla VPAT® para informar de la conformidad respecto a la EN 301 549, 2024
• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) 1.0, 2012

De los héroes de la accesibilidad al modelo de madurez . Reseña revista ASEPAU número 10

Título: De los héroes de la accesibilidad al modelo de madurez

Autor: Olga Carreras

Idioma: castellano

Descarga: artículo "De los héroes de la accesibilidad al modelo de madurez" en la revista anual número 10 de ASEPAU (PDF, 600 KB)

Fecha de edición: 2026

Título: Revista ASEPAU número 10

Autor: varios

Nº páginas: 155

Idioma: castellano

Descarga: Revista ASEPAU número 10 (PDF, 8.5 MB)

Fecha de edición: 2026

Título: Soy una persona sorda. Entonces, ¿qué artes escénicas puedo disfrutar?

Autor: Henar Pascual Villanueva

Idioma: castellano

Descarga: artículo "Soy una persona sorda. Entonces, ¿qué artes escénicas puedo disfrutar?" en la revista anual número 10 de ASEPAU (PDF, 629 KB)

Fecha de edición: 2026

Ya está disponible el número anual de la revista ASEPAU (Asociación Española de Profesionales de Accesibilidad Universal) con 155 páginas sobre accesibilidad, todo un lujo.

El dossier central de la revista recoge la temática seleccionada este año: las artes escénicas y la cultura inclusiva. Incluye una entrevista a Jana Pacheco, los resultados de la encuesta sobre "¿Cómo vivimos la accesibilidad en las artes escénicas?" y 6 artículos.

Destaco el artículo de Henar Pascual Villanueva "Soy una persona sorda. Entonces, ¿qué artes escénicas puedo disfrutar?" que ha recibido un bien merecido reconocimiento al mejor artículo de este número y que os recomiendo sin duda leer.

En la "La voz de ASEPAU" hemos colaborado 9 socias y socios con artículos muy variados. En mi caso, publico el artículo "De los héroes de la accesibilidad al modelo de madurez" donde hablo del W3C Accessibility Maturity Model. El modelo se publicó en noviembre de 2025 para evaluar si una organización tiene la capacidad de producir productos accesibles a largo plazo y si fomenta la responsabilidad compartida. La madurez de la organización crece cuando los líderes miden lo que importa, asignan recursos y actúan para generar mejoras sostenibles.

Otros temas tratados en los artículos son:

• "Hacia una regulación funcional de los servicios higiénicos accesibles", Ana Folch Méndes y Yolanda Fernández de Dios
• "El lenguaje también diseña", Belén Vaz Luis
• "Ética comunicativa y accesibilidad: en torno a la adaptación colaborativa", Cristina Sola
• "A11YConf: un congreso que deja huella", Melania Pastor
• "¿Son los asistentes virtuales una alternativa válida para cumplir la normativa de accesibilidad web?", Breixo Pastoriza Barcia
• "ARIA es el nuevo amigo de la accesibilidad digital", Jonathan Chacón Barbero
• "Accesibilidad turística: experiencias en Valencia y Jaén", Víctor Blázquez Martínez
• "Instrucciones de uso accesibles para equipos de entrenamiento físico en la tercera edad", José María Fariñas

Consulta de la revista por artículos.

Muchas gracias de forma especial a Belén Vaz Luis, directora de la revista, por su trabajo y su paciencia.

Enlaces relacionados:

• Reseña del artículo "Especializaciones en Accesibilidad Digital. Mapa introductorio de roles, competencias y entregables profesionales"
• Reseña del libro "Inclusive Design for Accessibility: A practical guide to digital accessibility, UX, and inclusive web and app design" (2025)
• ISO 30071. Code of practice for creating accessible ICT products and services - Inclusive Design for Organizations - Inclusive Design for Products

ISO 30071. Code of practice for creating accessible ICT products and services - Inclusive Design for Organizations - Inclusive Design for Products

La ISO 30071 "Code of practice for creating accessible ICT products and services" ayuda a las organizaciones a integrar la accesibilidad, no solo en el ciclo de vida de sus productos y servicios, sino también en sus procesos y políticas.

¿Cómo podemos acercarnos a la ISO 30071 de manera sencilla y práctica?

Mi recomendación es hacerlo a través de los libros de Jonathan Hassell. En la ISO 30071 se distinguen dos partes bastante claras, de la misma manera, Hassell estructura el acercamiento a la ISO a través de dos libros complementarios:

• "Inclusive Design for Organizations", sobre cómo integrar la accesibilidad en todos los procesos de la organización, en su cultura y en su ADN; y
• "Inclusive Design for Products", sobre cómo integrar la accesibilidad en el ciclo de vida de los proyectos.

Tres cosas me gustan especialmente de estos libros:

• La primera, que los libros vienen con materiales de apoyo gratuitos en formato Word y Excel. A lo largo de los libros te invita a utilizar estas herramientas y te guía en ese proceso.
• La segunda, que Hassell lideró la elaboración de la ISO 30071 (y la de su predecesora, la BS 8878). Además, cuenta con una larga experiencia implantándola en distintas empresas, por lo que sabe muy bien de lo que habla.
• La tercera, consecuencia de la anterior, es que aborda la ISO desde una perspectiva práctica y, sobre todo, realista. Con los años, una pierde el idealismo de que se pueda publicar una web con 0 errores, pasando a trabajar en cómo gestionar esta imposibilidad de la forma más adecuada. Esa perspectiva aparece continuamente a lo largo de los libros.

Por último, es relevante saber que la ISO 30071 está íntimamente relacionada con dos documentos del W3C que os recomendaba en la masterclass en abierto "De la teoría a la práctica", en el marco del Máster de Accesibilidad Digital de la Universidad de Barcelona:

• "Accessibility Maturity Model", que viene acompañado de una hoja de cálculo. Es un marco de referencia que describe siete dimensiones clave y cuatro niveles de madurez para evaluar la capacidad de una organización para integrar criterios de accesibilidad, identificar brechas y planificar mejoras continuas. Además, ayuda a medir y documentar políticas, comunicaciones, formación, herramientas y capacidades técnicas en torno a la accesibilidad.
• "Planning and Managing Web Accessibility", una guía que describe una serie de actividades para ayudar a integrar la accesibilidad en todas las fases del proceso de producción web, tanto en proyectos individuales como a nivel organizacional. Organiza estas actividades en "Iniciar", "Planificar", "Implementar" y "Mantener", aunque no se realizan necesariamente de forma secuencial.

Para ampliar información sobre el Accessibility Maturity Model del W3C se puede consultar el artículo: "De los héroes de la accesibilidad al modelo de madurez" (PDF, 600 KB), publicado en la revista ASEPAU en marzo de 2026, donde explico el Accessibility Maturity Model de forma sencilla.

La ISO 30071 fue una de las fuentes de referencia para la elaboración de estos documentos.

Introducción a la ISO 30071

La ISO 30071 "Code of practice for creating accessible ICT products and services" es una norma internacional que permite a las organizaciones integrar la accesibilidad en sus procesos y políticas, así como en el ciclo de desarrollo de sus productos y servicios. Se publicó en 2019 y en 2024 se revisó sin cambios.

La ISO 30071 adapta y amplía la norma británica BS 8878, que os explicaba en el artículo BS 8878:2010 Web Accessibility. Code of Practice de 2015.

La BS 8878 se centraba en productos web, mientras que la ISO 30071 se aplica a cualquier producto digital, no solo a páginas web y aplicaciones móviles, sino también a VR/AR apps, software de cajeros automáticos, juegos, chatbots, etc. La ISO actualiza las recomendaciones de la BS sobre casos de negocio y sobre cómo el diseño inclusivo se relaciona con los enfoques de accesibilidad personalizados. Además, se pasa de los 16 pasos de la BS 8878 a 8 actividades que se pueden integrar en cualquier metodología de desarrollo de software.

La ISO 30071 permite incluir el diseño inclusivo en la organización porque ayuda a:

• Comprender qué beneficios aporta.
• Hacer que forme parte del día a día de la organización de manera eficiente.
• Integrarlo en las políticas internas, como las de contratación y compras.
• Contar con el acompañamiento de expertos.
• Formar a los equipos para que sepan aplicarlo de forma autónoma.
• La adquisición y selección de herramientas y CMS.
• La subcontratación a terceros.
• La evaluación del riesgo y el impacto de la accesibilidad en los presupuestos.
• La gobernanza de la accesibilidad en la evaluación de los productos digitales.

También permite incluir el diseño inclusivo en los procesos de desarrollo porque ayuda a comprender:

• Cómo la audiencia de un producto influye en la manera de abordar la accesibilidad.
• Qué directrices de accesibilidad usar.
• Cómo asegurarse de que las herramientas, como un CMS o las bibliotecas JavaScript, garanticen la accesibilidad.
• Cómo integrar la accesibilidad de manera eficiente en la planificación y las pruebas.
• Cómo priorizar entre las correcciones de accesibilidad cuando no puedes hacerlo todo para todos.
• Cómo informar a las personas sobre cualquier problema de accesibilidad y ofrecerles una forma de comunicación con la organización.

Por último, la ISO 30071 puede ayudar a los profesionales a:

• Entender por qué la inclusión y la accesibilidad digital tienen sentido comercial.
• Integrar estratégicamente la responsabilidad de la accesibilidad en los diferentes roles laborales y en las políticas organizativas.
• Integrar la accesibilidad en el ciclo de vida del desarrollo de software, de modo que no se pase por alto el impacto que las decisiones tienen sobre la accesibilidad.
• Adoptar una forma informada de tomar y documentar estas decisiones para monitorizar el riesgo de incumplir los requisitos de accesibilidad y poder demostrar la conformidad con el estándar.
• Proporcionar orientación para encontrar o investigar requisitos detallados de accesibilidad para una amplia gama de productos digitales.

Acercamiento a la ISO 30071 a través de los libros de Jonathan Hassell

Título: Inclusive Design for Organisations

Autor: Jonathan Hassell

Nº páginas: 212

Idioma: inglés

Formato: papel, kindle, audiolibro

Fecha de edición: 1st 2019; revisado en 2024

Título: Inclusive Design for Products

Autor: Jonathan Hassell

Nº páginas: 374

Idioma: inglés

Formato: papel, kindle, audiolibro

Fecha de edición: 1st 2019; revisado en 2024

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Inclusive Design for Organisations

El libro "Inclusive Design for Organisations" se centra en la gobernanza, en el marco para que la accesibilidad sea una decisión estratégica, integrada en las políticas, responsabilidades y en la cultura de la organización.

Las claves en las que se estructura son:

1. Concienciar y motivar, abordando todos los argumentos posibles (éticos, legales, comerciales, de negocio, de competitividad, de innovación, de marca, económicos, de experiencia de usuario, etc.).
2. Integrar la estrategia como un valor, un objetivo y una competencia en todas las personas de la organización y en sus políticas. No puedes depender de los superhéroes de accesibilidad ni depender siempre de empresas externas. Se debe integrar la accesibilidad en las políticas y en la cultura, en la formación de todas las personas, para que sea eficiente y escalable.
3. Integrar la accesibilidad en los procesos, que deben estar correctamente documentados, además de ser flexibles y reproducibles. En realidad, esta parte es un resumen del libro “Inclusive Design for Products”, que es donde se desarrolla con detalle.
4. Medir el impacto de construir un producto mejor, tanto en la organización como en los objetivos de negocio, para comprobar que merece la pena, que la estrategia tiene los efectos esperados y es sostenible. Aborda cómo medir el ROI en accesibilidad, algo que puede llegar a ser bastante difícil.
5. En continua evolución, puesto que es un proceso que nunca termina, la accesibilidad hay que mantenerla y hay que mejorarla. Además, las WCAG evolucionan, aparecen nuevos productos y herramientas, nuevas oportunidades de innovación, como las que trae la IA, y hay que estar siempre al día.

Todos los capítulos terminan con un apartado "Es tu turno" que te orienta sobre cómo llevarlo a cabo.

Inclusive Design for Products

El libro "Inclusive Design for Products" aborda cómo integrar la accesibilidad en el ciclo de vida de desarrollo de software, desde la planificación, al diseño, el desarrollo o las pruebas, para convertirlo en un proceso de diseño inclusivo y centrado en las personas.

Está dividido en dos partes: el enfoque y las actividades. Si has leído previamente el libro "Inclusive Design for Organisations", la parte "Enfoque" es bastante repetitiva, ya que aborda temas ya tratados en este libro.

La parte más interesante es la de "Actividades", donde se repasan las 8 actividades de la ISO, que son:

1. Especificar la gama más amplia posible de personas usuarias.
2. Especificar sus objetivos y tareas.
3. Especificar sus necesidades de accesibilidad.
4. Especificar requisitos de accesibilidad.
5. Especificar el enfoque de diseño.
6. Garantizar su cumplimiento.
7. Garantizar que se comunica sobre accesibilidad.
8. Garantizar la integración de la accesibilidad en las actualizaciones del sistema.

No se trata solo de cumplir con una norma técnica como las WCAG, porque el propio planteamiento de tu producto depende estrechamente de tu audiencia. Por ejemplo, en la web de un restaurante, no solo importará que la web sea accesible, sino también la accesibilidad del propio restaurante o de la carta, y de la información que das sobre ello en la web.

Hassell habla de casos concretos en los que el estudio de su target le permitió un enfoque de diseño adecuado. Por ejemplo, idear juegos para menores de 8 años con discapacidad visual pensando que usarán un lector de pantalla en UK era abocar el proyecto al fracaso, pudiéndose abordar a tiempo un enfoque diferente y más adecuado.

Por otra parte, no todos los errores son iguales; hay que priorizarlos. De qué sirve que todo el proceso de búsqueda y reserva de un billete de avión sea accesible si, al final, en el último momento, un captcha impide a parte de las personas terminar la compra. El error es solo uno, y solo en una página, pero es un error bloqueante en una tarea fundamental y prioritaria.

La hoja de cálculo que acompaña al libro incluye una matriz de priorización de problemas de accesibilidad, para estimar el beneficio y el coste de cada criterio y sus dependencias. El autor insiste en lo importante que es documentar y argumentar correctamente cada decisión.

Es relevante saber que la ISO 30071 habla de tres niveles de accesibilidad que no se corresponden con los niveles A, AA y AAA de las WCAG, porque son más bien niveles de experiencia:

1. Nivel técnico: en este nivel se incluiría cumplir con una norma técnica como las WCAG.
2. Nivel de eficacia y eficiencia: en este nivel trabajamos una buena experiencia de las personas usuarias reales, el esfuerzo, el tiempo y los errores hasta completar una tarea.
3. Nivel de satisfacción: puede que sea técnicamente accesible, eficiente y eficaz, pero que resulte aburrido o poco respetuoso, en este nivel abordamos la satisfacción de las personas con el producto.

Otro de los temas recurrentes del libro es el de la accesibilidad en la realidad del desarrollo de software.

En el mundo real rara vez se consigue la perfección y, desde luego, nunca en el primer lanzamiento. En el mundo real, se aprende a trabajar de forma pragmática mediante un proceso de mejora continua. Durante este proceso, es muy importante seguir una metodología que permita ir documentando y justificando cada decisión.

También se aborda la importancia de incluir los requisitos de accesibilidad en la documentación y en los contratos de adquisición y subcontratación de productos.

Anexo. Índice de la ISO 30071

• Introduction
• Scope
• Normative references
• Terms and definitions
• Conformity
• Introduction to ICT accessibility within an organization
• Responsibilities and documentation for embedding accessibility of ICT systems within an organization
  • Taking responsibility and setting policy
  • Contents of an organizational ICT accessibility policy
  • Organizational ICT accessibility goals
  • Accessibility considerations in the organization's ICT policies
• Embedding ICT accessibility within the system development life cycle
  • Taking accessibility into account throughout ICT system development
  • Making justifiable decisions on Accessibility
  • Assuring accessibility throughout the system life cycle.
  • Creating accessibility logs and statements for each ICT system
  • Contents of an ICT system accessibility log
  • Contents of an ICT system accessibility statement
• (8) Activities in ICT system development or procurement
  • Performing and documenting accessibility activities
  • Activity 1: Specify widest range of potential users.
  • Activity 2: Specify user goals and tasks
  • Activity 3: Specify user accessibility needs
  • Activity 4: Specify accessibility requirements
  • Activity 5: Specify accessibility design approach
  • Activity 6: Ensure accessibility requirements are met
  • Activity 7: Ensure communication about accessibility
  • Activity 8: Ensure integration of accessibility in system updates
• Annex A (informative) Applying the accessibility goals of ISO/IEC Guide 71:2014
• Annex B (informative) Application of Clause 8
• Annex C (informative) Sources of ICT accessibility guidelines
• Annex D (informative) Accessibility testing methods
• Annex E (informative) Drivers of Accessibility
• Annex F (informative) Checklists for ISO/IEC 30071

Artículos relacionados

• BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web, 2015
• Masterclass en abierto "De la teoría a la práctica", en el marco del Máster de Accesibilidad Digital de la Universidad de Barcelona, 2025.

Reseña del libro "Moviendo la accesibilidad a la izquierda. Shift Left A11y" de Lisandra Armas.

Autora: Lisandra Armas

Idioma: español

Formato: digital (para Kindle)

Fecha de publicación: 2023

Descarga: "Moviendo la accesibilidad a la izquierda. Shift Left A11y. Lisandra Armas" (Amazon)

Podéis consultar más reseñas de libros en: "Libros y reseñas"

En esta ocasión os recomiendo un libro de accesibilidad escrito por Lisandra Armas que se centra en el aspecto metodológico.

En el contexto del desarrollo de software, "Shift Left" significa adelantar la detección de errores y pruebas en el ciclo de vida de un producto. La metodología "Shift Left a11y" está enfocada a integrar la accesibilidad en todas las etapas del ciclo de vida del desarrollo del software, desde la planificación, hasta el mantenimiento, en lugar de dejarla para las etapas finales. De este modo, nos aseguramos de que los productos y servicios digitales sean accesibles, evitando problemas de sobrecostes y retrasos en su lanzamiento.

Para lograr este objetivo, es necesario comprender qué es la accesibilidad y por qué es importante, conocer las normas y regulaciones que la gobiernan y aplicar principios de diseño accesible. También es crucial utilizar herramientas y técnicas específicas para el diseño y desarrollo accesible, así como realizar pruebas exhaustivas de accesibilidad durante todo el proceso de desarrollo.

La autora destaca la importancia de la colaboración entre los desarrolladores y los especialistas en accesibilidad, así como la necesidad de concienciar y formar en accesibilidad digital.

Un libro sencillo de leer y comprender, recomendable para cualquier perfil profesional involucrado en el desarrollo de software.

La estructura del libro es:

• Capítulo 1: Introducción. En este capítulo, se presenta el concepto de Shift Left a11y, sus objetivos y la estructura del libro.
• Capítulo 2: Fundamentos de accesibilidad. Este capítulo aborda los fundamentos de la accesibilidad, incluidos los beneficios, las normas y regulaciones, y cómo la falta de accesibilidad puede afectar la experiencia del usuario.
• Capítulo 3: Shift Left a11y. En este capítulo, se explica la metodología de Shift Left a11y, incluidas sus etapas y cómo aborda la accesibilidad en el ciclo de vida del desarrollo de software.
• Capítulo 4: Diseñando para la accesibilidad. En este capítulo, se presentan los principios del diseño accesible y las herramientas y técnicas para diseñar sistemas informáticos inclusivos.
• Capítulo 5: Desarrollo de software accesible. Este capítulo aborda los principios del desarrollo de software accesible y las técnicas para desarrollar sistemas informáticos que cumplan con las normas de accesibilidad.
• Capítulo 6: Prácticas recomendadas de Shift Left a11y. En este capítulo, se describen las mejores prácticas para implementar Shift Left a11y, incluida la integración de la accesibilidad en el ciclo de vida del desarrollo de software y la colaboración entre desarrolladores y especialistas en accesibilidad.
• Capítulo 7: Implementación de Shift Left a11y. En este capítulo, se presentan los pasos para implementar Shift Left a11y y se discuten los problemas comunes y soluciones.
• Capítulo 8: Medición del éxito de Shift Left a11y. En este capítulo, se abordan los indicadores clave de rendimiento para Shift Left a11y y cómo evaluar el éxito de su implementación.
• Capítulo 9: Futuro de Shift Left a11y. Este capítulo explora las tendencias y avances en accesibilidad, el impacto potencial de Shift Left a11y en la industria de software y las oportunidades para mejorar la accesibilidad mediante esta metodología.
• Capítulo 10: Conclusión. En este capítulo, se realiza una recapitulación de los temas clave del libro y se reflexiona sobre los beneficios de Shift Left a11y, finalizando con un llamado a la acción para implementar esta metodología en el proceso de desarrollo de software.

Artículos sobre accesibilidad y metodología:

• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)
• BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web
• Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA
• "Just Ask: Integrating Accessibility Throughout Design"

Libros relacionados:

• Guía Aplicaciones móviles accesibles, Olga Carreras, 2023
• Accesibilidad web. WCAG 2.1 de forma sencilla, Olga Revilla Muñoz y Olga Carreras Montoto, 2018
• Guía "PDF accesibles con Adobe Acrobat Profesional", Olga Carreras Montoto, 2021
• Guía "Documentos PowerPoint accesibles", Olga Carreras Montoto, 2021

Reseña del libro "Designing with progressive enhancement"

Autores: Todd Parker, Patty Toland, Scott Jehl, Maggie Costello Wachs

Nº páginas: 428

Idioma: inglés

Formato: digital e impreso

Fecha de publicación: 2010

Web: Ficha en Filament Group

Podéis consultar más reseñas de libros en: "Libros y reseñas"

Recomiendo este libro a cualquier desarrollador front-end, de hecho les animaría a todos a que lo leyeran. El libro tiene 10 años, pero sigue plenamente vigente.

Es una guía práctica que enseña a implementar páginas con una gran interactividad, de manera que el mismo código funciona correctamente en cualquier navegador antiguo o moderno, sea cual sea la configuración del usuario, e independientemente de su contexto de acceso o los productos de apoyo que utilice.

Para lograrlo, el libro enseña a desarrollar mediante el enfoque de "progressive enhancemente" (mejora progresiva) que supone dejar atrás malos hábitos y adoptar una perspectiva diferente de diseño y desarrollo.

Hay muchos contextos de acceso en los que nos vamos a beneficiar de una implementación que siga un enfoque de mejora progresiva:

• acceso con un dispositivo o un navegador antiguo, a veces impuesto por la empresa;
• acceso con dispositivos o navegadores actuales pero con capacidades limitadas, como el navegador de Kindle;
• situacionales, por ejemplo, si desactivamos ciertas capacidades por:
  • seguridad: plugins, JS...
  • por conectividad: imágenes, vídeos...;
• si hay un problema en la conexión o en el servidor que provoque que se cargue la página sin ficheros CSS, JS, etc.
• personas con menor experiencia tecnológica, por ejemplo, si se requiere la instalación o actualización manual de plugins (Flash, Silverlight, Sun Java...), que además pueden no ser compatibles con todas las plataformas o navegadores;
• las personas que acceden con productos de apoyo también se van a beneficiar de que las páginas se implementen con el enfoque que voy a resumir.

La metodología es sencilla y la explican con mucho detalle. Uno de los puntos fuertes del libro es que incluye numerosos ejemplos de maquetación y programación, paso a paso, de diferentes widgets.

Partimos de un código HTML correcto y semántico, formado por elementos estáticos estándar y controles de formulario, al que aplicamos una CSS de estilos básicos que trabajan correctamente en todos los navegadores. Esto nos proporciona una página completamente funcional, usable y accesible desde el principio, que funciona en cualquier dispositivo, navegador o contexto de acceso.

Una vez que tenemos la experiencia básica, la página llama al framework EnhancedJS, un JS gratuito que testea las capacidades del navegador. Si pasa todos los test, se cargan los ficheros CSS y JS que añaden una capa de diseño e interacción que mejoran la experiencia para los navegadores que la soportan, haciéndola más rica e interactiva.

Esta capa de mejora se implementa de manera que sea accesible por teclado y accesible con un lector de pantalla. Además, EnhancedJS incluye un enlace en la página para que el usuario pueda intercambiar de forma manual entre la versión básica y la versión avanzada.

Hay una serie de aspectos claves que subyacen a este enfoque, entre los que destacaría:

• la separación entre el contenido, la presentación y el comportamiento;
• el uso de JavaScript no intrusivo;
• la maquetación HTML semántica;
• el uso de WAI-ARIA.

No hay que confundir la "mejora progresiva" con la "degradación elegante" (graceful degradation).

Un ejemplo de degradación elegante sería el uso de la etiqueta <noscript>. En este enfoque se implementa la solución teniendo en cuenta a los usuarios con los dispositivos y navegadores más modernos, y luego se da una solución alternativa a los usuarios con navegadores más antiguos.

Por el contrario, en la mejora progresiva, siempre más recomendable, no sería necesario el uso de una etiqueta <noscript>, porque tendremos una página que trabaja sin JS y sin CSS, que es soportada por todos los navegadores y dispositivos, pero que ofrece una experiencia avanzada y accesible para los dispositivos y navegadores que la soportan.

Mejora progresiva. Ejemplo de un árbol desplegable en la versión mejorada y en la versión básica.

El libro de divide en dos partes:

• En la primera parte repasa la metodología, esta manera diferente de pensar la planificación de los diseños. Tiene capítulos específicos sobre las buenas prácticas para implementar HTML semántico; aplicar CSS de forma adecuada; añadir JavaScript no intrusivo; y usar el framework EnhancedJS, que testea la capacidad del navegador antes de aplicar la capa avanzada de mejoras.
• En la segunda parte hay doce capítulos, cada uno tiene el ejemplo de la implementación de un widget diferente mediante mejora progresiva.

Primera parte. Mejora Progresiva

Capítulo 1. Nuestro enfoque

En este capítulo explican el enfoque de mejora progresiva, tal y como lo he resumido previamente.

Como he indicado, se tienen dos experiencias, pero una única página y un único código. Hay una experiencia básica que funciona universalmente en todos los dispositivos, y una mejorada que se entrega a los navegadores con más funciones.

Las claves son:

• Todos los componentes están basados en HTML semántico y bien estructurado, de tal manera que la funcionalidad para una experiencia básica está disponible sin CSS y sin JS. Sobre esta experiencia básica se construye lo demás.
• Habrá una estricta separación entre contenido, presentación y comportamiento.
• Se testea las capacidades CSS y JS del navegador antes de aplicar las mejoras o mantener la experiencia básica.
• En los navegadores que admiten la experiencia mejorada, se añadirá la capa no intrusiva de estilos y comportamiento, que será accesible por teclado y por los lectores de pantalla.

Introducen el concepto "the x-ray perpective" que desarrollan en el siguiente capítulo y que hace referencia a cómo analizar el diseño de una interfaz compleja, por ejemplo, una aplicación web para organizar fotos.

La "perspectiva de rayos X" toma el diseño de una interfaz web compleja y lo descompone en sus diferentes partes, para encontrar el elemento HTML nativo adecuado para la experiencia básica. Por ejemplo, en un árbol desplegable, sería una lista UL anidada.

Consiste por tanto en pensar de forma creativa cómo deconstruir esos widget e interacciones en elementos HTML nativos estándar que puedan hacer la misma tarea. Mapear el HTML semántico que soportará la experiencia con la funcionalidad básica, y planear cómo se desarrollará la capa avanzada, con CSS y JS, para crear la experiencia mejorada, accesible además en el acceso por teclado y con el lector de pantalla.

Capítulo 2. X-ray perspective

Este capítulo incluye diversos ejemplos de la "perspectiva de rayos X", es decir, de la descomposición de una interfaz con una interacción y un diseño complejo, en componentes básicos y estándares de HTML a partir de los cuales poder construir la experiencia mejorada.

Partimos de la base de que hasta el diseño dinámico más complejo se puede descomponer en contenidos y funcionalidades esenciales expresados en elementos de HTML simples y semánticos, que proporcionarán una experiencia usable y accesible para todos los visitantes. Es un ejercicio muy divertido y creativo que todos deberían probar.

Si queremos tener, por ejemplo, una aplicación web para organizar fotos, pensamos en su versión más avanzada y seguimos un proceso que explican a lo largo del capítulo:

• Definimos la jerarquía y la prioridad del contenido.
• Mapeamos los componentes en sus equivalentes en HTML básico y semántico.
• Construimos el marcado base que proporciona todo el contenido y toda la funcionalidad esencial, con una CSS básica y sin JS.
• Escribimos la capa de mejora visual y funcional con CSS y JS en los navegadores que la soporten.

Una vez hecho esto, pasamos la siguiente checklist de verificaciones:

• ¿La experiencia básica es totalmente funcional y usable solo con HTML?
• ¿El marcado de base codifica toda la información, incluido el diseño y la estructura, que necesita la experiencia mejorada?
• ¿Tanto en la experiencia básica como en la experiencia avanzada, la pagina se lee y trabaja en un orden lógico y promueve el contenido y la funcionalidad más importante?
• ¿Son todas las páginas navegables y todos los elementos de formulario accesibles usando solo el teclado?
• ¿Las paginas tienen sentido al navegar con el lector de pantalla? ¿puede el usuario navegar por la estructura de encabezados?
• ¿Hay un opción clara para todos los usuarios (incluidos dispositivos móviles y lector de pantalla) para cambiar entre la experiencia básica y la experiencia avanzada? Por ejemplo, podemos querer acceder a la versión básica en función de la conexión, las preferencias o si por alguna razón la versión mejorada falla?

Capítulo 3. Escribir código HTML semántico

Este capítulo es un repaso de cómo implementar correctamente HTML de forma semántica. Trata los encabezados, párrafos y listas; el uso de BR y el abuso de DIV y SPAN; las citas, el texto enfatizado y las abreviaturas; las tablas, las imágenes y los elementos interactivos (enlaces y formularios); las zonas semánticas de la página (cabecera, pie, zonas de navegación...); o el contenido del head.

Por último, hace una enumeración básica de los requisitos de accesibilidad de las WCAG relacionados.

Capítulo 4. Aplicar estilos de forma efectiva

Se revisan las buenas prácticas relativas a las técnicas que comúnmente se emplean para aplicar CSS en el enfoque de mejora progresiva:

• la importancia de usar ficheros CSS y en el menor número posible, salvo excepciones muy concretas en que sí puede ser mejor usar el atributo style;
• los inconvencientes de usar @import;
• los diferentes tipos de CSS;
• las recomendaciones para usar convenciones en el nombre de las CSS;
• sobre los comentarios condicionales;
• etc.

Como ya he explicado previamente, habrá una CSS básica con estilos "seguros" (basic.css) y una CSS avanzada (enhacenced.css),  por lo que hay que decidir qué estilos son básicos y cualés avanzados para saber en cuál de estas CSS incluirlos.

Por ejemplo, serán seguros para todos los navegadores los estilos que hacen referencia a la fuente o al estilo del texto; pero los relacionados con la posición, las cajas flotantes, las dimensiones o los márgenes, deberían estar en la CSS avanzada.

Una ventaja añadida de tener una CSS básica es que nos sirve también como CSS de impresión, simplemente habrá que tener cuidado en ocultar los bloques que no se deben imprimir, como la navegación.

También incluyen consideraciones de accesibilidad:

• la definición de la fuente en medidas relativas; 
• el contraste de color; 
• evitar la información que se transmite solo por el color; 
• la necesidad de subrayar los enlaces dentro del texto; 
• definir los colores de fondo bajo las imágenes de fondo; 
• no ocultar el foco;
• el ancho de columna recomendado; u
• ocultar correctamente el contenido.

Por último, repasa diversos trucos para dudas habituales relacionadas con los elementos flotantes o los bugs en IE, como los relacionados con el z-index o el hasLayout.

Capítulo 5. Mejorar la experiencia y la interactividad con scripts

Este capítulo de centra en cómo aplicar JS no intrusivo para extender la funcionalidad de las páginas: 

• Aplicar el código JS al HTML de manera correcta: dónde y cuándo cargar los scripts.
• La inclusión del JS EnhancedJS para testear las capacidades del navegador y cargar los JS y CSS para la experiencia mejorada.
• Cómo construir el marcado mejorado y añadir la interactividad a los controles por JS no intrusivo. Por ejemplo, aprovechando el texto existente en el HTML de base; controlando correctamente la ocultación de contenido con la técnica adecuada para cada caso; etc.
• La importancia de conservar y mejorar la usabilidad y accesibilidad, asegurando el acceso por teclado y el acceso mediante lector de pantalla, para lo cual será imprescindible el correcto uso del atributo tabindex y el estándar WAI-ARIA (artículo relacionado WAI-ARIA).

Capítulo 6. Testear la capacidad del navegador

El framework javascript EnhancedJS testea las capacidad CSS y JS del navegador. Si pasa todos los test y, por tanto, soporta todas las características, se cargan las CSS y JS de la capa mejorada; de lo contrario, se mantiene la experiencia básica que es totalmente funcional.

No solo testea si se soportan ciertos elementos, sino si los soporta correctamente, en especial en aspectos como el modelos de cajas y sus dimensiones o posiciones. Por ejemplo, dada una caja con unas dimensiones (ancho, márgenes, padding, …) compara su ancho final con la suma de sus dimensiones.

Cuando el test pasa:

• Asigna la clase "enhanced" a los elementos HTML. De este modo, por ejemplo, en la CSS avanzada defines el estilo de HMTL.enhanced {} y en la CSS básica el estilo de HTML {}.
• Se incluyen las CSS y JS especificados para la experiencia mejorada.
• Graba el resultado en una cookie para prevenir al framework del resultado del test en cada pagina, así primero busca si existe la cookie.
• Añade un enlace en la página para que el usuario pueda intercambiar de forma manual entre ambas versiones. Tiene opciones de personalización y se puede deshabilitar.

También se puede forzar a pasar o fallar el test; a borrar la cookie y refrescar la pagina; o hacer que el valor de la cookie sea "pasa" o "falla" y refrescar.

Para incluir el framework:

• Se añade la llamada a la función "enhance()" en cada página. Acepta diferente parámetros, como el listado de JS y CSS que quieres añadir en la versión mejorada. Si el navegador no soporta JavaScript o no lo tiene activado, se ignora la función y se carga la versión básica. Los autores indican también un método para que no haya un flash de la pagina sin estilos mientras se carga la versión avanzada.
• La inclusión del fichero "enhance.js" que realiza todos los test, que pueden ser editados y extendidos fácilmente.

Hay otras librerías que podrían ser complementarias a esta, como modernizr.

Segunda parte. Mejora Progresiva en acción

Esta segunda parte incluye los ejemplos sobre cómo construir diferentes widget desde cero, paso a paso, mediante mejora progresiva.

Cada capítulo es un ejemplo diferente, pero todos tienen la misma estructura:

• Se parte del resultado final, la versión mejorada interactiva a la que se quiere llegar, revisándolo desde la perspectiva de rayos x (x-ray perspective).
• Se mapea para descomponer sus piezas funcionales en elementos HTML estándar.
• Se escribe el marcado base.
• Se aplican estilo "seguros" en una CSS básica.
• Se crea la capa de mejora con CSS avanzadas y ficheros JS.
• Se asegura la accesibilidad por teclado y con el lector de pantalla.

Todos los ejemplos están disponibles en la web del libro:

• Acordeón
• Pestañas
  • pestañas que mantienen funcional el botón atrás del navegador
  • pestañas que rotan solas
• Tooltips. Tengo que decir que no estoy de acuerdo con esta solución. En la versión básica, la ayuda de las etiquetas de los campos de texto, que en la versión avanzada se incluye con tooltips, se sustituye por el atributo title, que no es accesible con teclado.
• Árbol
• Gráfica con html5 canvas
• Ventanas de diálogo
• Botones
  • versión con iconos
• Votaciones con estrellas
• Slider
• Menu desplegable (I) y Menu desplegable (II)
• Crear elementos en una lista

Podéis pulsar el enlace "View high-bandwidth version" / "View low-bandwidth version" que hay al final de cada página de ejemplo para ver la versión avanzada o básica.

Para evitar que la página se vea sin estilos mientras se testea el navegador y se carga la versión avanzada, propone:

html.enhanced body {visibility: hidden}

y una vez cargada

html.enhanced body {visibility: visible}

Todos los ejemplos en:

• Designing with Progressive Enhancement Building the Web that Works for Everyone: Code Examples
• Filament Group. Designing with Progressive Enhancement Building the Web that Works for Everyone
• Filamente Group. Our open-source code
• Filament Group. GitHub

Artículos relacionados:

• Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web
• WAI-ARIA. Introducción, referencias, ejemplos, herramientas
• Reseña "Inclusive Design Patterns. Coding Accessibility Into Web Design"
• Reseña de “Pro HTML5 Accessibility
• HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa
• Apps nativas de Android accesibles

WCAG-EM Report Tool. Herramienta de generación de informes de una evaluación de accesibilidad

El objetivo de este artículo es describir la herramienta del W3C WCAG-EM Report Tool que:

• ayuda a aplicar la metodología del W3C/WAI WCAG-EM (Website Accessibility Conformance Evaluation Methodology) de evaluación de accesibilidad de un sitio web de acuerdo a las WCAG 2.0;
• genera el informe de la evaluación de accesibilidad a partir de los datos introducidos.

Índice

• WCAG-EM (Website Accessibility Conformance Evaluation Methodology)
• Visión general de la WCAG-EM Report Tool
• Inclusión de datos para la generación del informe
• Informe generado
• Mejoras que me gustaría proponer
• Herramienta de ayuda para la realización del informe de una consultoría de accesibilidad de acuerdo a las WCAG 2.0 (versión 3.1 - 2016)
• Enlaces de interés

WCAG-EM (Website Accessibility Conformance Evaluation Methodology)

En el artículo Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) os explicaba en detalle la metodología del W3C/WAI para la evaluación de un sitio web de acuerdo a las WCAG 2.0

En ella se describe un método fiable para determinar de forma global el nivel de accesibilidad de un sitio web completo. En el documento se especifican las buenas prácticas y los pasos concretos para definir el alcance de la evaluación, explorar el sitio, seleccionar una muestra representativa cuando no es factible evaluar todo el sitio, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

Los pasos del procedimiento de evaluación, como detallaba en ese artículo, son 5:

Algunos de los pasos pueden solaparse o llevarse a cabo en paralelo, pero es importante que se tengan en cuenta todos ellos para garantizar una evaluación fiable así como documentar claramente cada paso.

Para comprender mejor la herramienta WCAG-EM Report Tool y utilizarla correctamente, os recomiendo que os familiaricéis primero con la metodología WCAG-EM.

Visión general de la WCAG-EM Report Tool

La WCAG-EM Report Tool es una herramienta online y gratuita.

Esta herramienta no realiza ninguna evaluación automática de accesibilidad, sino que nos guía en la aplicación de la metodología WCAG-EM, nos permite introducir todos los datos y nos genera el informe en base a los datos introducidos.

Pantalla de inicio de WCAG-EM Report Tool

En la parte superior tenemos cuatro opciones de menú:

• New Report: crea un nuevo informe.
• Open: abre un informe guardado previamente con la opción "Save", recuperando así todos los datos introducidos en los campos de los diferentes pasos.
• Save: aunque los datos que se van introduciendo en cada paso se guardan, si cierras la ventana del navegador los habrás perdido. Esta opción permite guardarlos localmente en tu equipo (mediante un fichero JSON) que puedes recuperar posteriormente con la opción "Open".
• Key Resources: incluye enlaces a los documentos WCAG 2.0, WCAG-EM y How to Meet WCAG 2.0 Quick Reference.

A continuación tenemos un menú con 7 elementos en forma de pasos. Recorreremos cada uno de ellos para introducir los datos que se nos solicitan y de esta manera obtener el informe en el último paso.

Aunque la navegación está ideada para que sea secuencial, no es restrictiva, en cualquier momento puedes avanzar o retroceder a cualquiera de los pasos, bien a través del menú, bien a través de los botones inferiores "Next step" o "Previous step".

Las siete opciones del menú secuencial son:

• Start: ofrece información general sobre la herramienta y cómo utilizarla.
• 1. Define Scope: se corresponde con el primer paso de la metodología WCAG-EM Step 1: Define the Evaluation Scope. En la metodología este paso se divide en cuatro subpasos y su objetivo es definir el alcance de la evaluación, el nivel de adecuación deseado (A, AA, AAA), el soporte de la accesibilidad (navegadores y productos de apoyo que debe soportar) y los requisitos de evaluación adicionales.
• 2. Explore Website: se corresponde con el segundo paso de la metodología WCAG-EM Step 2: Explore the Target Website. En la metodología se divide en cinco subpasos y el objetivo es que el evaluador explore el sitio para comprender mejor su uso, propósito y funcionalidad. Como resultado, debe identificar las páginas y funcionalidades relevantes, los diferentes tipos de páginas o tecnologías de las que se depende. Esta información servirá después para seleccionar la muestra de páginas a analizar.
• 3. Select Sample: se corresponde con el tercer paso de la metodología WCAG-EM Step 3: Select a Representative Sample. En él se selecciona una muestra de páginas a analizar, en base a los datos recabados en el paso anterior, que nos asegure que los resultados de la evaluación reflejarán la accesibilidad de todo el sitio con suficiente fiabilidad. Se seleccionan también páginas al azar como muestra de control.
• 4. Audit Sample: se corresponde con el cuarto paso de la metodología WCAG-EM Step 4: Audit the Selected Sample. En este paso es donde se realiza la evaluación de la muestra de acuerdo a las WCAG 2.0 y el nivel de adecuación definido (A, AA, AAA). Por cada uno de los criterios de conformidad podremos indicar si la muestra en su conjunto (o cada una de las páginas individualmente) los cumple o no e incluir comentarios.
• 5. Report Findings: se corresponde con el quinto paso de la metodología WCAG-EM Step 5: Report the Evaluation Findings. En la metodología se divide en cinco subpasos. El primero define la información que se debe incluir obligatoriamente en el informe. En los otros cuatro subpasos se indica otra información que se puede ofrecer opcionalmente. La herramienta permite introducir en este paso datos generales (el nombre del evaluador, la fecha de la evaluación, etc.), redactar un resumen ejecutivo o incluir otra información adicional (herramientas de evaluación y navegadores y productos de apoyo utilizados, etc.)
• View Report: aquí podremos ver el informe generado y descargar el HTML y/o la CSS del informe, o grabarlo como fichero JSON.

Inclusión de datos para la generación del informe

Para la generación completa del informe en el último paso ("View Report") debemos rellenar los campos de cada una de las páginas precedentes, que como hemos visto se corresponden con cada uno de los pasos definidos en la metodología WCAG-EM.

Cada página (cada paso) es un formulario que nos solicita datos basados en los subpasos descritos en la metodología.

Pantalla del paso "2. Explore Website" de WCAG-EM Report Tool

Para rellenarlos correctamente hay que estar familiarizado con la metodología, que nos dirá no solo qué información recabar sino también cómo. A modo de ayuda, cada campo tiene un icono que despliega información adicional, pero que en última instancia remite a cada paso y subpaso concreto de la WCAG-EM.

Como he avanzado antes, en el paso 4 podemos ir introduciendo los resultados de nuestra evaluación de la muestra de acuerdo a las WCAG 2.0.

Pantalla del paso "4. Audit Sample" de WCAG-EM Report Tool

En esta página se muestran los criterios de conformidad de las WCAG 2.0 del nivel de conformidad (A, AA, AAA) que has indicado que quieres evaluar.

Por cada uno puedes indicar si la muestra completa cumple o no cumple este criterio (también puedes indicar: no chequeada, no presente, no sé), o bien indicarlo individualmente por cada una de las páginas de la muestra (para ello debes seleccionar en el menú izquierdo qué páginas de la muestra quieres evaluar individualmente).

También puedes añadir observaciones, por ejemplo podrías querer añadir la descripción de los errores, posibles soluciones, técnicas que se aplican, aunque para ello solo tenemos un textarea (por criterio y página) y no podemos adjuntar imágenes.

Un criterio de conformidad lo has podido evaluar manualmente o con alguna herramienta, pero la WCAG-EM Report Tool no hace ninguna evaluación automática de los mismos, solo sirve para recoger los resultados.

La metodología indica (subpaso 4a) que si no hay contenido relacionado con el criterio de conformidad (por ejemplo, no hay vídeo), entonces el criterio se indicará como satisfecho ("passed"). Pero que opcionalmente se puede optar por indicar que estos criterios son "no presente" ("not present").

Al final, lo importante es ser consistente en la manera de reflejar los resultados.

También indica que el contenido de las páginas o estados de páginas que tienen versiones alternativas se evalúan juntas (la página y la versión alternativa) como una unidad.

Informe generado

El informe generado, como he indicado, se encuentra en el último paso "View Report". Está en inglés pero podemos descargarlo para personalizarlo y traducirlo.

En primer lugar incluye los datos generales y el resumen ejecutivo.

Pantalla del paso "View Report" de WCAG-EM Report Tool. Datos generales y resumen ejecutivo

A continuación incluye una tabla resumen del número de criterios cumplidos, no cumplidos o no presentes, por cada uno de los cuatro principios de accesibilidad (sería muy útil que se desglosará también por nivel A, AA, AAA). Después se inserta el detalle de la evaluación, es decir, los datos introducidos en el paso 4.

Pantalla del paso "View Report" de WCAG-EM Report Tool. Resumen de los resultados y resultados detallados.

Al final del informe se incluye la relación de páginas auditadas y enlaces a las WCAG y la metodología WCAG-EM.

Mejoras que me gustaría proponer

Ayuda asociada a cada criterio de conformidad (paso 4)

Se entiende que la herramienta será utilizada por personas expertas en las WCAG 2.0, por eso no se incluye información adicional sobre cada criterio, solo su nombre. Sin embargo sería interesante que cada criterio tuviera, al igual que los campos en los pasos anteriores, un icono de ayuda que mostrara la descripción completa del criterio, el enlace al mismo y las recomendaciones (por ejemplo como en Interactive WCAG 2.0)

Mejorar la inclusión de observaciones asociadas a cada criterio

Para un análisis preliminar o para presentar un resumen ejecutivo, puede servir un informe sencillo como el que genera la herramienta, pero cuando el informe es para el equipo de desarrollo tienes que detallar qué significa cada criterio, cómo lo evalúas, poner ejemplos concretos de los errores con pantallazos y describir las soluciones. Como hemos visto, solo contamos con un textarea, que en este caso se quedaría escaso.

Según el tipo de informe que se quiera generar podría mejorarse la inclusión de observaciones, por ejemplo seleccionando que quieres incluir un problema, una solución, poder añadir un pantallazo, etc.

Más información en la tabla resumen del informe

La tabla resumen es de la muestra en su conjunto, no se puede desglosar por niveles, páginas o criterios de conformidad.

Sería muy útil que generara tablas resumen, estadísticas y gráficas de cumplimiento e incumplimiento más detalladas para incluir en el informe y en su presentación.

Ayuda en la comparación con la muestra de control

En el paso 4c de la metodología (y en el texto introductorio del paso 4 de la herramienta) se indica que se deben comparar los resultados de la evaluación de las páginas de la muestra que seleccionaste, con los resultados de la evaluación de las páginas que escogiste al azar como muestra de control.

Sería muy interesante que la herramienta diferenciara las páginas de la muestra de control y que en base a los datos introducidos pudiera emitir advertencias (por ejemplo si para un criterio de conformidad la única página que presenta errores es una de las páginas de control)

Herramienta de ayuda para la realización del informe de una consultoría de accesibilidad de acuerdo a las WCAG 2.0 (versión 3.1 - 2016)

En 2012 compartí la primera versión de una herramienta interna que utilizo para recoger los datos de una evaluación de accesibilidad, actualmente podéis descargaros la versión 3.1 que publique el 05/07/2016.

Ver Herramienta de ayuda para la realización del informe de una consultoría de accesibilidad de acuerdo a las WCAG 2.0 (versión 3.1).

La excel no genera el informe, pues para eso tengo diferentes plantillas según el tipo de informe, pero sí diferentes tablas resumen, estadísticas y gráficas de cumplimiento e incumplimiento (por nivel, principio, criterio de conformidad, página de la muestra o muestra completa) que son muy útiles para:

• elaborar el informe ejecutivo y su presentación;
• comparar en el tiempo los resultados de distintas evaluaciones de un mismo sitio;
• comparar los resultados de la evaluación de un sitio con la evaluación de otros sitios, por ejemplo de la competencia;
• identificar con rapidez cuáles son los criterios de conformidad y las páginas que presentan más problemas.

Por tanto esta herramienta (una excel cuya descarga es directa y gratuita) es un complemento muy útil para mejorar el informe del WCAG-EM Report Tool.

Hoja "6. Resultados por nivel y principio" de la excel

Enlaces de interés

• WCAG-EM Report Tool. Website Accessibility Evaluation Report Generator
• Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0
• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM), Olga Carreras
• Herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0 (version 3.1- 2016), Olga Carreras
• Interactive WCAG 2.0

Artículos relacionados

• BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web
• Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web, 2013
• Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI, 2009
• Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA, 2011
• Introducción a las WCAG 2.0, última actualización 2013
• Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España, última actualización 2015