BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web

Este artículo describe la norma BS 8878:2010 Web Accessibility. Code of Practice del Reino Unido que estandariza un proceso:

para la creación e inclusión de una política de accesibilidad web dentro de la estrategia de cualquier organización;
para la consideración de la accesibilidad web a lo largo de todo el ciclo de vida de cualquier producto web.

Índice

Qué es la norma BS 8878:2010 Web Accessibility. Code of Practice
WCAG 2.0 y BS 8878:2010
Antecedentes, autores y publicación
Visión general de la BS 8878:2010. ¿Qué nos enseña?
El proceso en detalle

Proceso para crear productos web accesibles (capítulo 6)
Asegurar la accesibilidad a lo largo del ciclo de vida de un producto web (capítulo 8)

Conclusiones
Bibliografía

Qué es la norma BS 8878:2010 Web Accessibility. Code of Practice

La norma BS 8878:2010 Web Accessibility. Code of Practice es un estándar nacional del Reino Unido creado por el BSI (British Standards Institution).

La norma define un proceso para la creación e inclusión de una política de accesibilidad dentro de la estrategia de cualquier organización, así como para la consideración de la accesibilidad a lo largo de todo el ciclo de vida de sus productos web.

Está escrita en un lenguaje no técnico y se dirige a las personas con responsabilidades en materia de estrategia o desarrollo dentro de una organización. El objetivo es que puedan seguir un estándar que les indique, de manera clara y sencilla, qué hacer y cómo conseguir que sus productos web sean más accesibles y fáciles de usar.

“Producto web”, dentro de la norma, hace referencia a cualquier sitio, servicio o aplicación web que se entrega vía IP a través de un navegador en cualquier tipo de dispositivo.

WCAG 2.0 y BS 8878:2010

La BS 8878:2010 no es, ni pretende ser, una alternativa a las WCAG 2.0 (o a otros estándares a los que hace referencia la norma: ISO 9241:171, UAAG, ATAG, WAI-ARIA). Al contrario, los considera indispensables para su aplicación.

La BS 8878:2010 no establece especificaciones técnicas como lo hacen las WCAG 2.0, se centra en el proceso. Establece un estándar para la calidad del proceso de creación de productos web accesibles.

La BS 8878:2010 estandariza el proceso necesario para integrar la consideración de la accesibilidad web dentro de una organización a través de:

una política general de accesibilidad web de la organización
una política de accesibilidad web concreta para cada uno de sus productos web

El proceso tiene que asegurar que los equipos están tomando decisiones informadas y justificadas sobre la accesibilidad en cada etapa del desarrollo del producto, integrando este tipo de comportamiento dentro de su negocio como una práctica habitual.

Una declaración de que el producto es conforme a la norma BS 8878:2010 NO es una declaración de que es conforme a las WCAG 2.0

Una declaración de que el producto es conforme a la norma BS 8878:2010 es una declaración de que durante todo el proceso de desarrollo del producto se ha tenido en cuenta la accesibilidad, se han tomado las mejores decisiones y que estas son siempre justificables.

Para incluir en un sitio la declaración de conformidad de acuerdo a la BS 8878:2010, la organización debe:

atender todas las recomendaciones de la norma;
ser capaz de justificar cualquier desviación respecto a dichas recomendaciones;
documentar sus procesos de decisión en la política de accesibilidad del producto que acredite que se han seguido las recomendaciones de la norma.

La declaración puede estar basada en una autoevaluación o en una evaluación llevada a cabo por terceros.

Antecedentes, autores y publicación

La BS 8878:2010 se desarrolló a partir de la especificación existente, la PAS 78:2006 Guide to good practice in commissioning accessible websites.

La PAS 78:2006 fue encargada al BSI por el DRC (Disability Rights Commission), comisión establecida por el Gobierno de Reino Unido en 1999. Su objetivo era ser una guía para el proceso de creación y mantenimiento de un sitio web, que ayudara a orientar a las personas no técnicas sobre cómo utilizar los estándares para garantizar que el sitio resultante fuera accesible.

Sin embargo se quedó obsoleta por los cambios que han sufrido no solo los propios productos web si no también la manera de consumirlos (ver [HASSELL, 2010]).

La BS 8878:2010 fue elaborada por la comisión IST/45 Web Accessibility del BSI, cuyo presidente fue Jonathan Hassell, por aquel entonces director de usabilidad y accesibilidad de la BBC.

Participaron expertos en accesibilidad e inclusión social, personas con discapacidad, representantes de diversas organizaciones de personas con discapacidad u organizaciones como Vodafone, IBM, Opera, BBC, British Computer Society, University of Southampton, entre otras.

El primer borrador se presentó en 2008 para una consulta pública generalizada y el segundo borrador en mayo de 2010. Fue revisada por 328 expertos mundiales de accesibilidad para asegurarse de que armonizaba con las normas internacionales (W3C, Adobe, etc.) y nacionales de otros países.

Finalmente se lanzó oficialmente en diciembre de 2010, el mismo año que la ley de igualdad de Reino Unido, la Equality Act 2010 (referenciada en la norma, especialmente en el Anexo C. Discapacidad y la ley) y que establece que los productos web, no solo del sector público, deben ser accesibles para todos.

Aunque la Equality Act no obliga a cumplir con la BS 8878:2010, es sin embargo reconocida por el UK Government’s e-Accessibility Action Plan del Gobierno Reino Unido como una herramienta clave para el desarrollo de servicios online accesibles.

Visión general de la BS 8878:2010. ¿Qué nos enseña?

La BS8878:2010 es un documento de 90 páginas, organizado en 8 capítulos y 15 anexos, que nos va enseñar:

Cómo crear una política de accesibilidad web de la organización

La política general de accesibilidad web de la organización estará integrada en la estrategia de la organización. Se refleja en un documento donde se explica el compromiso de la organización con la accesibilidad y se resume su planteamiento.

En el capítulo 4.3 se describe cómo elaborarla, y en el Anexo E1 se incluye un ejemplo de política de accesibilidad de una organización.

La norma explica además cómo designar un responsable (un rol o departamento con autoridad para cumplir con esta responsabilidad y que tiene una visión general de todos los productos web) que garantice que todos los productos web creados o adquiridos cumplen esta política.

Sus responsabilidades serán:

elaborar la política de accesibilidad de la organización;
delegar responsabilidades a través de diferentes departamentos y asegurarse de que las personas en las que delega son las adecuadas (se detalla la asignación de responsabilidades en el Anexo F);
asumir la responsabilidad de asegurar que la organización implementa y mantiene la política de accesibilidad.

Cómo integrar las consideraciones de accesibilidad a través del proceso de desarrollo

La norma ayuda:

a identificar las decisiones que impactan en la accesibilidad a lo largo de todo el ciclo de vida del producto;
a tomar estas decisiones de la mejor manera posible, considerando todas las opciones e implicaciones.

Cómo asegurar la accesibilidad web a lo largo del ciclo de vida de un producto web

Integrada dentro una metodología de Diseño Centrado en el Usuario, utilizando diversas técnicas de investigación y pruebas en los puntos clave del proceso de producción, y considerando siempre el impacto en la accesibilidad en cada uno de los pasos que se dan.

El mejor uso de las pautas de accesibilidad existentes en el proceso de desarrollo de productos web accesibles

El capítulo 7 (“El uso de las pautas de accesibilidad para dirigir la producción de productos web accesibles”) trata las pautas de accesibilidad del W3C (WCAG, UAAG, ATAG, WAI-ARIA) u otras pautas de accesibilidad como la Section 508 de EEUU, y ofrece recursos y enlaces de interés (selección de librerías Javascript, técnicas para Adobe Flex o Microsoft Silverlight).

Aborda también la adaptabilidad individualizada en un enfoque personalizado de la accesibilidad web, recomendando la aplicación de AccessForAll 3.0 (al que dedica también buena parte del Anexo K)

Trata por último, como recomendaciones adicionales a las WCAG 2.0, las pautas de accesibilidad específicas a tener en cuenta en dispositivos móviles e ITPV, así como las pautas de accesibilidad específicas para las personas mayores.

Cómo garantizar la accesibilidad en los productos que se adquieren o se contratan a terceros

El capítulo 6.11 trata sobre cómo garantizar que los productos que se adquieren o se contratan a terceros se seleccionan o especifican de manera que se asegure su accesibilidad.

En el Anexo L se incluye una batería de preguntas que se recomienda hacer antes de adquirir o contratar productos a terceros.

Cómo documentar y justificar todas las decisiones en la política de accesibilidad del producto web

Todas las decisiones que impactan en la accesibilidad del producto se documentan y justifican en su política de accesibilidad web.

La política de accesibilidad de un producto web es un documento específico para ese producto web en particular, que se crea tan pronto como el producto es concebido y se va completando a medida que pasamos por las diferentes etapas de desarrollo.

Es por tanto un documento vivo que evoluciona a lo largo de todo el ciclo de vida del producto.

El proceso para crear productos web accesibles ocupa el capítulo 6. A lo largo de él se va detallando, en cada paso, toda la información que se debe incluir en la política de accesibilidad del producto web.

Este capítulo 6 me parece de especial relevancia y luego lo trataré más detenidamente, indicando en cada paso a qué preguntas debe responder la política de accesibilidad del producto, preguntas que se corresponden con decisiones que siempre se han de justificar.

El capítulo 5 “Cómo tomar decisiones justificables sobre las opciones de accesibilidad en cada paso” está dedicado en exclusiva a la justificación de las decisiones.

En el capítulo 4.5 se resume la información que debe incluir la política de accesibilidad del producto web y en el Anexo E2 se proporciona un ejemplo de política de accesibilidad de un producto web.

Cómo comunicar las decisiones de accesibilidad en una declaración de accesibilidad

Las decisiones de accesibilidad del producto web se comunican a los usuarios tras el lanzamiento mediante la publicación en la web del producto de una declaración de accesibilidad.

La elaboración de la declaración de accesibilidad se trata en los capítulos 4.4 y 4.6 y se incluye un ejemplo en el Anexo E3.

La declaración de accesibilidad resume la política del producto de manera clara, sencilla y sin jerga (de manera que todos los usuarios puedan comprenderla) y muestra cómo se ha tenido en cuenta la accesibilidad durante el desarrollo del producto web.

Puede incluir referencias a las pautas y especificaciones del W3C, pero si se afirma que el sitio es conforme a las WCAG 2.0 debe ser de acuerdo a los requisitos que estas establecen para incluir declaraciones de conformidad de acuerdo a las WCAG 2.0

La declaración de accesibilidad:

indica cómo utilizar o personalizar el producto web para una experiencia más accesible de acuerdo a sus necesidades individuales (por ejemplo mediante opciones de personalización del navegador, mediante herramientas de preferencias del sitio, mediante versiones accesibles, etc.);
señala las limitaciones de accesibilidad del producto web (así como cualquier plan de mejora previsto o las alternativas que se ofrecen);
permite acceder a la política completa e incluye formas de contacto para que los usuarios remitan sus comentarios, sugerencias o quejas;
se ha de mantenerse actualizada y se debe indicar la fecha de la última actualización.

Una declaración que sigue el ejemplo del estándar es la de la web Access8878: Accessibility Statement.

Cómo mantener la accesibilidad tras el lanzamiento y cómo gestionar las comunicaciones de los usuarios sobre la accesibilidad del producto web

En el capítulo 6.16 se trata el proceso de revisión y evaluación continua del producto. También trata la necesidad de asegurarse de que todos los comentarios (sugerencias, quejas, etc.) sobre el producto web vienen a través de los mecanismos de contacto indicados en su declaración de accesibilidad y que se revisan y responden de manera adecuada.

En el Anexo M se incluye una guía para tratar las quejas de accesibilidad (cómo extraer información relevante, cómo responder, etc.)

El proceso en detalle

Hay dos capítulos que me interesan especialmente y en los que me centraré ahora. El capítulo 6 “Proceso para crear productos web accesibles” y el capítulo 8 “Asegurar la accesibilidad a lo largo del ciclo de vida de un producto web”.

Proceso para crear productos web accesibles (capítulo 6)

El proceso es muy similar al del Diseño Centrado en el Usuario, como indica la norma:

This process is very similar to the user-centred or human-centred design process detailed in ISO 9241-210 that many organizations may already follow. Where the limited resources of the organization or the small size of the web product make the costs of following every step of the process prohibitive, organizations are advised to consider choosing the cheaper or quicker options at each step, rather than omitting steps.

La accesibilidad se va a tener en cuenta en todo el ciclo de vida del producto web, pues cada decisión a lo largo del mismo afectará a si el producto resultante incluye o excluye a las personas con discapacidad o a las personas mayores.

El capítulo se articula en 16 pasos. Resumo a continuación sobre qué tratan y a qué preguntas debe responder la política de accesibilidad del producto en cada uno de ellos.

Investigación, diseño conceptual y análisis de requisitos (pasos 1-6)

Paso 1: Definir el propósito del producto web.

¿Cuál es la finalidad del producto y qué esperan lograr los usuarios al usarlo?

Paso 2: Definir el público objetivo del producto web.

¿Es un producto web interno (como una intranet o extranet a la que se accede con un login obligatorio) o público? ¿Se dirige a un grupo específico de personas?

Ante una situación en la que no es posible satisfacer las necesidades de todos los públicos potenciales porque divergen o se enfrentan, tendrán prioridad las del público objetivo.

Definir una serie de audiencias no significa que el resto de usuarios estén excluidos, sino que los requisitos, actividades de diseño y pruebas se centran en estos grupos de usuarios como los usuarios más probables del producto.

Paso 3: Análisis de las necesidades del público objetivo

¿Cuáles son las necesidades generales de tu público objetivo? ¿Tienen necesidades específicas en relación con tu producto web? ¿Cómo estás investigando sus necesidades?

Las necesidades generales de las personas con discapacidad y personas mayores de tu público objetivo deben analizarse junto a las necesidades generales de las personas sin discapacidad de tu público objetivo.

En este capítulo se habla de la investigación etnográfica en contexto, o de la técnica Personas. La investigación permite definir y tomar decisiones sobre los requisitos específicos de accesibilidad en la especificación general de los requisitos del producto.

En el Anexo H se aborda cómo las personas con discapacidad y las personas mayores utilizan los productos web, repasando diferentes discapacidades, necesidades, escenarios o tecnologías, y se recomiendan en cada caso distintos recursos.

Paso 4: Plataforma y tecnología. Preferencias y restricciones del público objetivo.

¿El público objetivo tiene restricciones respecto a la tecnología, quizás por su coste, confianza o compatibilidad (por ejemplo si las personas mayores de nuestro público objetivo están utilizando navegadores antiguos; o si hay usuarios que están utilizando un lector de pantalla en el trabajo y otro diferente en casa; o si los empleados tienen restricciones para usar el dispositivo móvil o un sistema operativo o navegador en el trabajo, etc.)? ¿Impactará la tecnología o plataforma elegida?

Esta información será útil cuando se tomen decisiones sobre la inclusión de herramientas de personalización (paso 8) o sobre los navegadores y productos de apoyo que se soportarán (paso 10)

Paso 5: Definir la relación que el producto tendrá con su público objetivo

¿El producto web permitirá opciones personalizadas (a través del login o el uso de cookies) o apoyará a grupos más generales de usuarios (un grupo será aquel cuyos usuarios tienen un conjunto común de necesidades)?

Influirá en las decisiones sobre el enfoque de accesibilidad que se tomarán en el paso 8.

Paso 6: Definir los objetivos de los usuarios y las tareas que el producto web ofrecerá

¿Cuáles son los objetivos que los usuarios quieren lograr y cuáles las tareas que van a realizar para alcanzarlos? ¿Cómo se priorizan los objetivos y cuáles son los criterios de éxito?

Separamos los objetivos primarios de los secundarios para priorizar el trabajo, investigándolos para nuestros diferentes targets.

Las tareas serán probadas durante los test con usuarios.

Se definen los criterios de éxito para evaluar luego el producto y ver si permite a su público objetivo alcanzar sus objetivos. En el anexo J (Medir el éxito del usuario) se incluyen ejemplos de criterios de éxito.

Toma de decisiones estratégicas basadas en la investigación (pasos 7-10)

Paso 7: Considerar el grado de experiencia de usuario que el producto web tendrá como objetivo ofrecer.

¿El producto web ofrecerá una experiencia “técnicamente accesible”, “usable y accesible”, “satisfactoria y accesible”?

La organización debe definir el grado de experiencia de usuario que tendrá como objetivo poner en práctica para cada grupo de usuarios y objetivo de usuario, y documentar las razones para la elección de ese grado en la política de accesibilidad del producto.

Se consideran tres posibles grados de experiencia de usuario:

“Técnicamente accesible”: ¿es técnicamente posible que los usuarios accedan a la información o realicen los pasos necesarios para realizar la tarea? La accesibilidad técnica no garantiza a las personas con discapacidad una experiencia equivalente a la de las personas sin discapacidad, por tanto esta decisión debe ser justificable y ser recogida en la política como una limitación de accesibilidad.
“Usable y accesible”: ¿los usuarios son además capaces de completar las tareas eficaz y eficientemente?
“Satisfactoria/divertida y accesible”: ¿los usuarios están satisfechos con la experiencia? ¿es divertida (si se supone que debe serlo)?

Los términos "eficaz", "eficiente", "satisfactorio" se toman de la ISO 9241. Se ha separado la satisfacción por ser más difícil de alcanzar que la eficacia y eficiencia.

En el Anexo I3 (Ejemplos de propósito, audiencias, objetivos de usuario, tareas de usuario y grados de experiencia de usuario para estas tareas. Grados comunes de experiencia de usuario para productos web 2.0) se pueden consultar ejemplos de grados de experiencia de usuario para diferentes objetivos de usuario de diferentes tipos de productos web.

Paso 8: Considerar el enfoque de accesibilidad: diseño inclusivo o herramientas de personalización de usuario

¿El producto tendrá un enfoque de diseño inclusivo (BS 7000-6 Design management systems. Managing inclusive design. Guide), un enfoque de personalización de usuario o una combinación de ambos?

El diseño inclusivo tiene como objetivo garantizar la accesibilidad siguiendo las pautas y técnicas reconocidas para asegurar la accesibilidad (como la WCAG) para una amplia gama de audiencias sin necesidad de una adaptación especial (que no sea un producto de apoyo).

Un enfoque de personalización (que también se trata en el Anexo K) permite al usuario especificar sus preferencias de accesibilidad y luego adaptar los productos automáticamente a estas y/o proporcionarle una versión alternativa. Pueden ser herramientas para redimensionar el texto o leer la página; versiones alternativas en las plataformas de eLearning, si diferentes usuarios tienen mejor apoyo en su aprendizaje a través de diferentes estilos y modalidad de aprendizaje, etc.

El enfoque personalizado complementa al diseño inclusivo, no lo sustituye, a menos que la organización pueda racionalizar las decisiones adoptadas.

La conveniencia de opciones de personalización surge de la investigación previa, por ejemplo si se descubre que un número razonable de usuarios pueden no poder o no saber utilizar las opciones de su navegador o sistema operativo, o no pueden usar productos de apoyo, etc.

Paso 9: Dispositivos soportados

¿El producto web estará optimizado para un dispositivo en particular, o formará parte de un conjunto de versiones específicas según el dispositivo?

Trata las diferencias entre el acceso según el dispositivo (ordenador, móvil o tablet, consolas, IPTV), los diferentes grados de apoyo a la accesibilidad para los usuarios que acceden desde diferentes dispositivos o el concepto “accessibility supported” de las WCAG 2.0.

Por ejemplo hay que tener en cuenta si el dispositivo soportado permite la instalación de productos de apoyo, si expone la información a los productos de apoyo o si sus navegadores incluyen opciones de configuración de accesibilidad habituales como cambiar el tamaño de fuente.

Paso 10: Navegadores, sistemas operativos y productos de apoyo soportados

¿Qué navegadores, sistemas operativos y productos de apoyo (lectores de pantalla, magnificadores de pantalla, sistemas de reconocimiento de voz, etc.) y versiones de los mismos se soportarán?

En la decisión influyen los que son soportados por los dispositivos indicados en el paso 9, si la organización tiene algún control sobre los que usara su público (por ejemplo en una intranet) o las restricciones o preferencias estudiadas en el paso 4.

Si se ha optado por un enfoque personalizado, se debe definir el rango exacto de preferencias individuales que se apoyarán con herramientas de personalización o alternativas de accesibilidad.

Contratación (paso 11)

Paso 11: Decidir si se crea el producto en la empresa o se adquiere o contrata a terceros

¿El producto se creará en la empresa o se adquirirá o contratará a terceros? ¿Cómo nos aseguraremos de que las soluciones de terceros son accesibles?

Cuando la organización contrata la creación del producto web a un proveedor externo debe cerciorarse de que el proveedor es capaz de entregar los requisitos de accesibilidad y los objetivos especificados en la política de accesibilidad del producto.

En el Anexo L se incluyen todas las preguntas que se recomiendan hacer para adquirir o contratar productos a terceros y asegurar su accesibilidad.

Producción del producto (paso 12-13)

Paso 12: Definir las tecnologías web que se utilizarán en el producto web

¿Las tecnologías web usadas para construir el producto web soportan la accesibilidad? ¿Permiten crear productos accesibles? ¿Exponen la información a los productos de apoyo?

Trata la elección de las tecnologías web utilizadas en la creación del producto web y las versiones alternativas que podrían necesitarse si se utilizan tecnologías no accesibles.

También se dan pautas a seguir cuando el producto web va a ser creado por la selección y la integración de una combinación de herramientas de autor, software de terceros, componentes o servicios web, en cuyo caso la organización tendrá menos control sobre las tecnologías utilizadas.

Paso 13: Uso de pautas web para dirigir la producción web accesible

¿Cuáles son los mejores estándares de accesibilidad disponibles para las plataformas y tecnologías elegidas? ¿Cómo se ajustará el producto web a ellas?

Ya hemos visto que no solo se tratan las WCAG 2.0.

Cuando hay niveles de conformidad (A, AA, AAA) se debe elegir cuál se va a proporcionar para cada grupo de usuarios y objetivo de usuario. Este nivel tiene un impacto en el precio y los plazos. La organización debe ser capaz de justificar su decisión, basada en el equilibrio entre el coste y los beneficios para los usuarios del producto.

Las directrices de accesibilidad y sus especificaciones técnicas no solo afectan a los desarrolladores, tienen impacto en los diferentes miembros del equipo: diseñadores visuales, diseñadores de interacción o autores y editores de contenido.

Evaluación del producto (paso 14)

Paso 14: Asegurar la accesibilidad a lo largo del desarrollo

¿Cuál es el plan de pruebas de accesibilidad? ¿Cómo se evaluará la accesibilidad durante todo el proceso de desarrollo del producto web (diseño, prototipos, construcción del producto)?

Si se contrata a terceros debe requerírseles el plan de pruebas y exigírseles que acrediten que lo han seguido a lo largo del todo proceso de desarrollo del producto.

Si se externalizan las pruebas de accesibilidad, el Anexo L4 incluye preguntas útiles para la selección de los proveedores que realizarán dichas pruebas.

También trata cómo afrontar situaciones en las cuales la organización tiene que sacar el producto cuando aún no cumple con el grado de experiencia al que aspiraba. Cómo tomar las decisiones y disminuir el riesgo y las limitaciones de accesibilidad.

Lanzamiento del producto (paso 15)

Paso 15: Comunicar las decisiones de accesibilidad del producto web en el lanzamiento

¿Qué dirá la declaración de accesibilidad? ¿Cómo estará disponible a través del producto web?

Ya he comentado que se han de comunicar todas las decisiones a los usuarios a través de la declaración de accesibilidad, que debe ser fácil de encontrar, accesible y comprensible.

Se recomienda que las organizaciones enlacen esta declaración en todas las páginas del producto web (normalmente con un enlace “Accesibilidad” en la cabecera o el pie).

Mantenimiento post-lanzamiento (paso 16)

Paso 16: Plan para asegurar la accesibilidad en todas las actualizaciones posteriores al lanzamiento

¿Con qué frecuencia se actualizará el producto? ¿Cuál es el proceso para revisar y evaluar continuamente el producto web?

Trata temas tales como la manera de afrontar las limitaciones de accesibilidad ya identificadas, el desarrollo e implementación de un programa regular de pruebas de accesibilidad post-lanzamiento, o la revisión periódica de la accesibilidad del producto web a la luz de los nuevos avances de la tecnología o nuevas versiones.

También trata los mecanismos de contacto de los usuarios y la respuesta adecuada a los comentarios, quejas o sugerencias de accesibilidad, tema que se aborda de forma ampliada en el Anexo M.

Proceso iterativo

Este es además un proceso iterativo (especialmente en los pasos 13-14) en el cual se va eliminando progresivamente la incertidumbre. La iteración implica que las especificaciones y los prototipos se van revisando y refinando a medida que se obtiene nueva información.

Política de accesibilidad del producto web

La política de accesibilidad del producto web responderá a las preguntas de cada paso, y en ella se recogerán y justificarán todas las decisiones que se han tomado en cada uno de dichos pasos. Hay un ejemplo de política de accesibilidad de un producto web en el Anexo E2.

En el Anexo G se trata el reto de la accesibilidad en productos que pueden presentar especiales dificultades (redes sociales, juegos en línea, basados en vídeo, sitios que permiten a los usuarios crear sus propios contenidos, plataformas de eLearning, etc.) ofreciendo recomendaciones y buenas prácticas.

Asegurar la accesibilidad a lo largo del ciclo de vida de un producto web (capítulo 8)

Para garantizar la accesibilidad del producto, la organización debe asegurarse de que las necesidades de las personas con discapacidad y de las personas mayores se tienen en cuenta desde el inicio, se recogen en los requisitos del producto y se testean a lo largo de todo el ciclo de vida del proyecto, y no solo al final del mismo.

La identificación de los problemas de accesibilidad lo antes posible mejora la viabilidad de abordar los problemas y reduce el coste de hacerlo.

Como se ha ido viendo en el capítulo 6, las organizaciones deben integrar las consideraciones de accesibilidad a lo largo del ciclo de vida de un producto.

Concepción inicial y análisis de requisitos

Las necesidades de las personas con discapacidad y las personas mayores se reúnen al mismo tiempo que se define la especificación de requisitos del producto web.

Los métodos de investigación etnográficos deben permitir recoger con precisión los requisitos particulares de las personas con discapacidad y las personas mayores. En el Anexo N se incluyen diferentes perfiles de usuarios con discapacidad que se han de tener en cuenta.

Adquisiciones o producción

Se define un plan de pruebas de accesibilidad durante las diferentes fases del desarrollo (diseño, prototipado y construcción), que por razones económicas y logísticas se recomienda armonizar con el plan de pruebas de usabilidad con audiencias más generales.

El plan de pruebas especifica qué tipo de pruebas se requieren para la aceptación formal de que el producto mantiene el grado de experiencia de usuario al que aspira.

El plan de pruebas debe indicar claramente:

qué métodos de pruebas de accesibilidad se utilizarán, y en qué puntos del proceso de producción;
cómo los métodos de pruebas apoyarán al equipo de producción para asegurar el progreso hacia el grado de experiencia de usuario deseado;
cómo se documentarán los resultados de las pruebas;
cómo los resultados de las pruebas se integrarán en el proceso de producción para mejorar el producto.

Servicio post-lanzamiento.

Tras el lanzamiento, y con cada actualización, el producto web se testeará para asegurar que sigue manteniendo el grado de experiencia de usuario al que aspira.

Involucrar a los usuarios

Cuando sea razonable y posible, se alienta a las organizaciones a involucrar a los usuarios con discapacidad y a las personas mayores en el proceso de desarrollo. Esto ayuda a los equipos de producción a entender los problemas de accesibilidad en el mundo real y a poner en prácticas soluciones de accesibilidad más eficaces.

Métodos de evaluación de la accesibilidad web

Todo el capítulo 8.4 está dedicado a los métodos de testing de accesibilidad.

La norma indica que las organizaciones deben utilizar una combinación de métodos de prueba en función de la naturaleza del producto que se está probando y los recursos de la organización.

Cómo mínimo

Los siguientes métodos se deben utilizar como mínimo:

Pruebas de validación de código, herramientas que incluyen la validación de HTML y CSS.
Evaluación manual por parte de expertos respecto a las WCAG (también respecto a las ATAG si tiene componentes de autor) puesto que muchos criterios no pueden validarse automáticamente.
Pruebas con productos de apoyo y ajustes del navegador y el sistema operativo. Se especifican los pruebas mínimas que han de hacerse.

Se debería incluir un mecanismo para conseguir feedback de los usuarios con discapacidad.

Recomendable

Los siguientes métodos son muy recomendables y deben utilizarse si la organización tiene recursos para probar más rigurosamente la usabilidad y accesibilidad técnica del producto.

Opinión de los expertos sobre los primeros diseños o prototipos (para identificar potenciales problemas de accesibilidad durante el diseño visual y el diseño de interacción) y el código final (para identificar posibles problemas de accesibilidad con la codificaciones de estos diseños). La revisión experta emplea una metodología más rigurosa y fiable para encontrar los problemas de accesibilidad y son útiles antes de las pruebas de usuarios.
Pruebas con usuarios que incluyan usuarios con discapacidad y personas mayores de la audiencia objetiva para intentar lograr tareas en función de los objetivos de usuario del producto. Detalla cómo y cuándo deben realizarse en el capítulo 8.4.6. En el Anexo N se definen usuarios representativos y en el Anexo O se incluye una guía para hacer pruebas de usuario con personas con discapacidad y personas mayores.

Periódicamente y tras el lanzamiento

Para auditar sitios grandes, y sobre todo para garantizar la accesibilidad después del lanzamiento, periódicamente se deben realizar evaluaciones automatizadas de la conformidad del sitio respecto a las WCAG.

No debe ser el único método de evaluación y no es suficiente para afirmar que sea conforme a las WCAG.

Por último se aborda la programación de pruebas de accesibilidad tras el lanzamiento. Las organizaciones deben desarrollar un programa regular de pruebas de accesibilidad después del lanzamiento para mantener el grado de experiencia de usuario especificado en la política de accesibilidad del producto.

Conclusiones

Al igual que no se puede abordar la usabilidad o la estrategia de posicionamiento en buscadores al final del desarrollo, o peor aún tras el lanzamiento, de un sitio o aplicación web, tampoco debemos abordar la accesibilidad web como una mera evaluación final antes de la puesta en producción. La identificación de los problemas de accesibilidad lo antes posible mejora la viabilidad de abordar los problemas y reduce el coste de hacerlo.

La accesibilidad debe formar parte de la estrategia de la organización y tenerse en cuenta en todo el ciclo de vida del proyecto, pues cada decisión que se toma a lo largo del mismo afectará a si el producto incluye o excluye a las personas con discapacidad o las personas mayores. Pero no solo a ellas, sino a todos nosotros en muchos contextos de uso. Una web accesible mejora la experiencia de todos sus usuarios.

La BS 8878:2010 establece un estándar para la calidad del proceso de creación de productos web accesibles. Describe de una manera sencilla, con ejemplos y recursos de interés, cómo integrar la accesibilidad web en todas las etapas de un proceso de Diseño Centrado en el Usuario, con el objetivo de conseguir que los productos web sean más accesibles y fáciles de usar, y que ello impacte lo menos posible en los plazos y los costes.

Lo aborda también de una manera realista, porque prevé que las decisiones no suelen darse en casos ideales, sino en el mundo real, donde hay unos plazos y un presupuesto al que ajustarse, guiándonos sobre cómo tomar las mejores decisiones en cada caso, considerando todas las opciones e implicaciones.