Accesibilidad en aplicaciones de escritorio

Índice

Introducción
Legislación
Normativa
- 3.1 Introducción: normativa nacional e internacional
- 3.2 Norma UNE 139802:2003. Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad al ordenador. Software
- 3.3 Directrices de accesibilidad de la Web Accessibility Initiative (WAI): ATAG 1.0 y UAAG 1.0
Metodología
- 4.1 Gobierno de Irlanda: accessIT
- 4.2 Microsoft
Herramientas de validación
- 5.1 Comunes a la validación de aplicaciones web
- 5.2 Linux
- 5.3 Microsoft
- 5.4 MAC
- 5.5 Listas de comprobación (checklists)
Certificación
Recursos y referencias
Notas

1. Introducción

Hace unas semanas recibí por correo una consulta que me pareció especialmente interesante.

Se resume en que hay mucha más sensibilización respecto a la accesibilidad en aplicaciones web que respecto a la accesibilidad en aplicaciones de escritorio, que parece la gran olvidada. La diferencia entre el volumen de recursos e información de una frente a la otra es abrumadora.

Es fácil saber, cuando hablamos de accesibilidad web, qué legislación existe, qué normativa se aplica, qué metodología y herramientas nos permiten validar nuestro proyecto o qué entidades certificadoras hay (1).

Sin embargo no existe ningún sitio donde se recopile toda esta información en referencia a las aplicaciones de escritorio.

¿Existe una normativa específica?

¿Hay alguna ley que establezca el nivel mínimo de accesibilidad que debe cumplir el software en España?

¿Hay entidades certificadoras de la accesibilidad de las aplicaciones de escritorio?

¿Cómo se valida la accesibilidad en dichas aplicaciones?

Este artículo pretende recopilar la información necesaria para contestar a esas preguntas. Espero que sirva no sólo para contestar a la persona que me hizo la consulta o a quienes busquen esta misma información, sino también para divulgar la necesidad de que las aplicaciones de escritorio (que puede ser hasta un simple CD multimedia) también sean accesibles.

2. Legislación

El REAL DECRETO 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social dice así:

Artículo 8. Condiciones básicas de accesibilidad a los equipos informáticos y a los programas de ordenador.

1. Los equipos informáticos y los programas de ordenador –independientemente de que sea libre o esté sometido a derechos de patente o al pago de derechos– utilizados por las administraciones públicas, cuyo destino sea el uso por el público en general, deberán ser accesibles a las personas mayores y personas con discapacidad, de acuerdo con el principio rector de «Diseño para todos» (2) y los requisitos concretos de accesibilidad exigidos, preferentemente en las normas técnicas nacionales que incorporen normas europeas, normas internacionales, otros sistemas de referencias técnicas elaborados por los organismos europeos de normalización o, en su defecto, normas nacionales (Normas UNE 139801:2003 y 139802:2003), y en los plazos establecidos en el apartado 1 de la disposición transitoria única del real decreto por el que se aprueba el presente reglamento.

El plazo establecido es el 31 de diciembre de 2008.

3. Normativa

3.1 Introducción: normativa nacional e internacional

En 1998 AENOR (Agencia Española de Normalización y Certificación) elabora la primera norma mundial de accesibilidad a las plataformas informáticas, la UNE 139802:1998 EX: informática para la salud: aplicaciones informáticas para personas con discapacidad: requisitos de accesibilidad de las plataformas informáticas: soporte lógico.

Esta norma fue revisada, ampliada y dividida en tres:

La que nos interesa en este artículo es la segunda, la relativa a los programas o software.

Existen otras normas nacionales relacionadas:

PNE 139804 Aplicaciones informáticas para personas con discapacidad. Requisitos para el uso de la Lengua de Signos Española en redes informáticas.
UNE 170001-1:2007 Accesibilidad universal. Parte 1: Criterios DALCO para facilitar la accesibilidad al entorno UNE 170001-1:2001
UNE 170001-2:2007 Accesibilidad universal. Parte 2: Sistema de gestión de la accesibilidad. UNE 170001-2:2001
UNE 170006:2003 Directrices para que el desarrollo de las normas tenga en cuenta las necesidades de las personas mayores y las personas con discapacidad.
UNE 153010:2003 Subtitulado para personas sordas y personas con discapacidad auditiva. Subtitulado a través del teletexto.
UNE 153020:2005 Audiodescripción para personas con discapacidad visual: requisitos para la audiodescripción y elaboración de audioguías.
UNE-EN ISO 9999:2003 Ayudas técnicas para personas con discapacidad. Clasificación y terminología

A nivel internacional existen las siguientes normas relacionadas con la accesibilidad del software:

ISO TS 16071:2003 Ergonomics of human-system interaction. Guidance on accessibility for human-computer interfaces
ISO DIS 9241-20 Ergonomics of human-system interaction. Part 20: Accessibility guidelines for information/communication technology (ICT) equipment and services
ISO DIS 9241-171:2008 Ergonomics of human-system interaction. Part 171: Guidance on software accessibility
ISO DIS 9241-151:2008 Ergonomics of human-system interaction. Part 151: Guidance on World Wide Web user interfaces

Entre las que destacaría la ISO IS 9241-171:

ISO 9241-171:2008 provides ergonomics guidance and specifications for the design of accessible software for use at work, in the home, in education and in public places. It covers issues associated with designing accessible software for people with the widest range of physical, sensory and cognitive abilities, including those who are temporarily disabled, and the elderly. It addresses software considerations for accessibility that complement general design for usability as addressed by ISO 9241-110, ISO 9241-11 to ISO 9241-17, ISO 14915 and ISO 13407.

ISO 9241-171:2008 is applicable to the accessibility of interactive systems. It addresses a wide range of software (e.g. office, Web, learning support and library systems).

It promotes the increased usability of systems for a wider range of users. While it does not cover the behaviour of, or requirements for, assistive technologies (including assistive software), it does address the use of assistive technologies as an integrated component of interactive systems.

It is intended for use by those responsible for the specification, design, development, evaluation and procurement of software platforms and software applications.

Por otra parte, la Unión Europea toma como normas de facto las Directrices de Accesibilidad que produce el WAI.

3.2 Norma UNE 139802:2003. Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad al ordenador. Software

La Norma UNE 139802:2003. Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad al ordenador. Software establece las características que ha de cumplir el software de ordenador:

aplicaciones informáticas
entornos operativos (sistema operativo más la interfaz de usuario asociada)
documentación asociada

para que puedan ser utilizados por la mayor parte de las personas, incluyendo personas con discapacidad y personas de edad avanzada, de forma autónoma o mediante las ayudas técnicas pertinentes.

Son 93 requisitos agrupados en 10 categorías. Dentro de cada categoría los requisitos se agrupan por su prioridad, igual que en las WCAG (Web Content Accessibility Guidelines) hay prioridad 1, 2 y 3. En cada requisito se indica si su ámbito de aplicación es: sistema operativo, aplicaciones o ambos.

Las categorías son:

Principios generales (17 requisitos)
Teclado (19 requisitos)
Dispositivos apuntadores (12 requisitos)
Pantalla (20 requisitos)
Sonido y multimedia (6 requisitos)
Notificación al usuario (2 requisitos)
Información de objetos (6 requisitos)
Tiempo (3 requisitos)
Documentación (5 requisitos)
Otros (3 requisitos)

[…] El problema de la accesibilidad del software resulta mucho más complejo por resultar sus componentes y sus fronteras mucho más difusas.

[…] el enfoque haya sido más orientado a los elementos que componen el interfaz de usuario, que a los problemas característicos de cada discapacidad.

Además la norma afecta muy poco a las partes internas o capas inferiores del software, de manera que se limita a hacer una aproximación desde el punto de vista de la usabilidad de las plataformas, manteniéndose alejada de los detalles internos y de construcción de los elementos que conforman las plataformas informáticas.

"Primera norma mundial de accesibilidad a las plataformas informáticas" de Javier Romañach Cabrero en SIDAR.

Se puede consultar un resumen de los requisitos más importantes de la norma en las siguientes direcciones:

"7.3.1. Accesibilidad de software en general: UNE 139802:2003" del informe Accesibilidad, TIC y Educación del Ministerio de Educación y Ciencia
"Primera norma mundial de accesibilidad a las plataformas informáticas" de Javier Romañach Cabrero en SIDAR
"Directrices para mejorar la accesibilidad a los recursos electrónicos en los servicios de información públicos" de José Ángel Martínez Usero

3.3 Directrices de accesibilidad de la Web Accessibility Initiative (WAI): ATAG 1.0 y UAAG 1.0

Si nuestro software sirve para crear páginas y contenido Web (3), por ejemplo porque permite guardar en formato HTML, debería cumplir con las Pautas de Accesibilidad para Herramientas de Autor (ATAG) 1.0.

El objetivo de estas pautas es doble, puesto que quiere ayudar a los desarrolladores a:

diseñar herramientas de autor que generen contenidos para la Web accesibles
crear una interfaz de autor accesible

Las ATAG 1.0 tienen 28 puntos de verificación de prioridad 1, 2 y 3 organizados en 7 pautas de alto nivel:

Dar soporte a prácticas accesibles de autoría.
Generar marcado estándar.
Dar soporte a la creación de contenido accesible.
Proporcionar medios para verificar y corregir contenido inaccesible.
Integrar las soluciones de accesibilidad en la interfaz de usuario.
Promover la accesibilidad en la ayuda y documentación.
Asegurar que la herramienta de autor es accesible para autores con discapacidad.

Se puede consultar un resumen de las mismas en "7.3.1. Accesibilidad de software en general: UNE 139802:2003" del informe Accesibilidad, TIC y Educación del Ministerio de Educación y Ciencia.

Si nuestro software es un agente de usuario, esto es, un navegador, un reproductor multimedia o una tecnología asistiva (software que algunas personas con discapacidad utilizan para interactuar con los dispositivos) debería cumplir con las Pautas de Accesibilidad para Agentes de Usuario (UAAG) 1.0.

Son un conjunto de puntos de verificación organizados en 12 pautas que incluyen:

Acceso a todo el contenido, incluyendo contenido en relación de eventos generados por el ratón o el teclado.
Control del usuario sobre la forma en que se muestra el contenido.
Control del usuario sobre la interfaz del usuario, con documentación sobre características de accesibilidad.
Interfaces de programación estándares, para permitir la interacción con tecnologías asistivas.

4. Metodología

4.1 Gobierno de Irlanda: accessIT

Planning and Procurement

Assess a design concept or prototype
- Step 1. Consider the following high-level questions.
- Step 2. Apply the NDA application software accessibility guidelines
Assess a current offering for accessibility
- Step 1. Determine the required level of compliance.
- Step 2. Use the accessibility checklist.
- Step 3. Consult the test methods for each guideline
- Step 4. Test with real users, where appropriate
Scope accessibility requirements
- Step 1. Consult users or user advocates.
- Step 2. Decide which of the NDA guidelines the application should meet
Write a design brief or a Request For Tenders (RFT)
- Step 1. Scope the accessibility requirements for the project.
- Step 2. Write these requirements into the RFT, giving them a weighting.
- Step 3. Encourage an inclusive user-centred design process.
- Step 4. State the testing requirements.

Design and Development

Plan a design project
Interpret accessibility requirements
- Step 1. Determine the required level of compliance
- Step 2. Consult the NDA accessibility guidelines
- Step 3. Read the introduction to each guideline
- Step 4. Read the rationale for each guideline.
Choose design and implementation techniques
- Step 1. Consult the NDA web accessibility guidelines
- Step 2. Read the suggested techniques for each guideline

Testing, Assessment and Quality Assurance

User test a design or prototype
Assess a design concept or prototype
- Step 1. Consider the following high-level questions.
- Step 2. Apply the NDA application software accessibility guidelines
Assess a current offering for accessibility
- Step 1. Determine the required level of compliance.
- Step 2. Use the accessibility checklist.
- Step 3. Consult the test methods for each guideline
- Step 4. Test with real users, where appropriate
Scope accessibility requirements
- Step 1. Consult users or user advocates.
- Step 2. Decide which of the NDA guidelines the application should meet

4.2 Microsoft

Es interesante su recurso "Cómo desarrollar un plan de tecnología de accesibilidad". Un plan de cinco pasos basado en los descritos en el libro de Susan Conway y Char Sligar "Unlocking Knowledge Assets" (2002).

5. Herramientas de validación

La validación de la accesibilidad web debe estar basada siempre en la revisión manual, sin embargo existen herramientas que facilitan una primera revisión automática (TAW, HERA, PISTA, etc.)

Por el contrario, no existe ninguna herramienta genérica que permita evaluar automáticamente la accesibilidad de un aplicación de escritorio (y mucho menos respecto a la Norma UNE 139802:2003).

Para verificar por tanto si un software es accesible deberemos comprobar manualmente cada uno de los requisitos de la Norma UNE 139802:2003, que aunque no cuenta con una lista de comprobación, es fácil de seguir.

Sin embargo, hay ciertas aplicaciones que nos pueden ayudar. En primer lugar nombraré aquellas que son comunes a la validación de aplicaciones web e independientes de la plataforma; en segundo lugar las herramientas específicas de cada sistema operativo, que permiten evaluar ciertos aspectos de la accesibilidad de las aplicaciones de escritorio; por último, nombraré las checklists o listas de comprobación más reconocidas que pueden complementar nuestra revisión.

Si conoces más recursos, por favor, compártelos con nosotros en los comentarios.

5.1 Comunes a la validación de aplicaciones web

La Norma UNE 139802:2003 dice:

4.4.15 Deben proporcionarse combinaciones de colores predefinidas que hayan sido diseñadas teniendo en cuenta las necesidades de las personas con deficiencias visuales.

4.4.2 No debe usarse el color como única fuente de información.

Para verificar estos puntos contamos con:

Colour Contrast Analyser 2.0. Herramienta local que evalúa si hay suficiente contraste entre un color de fondo y un color de primer plano. Se basa en el algoritmo Contrast Ratio propuesto por el World Wide Web Consortium (W3C).
Analizador de Contraste de Color 1.0. Herramienta local que permite mostrar resultados de contraste para la ceguera cromática.

Para validar el punto 4.4.6 Se debe evitar presentar elementos que parpadeen o destellen con una frecuencia entre 2 y 50 Hz., podemos contar con Photosensitive Epilepsy Analysis Tool (PEAT), herramienta gratuita que valida ficheros ".avi".

La Norma también indica:

4.6.1 Los mensajes emitidos deben ser cortos, sencillos y redactados en un lenguaje claro para el usuario no técnico.

4.9.1 La documentación del producto debe estar redactada de la forma más clara y sencilla posible, dentro del vocabulario del dominio de la aplicación

EJEMPLO: Debe intentar evitarse el uso de terminología en otros idiomas si el concepto tiene una forma de expresarse recogido en el Diccionario de la Real Academia Española.

Para validar estos puntos podemos utilizar:

TxReadability, que evalúa la complejidad de un texto.
Stilus, revisor que detecta cuatro tipos de errores: ortografía, gramática, tipología y estilo.
Otros revisores de ortografía son: Corrector ortográfico.com, Revisor, Total validator y Orangoo
Se puede consultar otros recursos lingüísticos (traductores, diccionarios, etc.) en la Oficina de Español en la Sociedad de la Información (OESI) del Instituto Cervantes
Siempre conviene tener a mano la dirección de la RAE (Real Academia de la Lengua)

La Norma establece también: 4.9.2 Se deben proporcionar sistemas de ayuda en texto sencillo, complementado de forma opcional mediante lengua de signos.

En este sentido es interesante saber que actualmente IBM esta desarrollando un traductor automático a la lengua de signos.

5.2 Linux

Accerciser, es una herramienta para el escritorio de GNOME que permite ver la información de accesibilidad que una determinada aplicación ofrece a las ayudas técnicas (lectores de pantalla, teclados en pantalla, etc.)

De esta manera, un desarrollador puede ir verificando en la fase de desarrollo de la aplicación si su aplicación está siendo accesible a estas ayudas, y por tanto que pueda utilizarla personas con discapacidad.

Cosas que se pueden verificar en esta aplicación son: el nombre o descripción en componentes visuales, la relación entre etiquetas y otros componentes.

[…] Accersicer puede ser personalizado, ya que permite la creación de plugins.

Obtiene la accesibilidad de AT-SPI, al igual que los lectores de pantalla Orca y LSR.

Accerciser está hecho en Python, y lo más importante es que es libre y gratuito.

En "Accerciser: Herramienta para verificar la accesibilidad en aplicaciones" de tiflolinux.org

Más información sobre accesibilidad en Linux en las siguientes direcciones:

5.3 Microsoft

Microsoft permite descargar para las aplicaciones que corren en Windows el Active Accessibility 2.0 SDK Tools que consta de:

Accessible Event Watcher. The Accessible Event Watcher (AccEvent) tool allows developers and testers to validate that the user interface (UI) elements of an application raise proper Active Accessibility events when the UI changes. Changes in the UI occur when a UI element is invoked, selected, or has a state change, or when the focus changes.
Accessible Explorer. The Accessible Explorer program allows you to examine the IAccessible properties of objects and how objects are related to each other.

Inspect Objects. The Inspect Objects tool allows developers and testers to examine the IAccessible property values of the the user interface (UI) items of an application and to navigate to other objects.

Para más información sobre Microsoft y accesibilidad consultar las siguientes direcciones:

aDesigner

Es una herramienta local gratuita que permite simular cómo "ve" una página dos tipos de usuarios diferentes: una persona ciega con un lector de pantalla o una persona con visión reducida. Además permite evaluar la accesibilidad de documentos ODF, animaciones Flash o de una aplicación de escritorio.

5.4 MAC

En MAC tenemos:

Accessibility Verifier: Accessibility Verifier displays the accessibility hierarchy comprising all currently instantiated objects in the selected application. To use Accessibility Verifier, be sure to enable assistive applications in the Universal Access Preferences.
Accessibility Inspector: Accessibility Inspector presents a utility window that displays the attributes (and values), actions, and position in the accessibility hierarchy of the object currently under the mouse pointer […] If you’re beginning to access-enable your application, try using Accessibility Inspector to view the accessibility information other applications provide. Although Accessibility Inspector is not an assistive application, it uses the same APIs assistive applications use to get information from the accessibility objects it encounters.

Más información sobre MAC y accesibilidad en Apple Developer Connection.

5.5 Listas de comprobación (checklists)

La metodología del Gobierno de Irlanda hace referencia a sus "Application software accessibility guidelines".

These guidelines cover application software running under any operating system or runtime environment such as Windows, Macintosh, Unix, Linux, Java.

Directrices: "Application software accessibility guidelines". Acceder a la versión para impresión
Checklist "Application software accessibility guidelines"

La Sección 508 del Acta de Americanos con Discapacidad de EEUU recomienda:

Guidelines "Requirements for Accessible Software Design"
Lista de comprobación "Software Accessibility Checklist" del Departamento de Justicia, disponible también en la web del U.S. Department of Labor

Son también muy conocidas las listas de comprobación de:

6. Certificación

Así como existe una Certificación de Accesibilidad TIC (Accesibilidad Web) conforme a la Norma UNE 139803:2004 no existe una certificación especifica sobre la accesibilidad del software basada en la norma Norma UNE 139802:2003.

Por otra parte, al igual que existen numerosas empresas que ofrecen asesoría y consultoría de accesibilidad web, es muy difícil encontrar alguna que ofrezca estos servicios en relación con el software de escritorio.

El logotipo de certificación para Windows incluye requisitos de accesibilidad. Según estos requisitos, una aplicación accesible:

Admite las configuraciones de tamaño, color, fuente y entrada del Panel de control. La barra de menú, la barra de título, los bordes y la barra de estado cambian todos automáticamente de tamaño cuando el usuario cambia la configuración del Panel de control. En esta aplicación no es necesario hacer más cambios en los controles ni en el código.
Admite el modo de Contraste alto.
Proporcionar acceso mediante teclado documentado a todas las funciones.
Expone la ubicación del foco del teclado de forma visual y mediante programación.
Evita ofrecer información importante únicamente por medio de sonido.

Más información en "Crear una aplicación accesible basada en Windows" en MSDN.

Si alguien tiene más información sobre este apartado le agradecería que lo compartiera en los comentarios.

7. Recursos y referencias

7.1 Legislación, normalización y certificación

7.2 Metodología, guidelines y checklists

7.3 Usabilidad

Notas

(1) Puedes obtener esa información relacionada con aplicaciones web en las siguientes direcciones:

(2) Los principios del diseño para todos son siete:

Uso equiparable
Uso flexible
Simple e intuitivo
Información perceptible
Con tolerancia al error
Que exija poco esfuerzo físico
Tamaño y espacio para el acceso y uso

Más información en "Principios del Diseño Universal o Diseño para Todos" en SIDAR

(3) Se pretende que estas directrices sean utilizadas por los creadores de todas las herramientas utilizadas para crear una página Web, entre las que se incluyen:

Herramientas de edición específicamente diseñadas para producir contenido Web, por ejemplo, editores HTML y XML de "what you see is what you get" (WYSIWYG)
Herramientas que ofrecen la opción de guardar contenido en formato Web, por ejemplo, procesadores de texto o paquetes de publicación.
Herramientas que transforman documentos a un formato Web, por ejemplo, filtros que transforman formatos de publicación a HTML.
Herramientas que producen multimedia, especialmente cuando se quiere utilizar en la Web, por ejemplo, producción de vídeo y edición, paquetes de autor de SMIL.
Herramientas para la administración o publicación de sitios Web, incluidos gestores de contenido (CMS), herramientas que automáticamente generan sitios Web de forma dinámica desde una base de datos, herramientas de conversión instantánea y herramientas de publicación de sitios Web.
Herramientas de diseño, por ejemplo, herramientas de formato CSS.