7.3.1. Accesibilidad de software en general: UNE 139802:2003

La norma UNE 139802:2003 (AENOR, 2003) ha sido desarrollada por el Subcomité 8 del Comité Técnico Nacional 139 de AENOR, denominado de forma abreviada AEN CTN 139 / SC8. El Comité CTN 139 se denomina “Tecnologías de la Información y las Comunicaciones para la Salud”, y el subcomité 8, llamado “Sistemas y dispositivos para la tercera edad y la discapacidad”, fue creado en el año 1995 con el fin de desarrollar normas técnicas de accesibilidad a la informática. Este subcomité fue el responsable de la publicación, en 1998, de dos Normas Técnicas Experimentales, que fueron las primeras a nivel mundial en ser publicadas por un Organismo Oficial de Normalización: UNE 139801:1998 EX para el hardware (AENOR, 1998a) y UNE 139802:1998 EX para el software (AENOR, 1998b). Estas normas fueron revisadas en su totalidad y publicadas de nuevo en el año 2003. Por lo tanto la norma UNE 139802:2003 es la que debe tenerse en cuenta en España para el desarrollo de aplicaciones software accesibles aplicación.

El título de esta Norma es “Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad al ordenador. Software”. La Norma Técnica de software es más compleja que la de hardware y contiene 90 requisitos con la siguiente estructura: texto normativo, prioridad, notas y ejemplos. Cada uno de los requisitos tiene asignado un nivel de prioridad, entre el 1 (máxima importancia) y el 3 (menor importancia) y, además, cada requisito tiene como ámbito de aplicación el sistema operativo, las aplicaciones o ambos.

Estos requisitos están agrupados en 10 secciones:

  • Principios generales. Dentro de este grupo de requisitos puede destacarse: que el software debe minimizar el número de acciones del usuario; que debe permitir que el usuario elija dispositivos de entrada y salida y debe poder ser utilizado sólo con uno de ellos; que se deben usar los servicios de accesibilidad del sistema operativo y que no se debe interferir con dichos requisitos. Por otro lado, se recomienda incorporar la función de deshacer, facilitar la definición de preferencias de usuario y utilizar los servicios de entrada / salida estándar del entorno.
  • Teclado. Lo más importante de este grupo de requisitos es que el usuario debe poder utilizar el programa sólo con teclado.  Por otro lado, la navegación por teclado no debe activar objetos de la interfaz y se deben ofrecer alternativas a la pulsación simultánea de varias teclas (muchos sistemas operativos lo permiten). También es recomendable ofrecer atajos de teclado para las funciones más importantes, permitir que el usuario modifique la asignación de funciones a las teclas, ofrecer una secuencia de navegación por teclado consistente con la distribución de elementos en pantalla y, por último, respetar las convenciones de uso del teclado del sistema operativo.
  • Dispositivos apuntadores (principalmente el ratón). Los programas deben permitir cambiar la asignación de funciones de los botones del ratón y también deben permitir hacer doble clic y el arrastre mediante pulsaciones simples de teclas o botones.
  • Pantalla. Entre los requisitos más importantes de este grupo está el de no usar el color como única fuente de información; utilizar las funciones estándar del entorno para mostrar texto; permitir que el usuario cambie aspectos visuales (colores, tamaños, tipos de letra) y evitar frecuencias de refresco que puedan provocar ataques epilépticos. Otro aspecto importante es la asociación explícita y por posición entre etiquetas y campos de formularios.
  • Sonidos y multimedia. Deben ofrecerse alternativas a las salidas de sonido (como los subtítulos) y debe permitirse que el usuario modifique parámetros del sonido, principalmente su volumen.
  • Notificación al usuario. Los mensajes emitidos al usuario deben ser redactados para facilitar su identificación y comprensión por personas sin conocimientos técnicos.
  • Información de objetos. Las aplicaciones deben proporcionar información textual asociada a todos los objetos de su interfaz, de forma que tanto las ayudas técnicas como los revisores de pantalla puedan presentársela al usuario de la forma más adecuada.
  • Tiempo. Se debe ofrecer al usuario el control sobre aspectos dependientes del tiempo, como contenidos dinámicos o mensajes con tiempo límite de respuesta.
  • Documentación. La documentación debe ser clara y sencilla y debe proporcionarse en formatos alternativos bajo petición del usuario. Además debe ofrecerse ayuda en pantalla.
  • Otros requisitos. Para las aplicaciones el único requisito de este grupo es que se ofrezca la función de salir del programa.

    7.3.2. Accesibilidad de herramientas de autor: ATAG 1.0

Las Directrices de Accesibilidad para las Herramientas de Autor (ATAG 1.0) fueron desarrolladas por la Iniciativa para la Accesibilidad Web del Consorcio de la Web (W3C, 2000) y se publicaron como recomendación del consorcio en febrero del año 2000. ATAG proporciona directrices para quienes desarrollan herramientas de autor para la Web. Su objetivo es doble: ayudar a los desarrolladores a diseñar herramientas de autor que generen contenidos de la Web accesibles y ayudarles a crear una interfaz de autor accesible.
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 diseñadas específicamente para la creación de páginas Web (por ejemplo, editores WYSIWYG HTML, paquetes de autor de SMIL, etc.).
  • Herramientas que ofrezcan la posibilidad de archivar el material en formato Web (por ejemplo, procesadores de texto, paquetes de autoedición).
  • Herramientas que traduzcan documentos a formato web (por ejemplo, filtros que traduzcan formatos de autoedición a HTML).
  • Herramientas que produzcan contenidos multimedia, especialmente cuando se pretende utilizar esos contenidos en la  web (por ejemplo, producción de vídeo, programas de edición).
  • Herramientas para manejo del sitio o publicación del sitio, incluyendo conversiones “al vuelo” y herramientas de publicación del sitio Web.
  • Herramientas  para manejo del aspecto (por ejemplo, herramientas CSS para formato de páginas).

ATAG tiene tres grandes objetivos: la herramienta de autor debe ser accesible en sí misma; la herramienta de autor debe generar contenidos accesibles y la herramienta de autor debe favorecer la creación de contenidos accesibles.
El documento ATAG 1.0 tiene 7 pautas de alto nivel:

  • Dar soporte a prácticas accesibles de autoría. Si las marcas se generan de forma automática, muchos autores no se darán cuenta de la accesibilidad del producto final, a menos que le dediquen un esfuerzo añadido para realizar las correcciones oportunas a mano. Puesto que a un número importante de autores la accesibilidad no les resulta familiar, las herramientas de autor son responsables de generar marcado accesible de forma automática y, donde sea adecuado, de guiar al autor para producir contenido accesible. Muchas aplicaciones permiten traducir documentos de otros formatos (por ejemplo, Formato de Texto Enriquecido, Rich Text Format) a un formato de marcas para la web tipo HTML. Cambios en las marcas también se pueden crear para facilitar una edición y una manipulación eficientes. Es esencial que estos procesos no introduzcan código no accesible o eliminen contenidos accesibles, sobre todo cuando la herramienta oculta los cambios de marcado en la vista del autor.
  • Generar marcado estándar. La conformidad con estándares promueve la interoperabilidad y la accesibilidad al facilitar que existan agentes de usuario (navegadores) especializados para usuarios concretos. Por ejemplo, hay ayudas técnicas que sólo permiten acceder a contenido web si usa marcado válido. Por lo tanto, es esencial que las herramientas de autor generen marcado válido.
  • Dar soporte a la creación de contenido accesible. Una información bien estructurada y la incorporación de contenidos accesibles equivalentes son fundamentales para un diseño accesible. Sin embargo, la producción de información equivalente puede ser uno de los aspectos más complejos del diseño web y las herramientas de autor deben facilitar y automatizar este proceso. A modo de ejemplo, se puede solicitar a un autor texto alternativo cada vez que se inserta una imagen.
  • Proporcionar medios para verificar y corregir contenido inaccesible. Muchas herramientas permiten al autor crear documentos con poco o ningún conocimiento de las marcas subyacentes. Para asegurar la accesibilidad, las herramientas de autor deben ser diseñadas de forma que puedan identificarse automáticamente contenidos inaccesibles, y permitir su corrección incluso en los casos en los que las marcas estén ocultas al  autor. Para ayudar en la creación de contenidos accesibles de la Web, las herramientas de autor deben tener en cuenta  los diferentes estilos de autor de sus usuarios. Algunos usuarios preferirán ser advertidos de los problemas cuando surgen, mientras que otros preferirán  hacer las correcciones al tener el documento acabado.
  • Integrar las soluciones de accesibilidad en la interfaz de usuario (en el look and feel). Cuando se añade una nueva característica a una herramienta existente sin una integración apropiada, el resultado por lo general es una discontinuidad obvia. Diferentes esquemas de color, fuentes, estilos de interacción e incluso la estabilidad de la aplicación pueden ser factores que afecten la aceptación por parte del usuario de la nueva característica. Además, la relativa prominencia de formas distintas de hacer lo mismo puede influenciar al autor en su elección de técnicas. Por lo tanto, es importante que la creación de contenido accesible sea un proceso natural dentro de la herramienta.
  • Promover la accesibilidad en la ayuda y documentación. Los autores pueden no estar familiarizados con los problemas de accesibilidad que surgen al crear contenido web. La ayuda y la documentación deberían  explicar los problemas habituales de accesibilidad y sus soluciones con ejemplos ilustrativos.
  • Asegurar que la herramienta de autor es accesible para autores con discapacidad. Las herramientas de autor son aplicaciones con elementos de interfaz de usuario estándar y como tal tienen que seguir una pauta de accesibilidad de la interfaz de usuario. Esto afecta a toda la funcionalidad de la herramienta: para poder editar un documento, el autor debe ser capaz de localizar y seleccionar párrafos de texto específicos, recorrer de forma eficiente el documento, y encontrar y marcar rápidamente los puntos de inserción. Los autores que utilizan lectores de pantalla, presentadores de braille actualizables, o magnificadores de pantalla, pueden hacer un uso limitado, en el mejor de los casos, de artefactos visuales que comunican la estructura del documento y actúan como postes de señales cuando recorren el documento.
retroceder avanzar