Comprendiendo la Accesibilidad

Una Guía para Lograr la Conformidad

en Sitios Web e Intranets
 

 

 

 

Robert B. Yonaitis

 

 

Traducción de

Emmanuelle Gutiérrez y Restrepo

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HiSoftware Logo

 

Edita HiSoftware

Concord, New Hampshire USA


Edita HiSoftware,

Concord, New Hampshire 03301 USA

 

© 2002 por HiSoftware, Inc.

6 Chenell Drive, Suite 280

Concord, NH 03301 USA

 

Tel.: (603) 229-3055

Fax: (603) 223-9741

 

Web: http://www.hisoftware.com

Email: info@hisoftware.com

 

Todos los derechos reservados. Publicado en el 2002

Impreso en los Estados Unidos de América

 

Las corporaciones, asociaciones profesionales, instituciones educativas y otras organizaciones, pueden beneficiarse de descuentos sustanciales, en la adquisición de grandes cantidades de los libros editados por HiSoftware. Para obtener información sobre descuentos, póngase en contacto con el departamento de ventas de HiSoftware, llamando al +1(603) 229-3055, o enviando un mensaje de correo electrónico a: sales@hisoftware.com.

 

ISBN

1-930616-03-1

 

Copyright 2002 por Hiawatha Island Software Company, Inc (“HiSoftware”).  Todos los derechos reservados. MARCAS REGISTRADAS: AccMonitor, AccRepair, AccVerify, AccessibilityWATCH™, HiSoftware®, son marcas registradas de Hiawatha Island Software Company, Inc. Microsoft®, Microsoft® FrontPage®, Microsoft® Office, Windows®, y Windows® NT® son marcas o marcas registradas de Microsoft Corporation en los Estados Unidos y/o otros países. Cualquiera y todos los otros nombres de productos y empresas mencionadas aquí, son marcas registradas, o marcas de servicios, de sus respectivos dueños.


Acerca del Autor

Robert B. Yonaitis, es el fundador y Director Ejecutivo de HiSoftware en Condord, New Hampshire. HiSoftware, es el principal proveedor de soluciones globales para la gestión y revisión de la accesibilidad, software de Gestión del Conocimiento, y soluciones para la gestión de sitios Web de la Administración, empresas, instituciones educativas y el mercado de consumidores. Yonaitis tiene más de 14 años de experiencia en ingeniería de software. Antes de fundar HiSoftware, lideró equipos de ingeniería en varias empresas situadas en la lista “Fortune 500” y organismos de la administración local y estatal. Yonaitis se ha especializado en rediseñar equipos, para facilitar un mayor rendimiento, disminuir el tiempo para llegar al Mercado e incrementar la calidad.

 

Image of Robert B. Yonaitis

 
Contacta con el Autor

Robert B. Yonaitis

HiSoftware, Inc.

6 Chenell Drive, Suite 280

Concord, NH 03301 USA

ryonaitis@aol.com

 

Títulos previos de Robert B. Yonaitis

WYSIWYG

The Elements of <WebSite> Promotion

Understanding Internet Traffic


RECONOCIMIENTOS

Cuando Ediciones HiSoftware publica un libro, es porque hay una enorme necesidad de aclarar algo relativo a la tecnología e Internet. Para escribir estos libros, nosotros utilizamos información que recibimos de incontables clientes, así como, de los empleados de HiSoftware. En este libro, hemos intentado identificar una estrategia, que ayudará a los lectores a tratar con los estándares de accesibilidad emergentes, a través del uso de las tecnologías, que van evolucionando. Al hacer esto, también hemos intentado crear una publicación rigurosa de “mejores practicas”, en diseño de sitios Web accesibles. Nos gustaría reconocer y agradecer, a todos los que buscan clarificar, simplificar y producir soluciones significativas al problema de la accesibilidad.

 

 

Colaboradores corporativos

Los siguientes empleados de HiSoftware, han contribuido a la creación de este libro:

 

Amy M. Overka – Editora

Dana L. Simberkoff – Editora

Thomas J. Sweet – Revisor

 

Diseño de carátula

La carátula y la maquetación son un trabajo original de:

 

Tandem Designs

http://www.tandemdesigns.com/

Kenneth Piccini & Jeannie Piccini




Tabla de Contenidos

1. Familiarizándote con los problemas de Accesibilidad y sus desafíos  15

Personas con discapacidad y el acceso a la información en la Web   17

Discapacidades atendidas por los Estándares de Accesibilidad   19

Mejorando la Web para todos.. 21

La industria y el futuro de la tecnología accesible   22

Reglamentación Federal para contenido Web accesible   23

Resumen de la Subsección B.. 24

Solicita una copia de la Sección 508. 25

Directrices de accesibilidad para el contenido Web del W3C   26

¿Cuándo entran en vigor las leyes de accesibilidad?. 26

Por dónde comenzar.. 27

Conoce las leyes de accesibilidad. 27

Encuentra recursos fidedignos. 27

Mantente informado. 28

Considera usar software automatizado. 28

¿Quién puede ayudarte?. 28

Creando Contenido Web Accesible.. 30

Diferencias entre la Sección 508 y el W3C.. 30

¿Por qué debes construir de forma accesible?. 31

Una versión del contenido. 32

2. Los puntos de control y su significado.. 35

Entendiendo el Párrafo (a) / W3C P1 (1.1) 36

Entendiendo el Párrafo (b) / W3C P1 (1.4) 38

Comprendiendo el Párrafo (c) / W3C P1 (2.1) 40

Comprendiendo el Párrafo (d) / W3C P1 (6.1) 42

Comprendiendo los párrafos (e) & (f) / W3C P1 (1.2) & (9.1) 44

Comprendiendo los párrafos (g) y (h) / W3C P1 (5.1) y (5.2) 46

Comprendiendo el Párrafo (i) / W3C P1 (12.1) 49

Comprendiendo el Párrafo (j) / W3C P1 (7.1) 50

Comprendiendo el Párrafo (k) / W3C P1 (11.4) 51

Comprendiendo el Párrafo (l) / W3C P1 (partial 6.3) 53

Comprendiendo el Párrafo (m) 55

Comprendiendo el Párrafo (n) 57

Comprendiendo el Párrafo (o) 59

Comprendiendo el Párrafo (p) 61

3. Introducción a la Revisión de la Accesibilidad   63

Errores Comunes de la Accesibilidad.. 64

Una introducción a la garantía de calidad.. 65

Revisando la versión Beta. 69

Introducción a la Revisión de la Accesibilidad   69

Página versus Sitio. 70

Distribución Avanzada de Contenido. 71

Usando Herramientas.. 72

Herramientas de verificación. 72

Herramientas de Rehabilitación (Reparación) 75

Herramientas de monitoreo. 76

Qué no pueden hacer las herramientas automáticas. 77

Evaluando Herramientas de Revisión y Reparación de la Accesibilidad  77

Sistemas existentes de Gestión de Contenido.. 79

Arquitecturas de revisión existentes.. 79

¿Qué es un API?. 80

4. Desarrollando una Estrategia de Conformidad con la Accesibilidad   81

Mirando adelante.. 82

La Dirección Correcta.. 84

Una aproximación por fases.. 85

La evaluación de un sitio. 87

Estableciendo metas. 93

Estableciendo Directrices de Diseño. 93

Implantando directrices corporativas.. 96

Formando a los desarrolladores. 96

Reconvertir el contenido actual y desarrollar todo el contenido nuevo, de acuerdo con las directrices  96

Revisando la Accesibilidad.. 98

Unidad de revisión. 99

Revisión de conformidad. 99

Revisión de compatibilidad. 99

Revisión con Ayudas Técnicas. 100

Mantenimiento de la accesibilidad.. 100

Introducción a las Intranets.. 101

Sitios en Internet vs. Sitios en Intranet 101

Creando una Intranet accessible. 102

Prioridades en la Intranet 102

Da Pequeños Pasos para obtener Grandes Ganancias en Accesibilidad   103

5. Accesibilidad y Contenido Dinámico.. 105

Definición de Contenido Dinámico.. 105

Un ejemplo de la emulación de navegador en herramientas de verificación   107

Quién debe revisar el Contenido Dinámico.. 109

Aplicaciones con base en la Web.. 109

Caso I – Problemas Comunes con el Contenido Dinámico, vistos en uno de los mayores sitios de comercio electrónico.. 110

Introduciendo la Información del Producto. 110

Vendiendo el producto. 112

Arreglemos el problema. 114

¿Cuándo debe comenzar la empresa de comercio electrónico?  115

Caso de ejemplo II – Proponiendo tu sitio Web a un motor de búsqueda popular   116

6. El significado inadvertido.. 119

Metadatos para la  Accesibilidad.. 119

Una introducción a los metadatos. 119

Metadatos para la Accesibilidad. 120

La estructura de la etiqueta Meta. 121

Eligiendo las etiquetas Meta. 121

Añadiendo etiquetas Meta a los documentos. 123

Escribiendo Textos Equivalentes.. 123

Pistas para escribir textos equivalentes. 124

Evitando textos de enlaces sin sentido. 125

Imágenes y Accesibilidad.. 127

Prácticas comunes pero ERRÓNEAS.. 127

Errores Comunes a Evitar – Textos como Imágenes. 130

Buenas prácticas. 131

7. Tutorial: Corrigiendo Errores de Accesibilidad   134

Usando el tutorial. 135

Sección 1 – Sección 508 (a) Directrices W3C 1.1. 137

1.  Las Imágenes sencillas requieren texto alternativo. 139

2. Misma imagen: también sirve como enlace de navegación  140

3. Una imagen que requiere una descripción larga. 141

4. Objeto hoja de cálculo de MS Office. 142

5. Applet 144

6. Elementos Input (también en 508 (n)) 145

7. Inline Frame (IFRAME) 146

9. Ejemplo de imágenes como viñetas. 148

Sección 2 – Sección 508 (b) Directrices W3C 1.1. 150

Archivos de Audio. 150

Sección 3 – Sección 508 (c) Directrices W3C  2.1. 153

1. Texto coloreado como única manera para determinar un paso requerido  154

2. Campos de formularios requeridos. 156

Sección 4 – Sección 508 (e) Directrices W3C  1.2. 158

1. Proporciona Enlaces redundantes en formato Texto para los Mapas de Imagen del lado del servidor 159

Seción 5 – Sección 508 (g&h) Directrices W3C  5.1 &5.2  160

1. Las Filas y Columnas, deben identificarse en las Tablas de Datos  162

2. Todas las tablas de datos deben tener una leyenda. 164

3. Todas las celdas de encabezado de fila y columna requieren contener el atributo scope  166

4. Todas las celdas de DATOS, requieren contener el atributo header 168

5. Todas las celdas de DATOS, requieren contener el atributo AXIS   170

6. Cuando se usan elementos de agrupamiento, todas las filas requieren estar agrupadas  172

Sección 6 – Sección 508 (i) Directrices W3C  1.1 &12.1  174

1. Todos los elementos Frame, requieren contener el atributo title  176

2. Todos los elementos FRAMESET, requieren contener el elemento noframes  177

Sección 7 – Sección 508 (j) Directrices W3C  7.1. 179

1. No uses el elemento BLINK.. 180

2. No use el elemento MARQUEE.. 181

Sección 8 – Sección 508 (l)&(m) Directrices W3C  6.3  182

1. Si usas el elemento SCRIPT usa el elemento NOSCRITP   184

2. No uses script en elementos ANCHOR.. 185

3. No uses script en elementos AREA.. 186

Sección 9 – Sección 508 (0) 187

1. Enlaces para saltar el menú de navegación. 188

8. Usa Soluciones Accesibles. 190

Normas para Software.. 190

Sección 508. 192

La Plantilla Voluntaria de Accesibilidad de Producto. 192

Salidas del Software. 195

Características soportadas. 195

Comentarios y explicaciones. 196

Introducción a las Normas EITACC para Software   196

Introducción a las Directrices de Accesibilidad de Microsoft  197

9. Recursos de Accesibilidad para Lecturas Posteriores  199

Sección 508. 199

Recursos Web relacionados.. 200

W3C / WAI 201

Soluciones informáticas.. 202

Servicios de Accesibilidad.. 203

Apéndice A. 204

Normas de la Sección 508 y puntos de control de Prioridad Uno del W3C®  205

Apéndice B. 211

Resumen de las normas de la Sección 508 para el software y sistemas operativos. 211

Glosario.. 214

Índice. 218

Registra tu libro.. 220

 

 


INTRODUCCIÓN

Entendiendo la Accesibilidad: Una Guía para Lograr Conformidad en Sitios Web e Intranets, está diseñada para ser una completa guía para crear sitios Web, que consigan la conformidad con las normas federales de Estados Unidos para la accesibilidad del contenido Web, delineadas en el Rehabilitation Act Amendments de 1998, Sección 508, Subsección B, §1194.22.   Adicionalmente, esta guía puede ayudarte a asegurarte de que tus documentos con base en la Web, cumplen con los estándares de accesibilidad del World Wide Web, o W3C®. En este libro encontrarás:

 

 

Este libro es para Autores Web, Gerentes de Proyectos y básicamente cualquier individuo o equipo que se enfrente con el desafío de crear un sitio Web accesible, o modificar un sitio Web, para hacerlo accesible. Si la accesibilidad es algo nuevo para ti te sugerimos que comiences por el principio y leas el libro entero. Si estás atareado reparando sitios que no son accesibles, este libro te servirá como referencia y guía.  Si revisas sitios para ver si son accesibles, este libro te ayudará a seleccionar herramientas y a entender los requerimientos de accesibilidad.

 

¿QUÉ HAY EN ESTE LIBRO?

Este libro te introduce en los preliminares de la accesibilidad y sus desafíos. Proporciona una completa referencia sobre reparación de la accesibilidad. A continuación, se detalla cada una de las secciones:

 

Capítulo Uno: Familiarizándose con el problema de la Accesibilidad y sus desafíos

En esta sección, aprenderás sobre las principales organizaciones que desarrollan estándares de accesibilidad y sobre las leyes del gobierno de Estados Unidos, y también, aprenderás sobre los tipos de discapacidad tenidos en cuenta por los requerimientos. El capítulo Uno, también te guía hacia diversos recursos que pueden proporcionarle ayuda a tu organización y pueden proporcionarte la justificación de, por qué debe construir su sitio Web de forma accesible.

 

Capítulo dos: Los puntos de control y su significado

En esta sección, aprenderás qué es cada uno de los puntos de control, cuál es el objetivo de los puntos de control, e información sobre cómo observar su cumplimiento satisfactoriamente.

 

Capítulo Tres: Introducción a la revisión de la Accesibilidad

Esta sección, te introducirá en la tarea de revisar la accesibilidad de páginas Web y de sitios Web enteros. Además, te introducirá en el conocimiento de herramientas de revisión, reparación y seguimiento. Discutiremos brevemente sobre los sistemas de gestión de contenido y arquitecturas de revisión existentes.

 

Capítulo Cuatro: Desarrollando una estrategia para la conformidad con la Accesibilidad

En esta sección, aprenderás cómo definir requisitos de formación, como parte de una valoración inicial de la accesibilidad de un sitio.

 

 

Capítulo Cinco: Accesibilidad y Contenido Dinámico

Esta sección, te introducirá en la relación entre el contenido dinámico y el trabajo para hacerlo accesible. Esta sección incluirá, también, dos ejemplos para demostrar problemas de accesibilidad con el contenido dinámico.

 

Capítulo Seis: El significado inadvertido

Este capítulo, cubre tres métodos distintos para proveer un sitio más útil, para aquellos que tienen una limitación tecnológica, o una discapacidad que les impide ver el componente visual de su sitio Web.

 

Metadatos para la accesibilidad

En esta sección, aprenderás cómo usar metadatos para incrementar la accesibilidad de tu sitio Web.

 

Escribiendo textos alternativos

En esta sección, aprenderás las mejores y peores prácticas, para crear textos alternativos para los objetos gráficos en tu página Web.

 

Imágenes y accesibilidad

En esta sección, aprenderás cómo asignar con propiedad textos alternativos a las imágenes y por qué. Además, expondremos algunas prácticas comunes, pero defectuosas, para asignar texto alternativo a las imágenes.

 

Capítulo Siete: Tutorial: Corrigiendo Errores de Accesibilidad

Esta sección, consiste en una extensa guía y tutorial. Este capítulo, contiene completos ejemplos y una serie de archivos de demostración, que serán inestimables ayudándote a comprender el marcado de la accesibilidad.

 

Capítulo Ocho: Uso de soluciones accesibles

En esta sección, aprenderás sobre los requerimientos de accesibilidad para el software, de acuerdo con las normas de accesibilidad de Estados Unidos. También, te introducirá en el uso de la “Voluntary Product Accessibility Template, (“VPAT”)”.

 

Capítulo Nueve: Recursos de Accesibilidad y otras lecturas

Esta sección, te proporciona información adicional y recursos.

 

MÁS SOBRE ESTE LIBRO Y LA ACCESIBILIDAD

Este libro fue publicado originalmente por HiSoftware, para complementar una serie de programas de solución de la accesibilidad, incluyendo AccMonitor, AccRepair, y AccVerify. Estas soluciones de HiSoftware ofrecen tecnología de verificación y reparación, que ayuda a los usuarios a identificar y corregir elementos Web, para que sean conformes con los estándares de accesibilidad. Independientemente de, si tu organización está obligada a cumplir con la normativa federal para la accesibilidad o no, lograr la accesibilidad beneficia a todos.

 

Cuando te embarques en una misión para lograr la accesibilidad, asegúrate de hacer referencia al documento en el que las Normas 508 han sido publicadas, Electronic Information Technology Accessibility Standards; Final Rule. Este documento, debe leerse e interpretarse como la base para la revisión continuada de las normas de accesibilidad. Considera, también, poner en práctica las recomendaciones del W3C®. Aunque la ley no ordena obedecer  estas recomendaciones, la puesta en práctica de estos estándares, incrementará el alcance global de tu contenido Web, así como la usabilidad de ese contenido, para todos.


1. Familiarizándote con los problemas de Accesibilidad y sus desafíos

Divider

 

En este capítulo

 

·        Introducción a qué significa la accesibilidad y el acceso a la información en Internet, para las personas con discapacidad.

·        Reglamentación Federal de los Estados Unido, para la accesibilidad.

·        Cómo comenzar la tarea de crear contenido accesible para Internet.

 

Divider

 

Desde que Internet fue fundada, se ha convertido en una manera sencilla de publicar y localizar información.

De acuerdo con el American Heritage Dictionary, algo es accesible cuando puede ser “obtenido fácilmente”[1],  Cuando la información en la Web es accesible, todo el mundo pude encontrarla y usarla.

 

Hoy en día la accesibilidad para el contenido Web, tiene dos significados:

 

La información es accesible, cuando cumple con la normativa Federal de Estados Unidos para el contenido Web. Desde el 25 de junio de 2001, los sitios Web y redes, mantenidas por un organismo federal, están obligados a cumplir con esas normas de accesibilidad.

 

La información, también es accesible cuando logra el más alto nivel de usabilidad. Además de la normativa federal, existen más recomendaciones, que nos ayudan a todos, a encontrar y usar información en la Web. Para obtener más información, contacte con el  W3C® o visite  http://www.w3.org/WAI.

 

En este libro, se introducen los problemas de accesibilidad y se dan consejos y técnicas para cumplir con las normas de accesibilidad.

Personas con discapacidad y el acceso a la información en la Web

Según el informe de 1997 del Censo de Estados Unidos, realizado por el US Census Bureau, una persona de cada cinco tiene algún tipo de discapacidad reconocida legalmente.  (Fuente: Informe del Censo de diciembre de 1997,  “Disabilities Affect One-Fifth of all Americans,” disponible en www.census.gov/prod/3/97/pubs/cenbr975.pdf).   Las personas afectadas por estas discapacidades, pueden necesitar ayudas técnicas para acceder a la información en la Web. La mayoría de las personas, usan un navegador como Microsoft® Internet Explorer™ o Netscape® Navigator™, para ver la información que hay en la Web. Pero debido a que los navegadores comunes no se adaptan a las necesidades de todas las personas, algunas personas usan ayudas técnicas junto con su navegador. Las ayudas técnicas, funcionan en conjunción con los navegadores, permitiendo a los usuarios con discapacidad acceder a la información en la Web. Por ejemplo, si eres ciego, necesitas usar un lector de pantalla. El lector de pantalla, un programa informático, no sólo lee en voz alta el cuerpo de texto en una página, sino que también describe los elementos Web, tales como las imágenes. Sin embargo, para que un lector de pantalla describa imágenes, y otros elementos Web, el HTML u otro lenguaje de marcado, usado para codificar la página, debe hacer que esta información esté disponible para el lector de pantalla.  

 

Cuando un lector de pantalla encuentra una imagen en un documento Web, no pude describir la imagen al usuario, a menos que, el autor del documento la haya provisto de texto alternativo. El texto alternativo, algunas veces creado en HTML utilizando el “atributo alt”, proporciona al lector de pantalla una descripción de la imagen. Si una imagen en un documento Web, consiste en un círculo rojo y blanco y el texto alternativo es “diana”, el lector de pantalla puede decirle al usuario que hay una diana en el documento Web. Cuando no está presente el texto alternativo en la información no textual, el lector de pantalla no puede  proporcionar información que ayude al usuario.

 

Algunos autores Web, utilizan animaciones y sonidos para transmitir información. Estos elementos y técnicas Web, tienen problemas similares de acceso para usuarios con discapacidad. Alguien con una deficiencia visual o dificultad para oír, no puede obtener información útil de una presentación basada en el audio sin una descripción en texto. Una descripción en formato texto, para una animación, pude ayudar a un usuario con deficiencia visual, de la misma manera que una descripción en formato texto para un sonido, puede ayudar a un usuario con deficiencia auditiva. Las descripciones en texto para los sonidos, son similares al subtitulado para televisión. 

 

Además de los estándares de accesibilidad para las imágenes y los elementos multimedia, hay estándares que permiten a los usuarios ver y usar fácilmente, las páginas, incluso cuando sus navegadores y ayudas técnicas no soportan opciones de presentación.

 

Antes de las leyes sobre accesibilidad, mucho sitios Web no eran compatibles con las ayudas técnicas. Este déficit, dejaba a una amplia población de usuarios incapaces de acceder a la información en la Web. Las leyes de accesibilidad, garantizan que todo el mundo pueda encontrar y usar la misma información.

 

Discapacidades atendidas por los Estándares de Accesibilidad

Si tuvieras que preguntar a alguien en tu empresa, qué es un sitio Web accesible, probablemente ellos te responderían que es uno que puede ser usado por una persona ciega. De hecho, un sitio Web accesible, ayuda a hacer que la información del sitio sea accesible para una persona ciega, a la vez que también, habilita a otras personas con varios tipos de discapacidad para acceder a ella.

 

 

Algunas discapacidades comunes:

 

 

Si echas un vistazo a la lista de las posibles discapacidades, atendidas por los estándares de accesibilidad, puedes obtener un mayor conocimiento del alcance de los estándares y de su importancia. La siguiente, es una lista de discapacidades, los problemas comunes que presentan y/o las soluciones que pueden darse a los problemas de acceso:

 

CEGUERA

Software que lee el contenido en voz alta o soluciones que traducen el contenido a Braille.

CEGUERA AL COLOR

El sitio debe desarrollarse para no depender del color

 

BAJA VISIÓN

Los usuarios con baja o débil visión, usarán programas navegadores o programas de ampliación para corregir la discapacidad

 

SORDERA O DEFICIENCIA AUDITIVA

Confían en que habrá subtitulado o transcripciones en formato texto, del contenido auditivo

 

DEFICIENCIA MOTORA, INCAPAcidad para USAR EL TECLADO Y/O EL RATÓN

Las personas que no usan ratón, confían en los atajos de teclado o en dispositivos apuntadores, sostenidos con la boca u otras partes del cuerpo

Adicionalmente, las interfaces por voz proporcionan una solución potencial.

 

EPILEPSIA FOTOSENSIBLE

Las personas con esta discapacidad, pueden tener un ataque provocado por el movimiento, parpadeo o animación, en la pantalla del ordenador, lo cual no es acorde con la norma.

 

 

Mejorando la Web para todos

Desde el comienzo de la “Era de la información”, la tecnología ha venido desarrollándose rápidamente. Los dibujos animados en televisión desde las pasadas décadas, como Los Supersónicos (The Jetsons), presentaban personas paseándose con teléfonos sin cables, y usando sus relojes de pulsera como ordenadores. Hoy en día esto es una realidad – los ordenadores ahora son portátiles y las pantallas de los dispositivos son cada vez más pequeñas.  Los ordenadores de mano son comunes. La gente está usando pequeños dispositivos para descargar su correo electrónico, saber cómo va la bolsa, encontrar indicaciones cuando conducen, y comunicarse con sus amigos y parientes. Estas situaciones son cada vez más comunes y los proveedores de tecnología, ya no presuponen que la mayoría de la gente usa un ordenador de sobremesa, con un teclado y un dispositivo apuntador para navegar por la Web. La legislación sobre accesibilidad está haciendo que la información con base en la Web, sea más fácil de usar para todos los usuarios.

 

Cumpliendo con los estándares, no solo se ayuda a los usuarios de ayudas técnicas, sino que también puede mejorar el acceso a la Web para esos dispositivos de mano y sin cables. Estas leyes se basan en las mejores prácticas de autoría Web y de tecnología de la información. En tanto que muchas de las leyes, benefician directamente a los usuarios con discapacidad, quienes deben depender de las ayudas técnicas para ver la información, estas leyes también benefician a todos los demás. 

 

La industria y el futuro de la tecnología accesible

El futuro de la accesibilidad Web se presenta optimista. Desde que las leyes federales de accesibilidad han sido adoptadas, las empresas de tecnología han declarado públicamente su compromiso con estas normas, incluso, a pesar de que no están obligadas por ley a hacerlo. Es más, los directivos de empresas de tecnología, están colaborando con sus ideas visionarias, para la accesibilidad, que van más allá de los requerimientos legales. Los líderes de la industria, han comprendido que el poder de Internet estriba en su capacidad para dispensar información para todo el mundo.

 

Nadie sabe con certeza cómo será posible la accesibilidad en el futuro. Quizás tomará la forma de un navegador dinámico, de manera que los usuarios no necesiten más de las ayudas técnicas. O quizás el software de autoría para la Web del futuro, compensará los actuales déficit de la información con base en la Web. Pero hasta que la tecnología dominante permita a todos los usuarios el acceso a la misma información, los autores Web deben proporcionarla en el código fuente de sus documentos Web, de manera que la información Web pueda ser procesada por las ayudas técnicas. Esta guía puede ayudarte a hacerlo.

 

Reglamentación Federal para contenido Web accesible

La reglamentación federal que influye en el contenido Web accesible, surge como resultado de The Rehabilitation Act Amendments of 1998, que incluye The Workforce Investment Act of 1998 y que proviene de The Rehabilitation Act of 1973.

 

La Sección 508 contiene normas para la tecnología de la información. Estas normas, han sido promulgadas en la publicación S-40, Electronic Information Technology Accessibility Standards; Final Rule. Este documento establece que, “cuando los organismos federales desarrollen, adquieran, mantengan, o usen tecnología electrónica y de la información, deberán garantizar que la tecnología electrónica y de la información, permitirá el acceso a los empleados federales con discapacidad, y el uso de la información y de los datos, por parte de los empleados federales que no son individuos con discapacidad, a menos que signifique una carga excesiva[2] impuesta al organismo.”[3]

 

La Sección 508, trata de la accesibilidad para las tecnologías electrónicas y de la información. En la Sección 508 hay varias subsecciones:

 

 

 

 

 

Resumen de la Subsección B

La subsección B contiene §1194.22, la sección que trata de las normas para las aplicaciones y la información con base en la Web, de intranets y de Internet.

 

La Subsección B – Normas Técnicas en su integridad, contiene las siguientes subsecciones:

 

§1194.21 Aplicaciones de software y Sistemas Operativos[4]

§1194.22 Aplicaciones e información Web para intranets e Internet

§1194.23 Productos para Telecomunicaciones

§1194.24 Productos para Vídeo y Multimedia

§1194.25 Productos autónomos y reservados

§1194.26 Ordenadores portátiles y de sobremesa

 

Solicita una copia de la Sección 508

Para conseguir una copia de la publicación S-40 Electronic Information Technology Accessibility Standards; Final Rule, contacta con la línea automatizada de solicitud de publicaciones de la Access Board. Marca el  (800) 872-2253, presiona el 2 en el teclado del teléfono, y luego presiona el 1. Solicita la publicación S-40, Electronic Information Technology Accessibility Standards; Final Rule.

 

Si usas un teléfono de texto, llama al +1- (800) 993-2822. Graba tu nombre, dirección y el número de teléfono de la persona que solicita la publicación S-40, Electronic Information Technology Accessibility Standards; Final Rule.

 

Hay copias disponibles en formatos alternativos, incluyendo cintas de casete, braille, fuentes grandes, o disquetes de ordenador.

 

La publicación también está disponible en Internet en:

http://www.access-board.gov/sec508/508standards.htm

Directrices de accesibilidad para el contenido Web del W3C

El grupo de iniciativa de accesibilidad del W3Câ (WAI), persigue la accesibilidad de la Web a través de 5 áreas de trabajo principales:

 

 

Para más información sobre el W3C visite su sitio Web en:

http://www.w3.org/WAI/

 

Ahí encontrará noticias sobre accesibilidad y toda la información relativa a la accesibilidad Web, estándares, y el trabajo disponible del grupo de Accesibilidad del W3C.

 

¿Cuándo entran en vigor las leyes de accesibilidad?

La Sección 508, exige que los sitios Web mantenidos por organismos federales y sus intranets, estén en conformidad con las normas desde el 25 de junio de 2001. Si no estás seguro de si tu organización se ve afectada por la ley, para cumplir con las normas de accesibilidad, contacta con la Comisión de Acceso, o visita la página http://www.access-board.gov.

 

Por dónde comenzar

Conoce las leyes de accesibilidad.

Obtén una copia de la publicación S-40, Electronic Information Technology Accessibility Standards; Final Rule, y familiarízate con ella. Esta guía, también ayuda explicando las leyes relativas al contenido Web de Internet e intranets.

 

Otro documento de la Comisión Acceso, proporciona técnicas específicas sobre cómo puede cumplir las normas de accesibilidad. Visita http://www.access-board.gov/ sec508/guide/1194.22.htm para obtener más información.

Encuentra recursos fidedignos.

Hay muchos recursos disponibles para ayudarte a desarrollar contenido Web accesible. La Access Board, la organización que dispone las leyes federales de accesibilidad, ofrece apoyo técnico e información adicional sobre accesibilidad. Visita http://www.access-board.gov/ sec508/guide/1194.22.htm para obtener más información.

 

Considera también el W3C®, Trace Research & Development Center, National Center for Accessible Media, y el National Arts and Disability Center. Contacta directamente con estas organizaciones, o visita sus sitios Web para obtener más información.

Mantente informado.

Es importante mantenerse informado, por varias razones:

·           Como la tecnología se desarrolla, con certeza, los estándares de accesibilidad cambian.

·           Frecuentemente se publican nuevas técnicas para crear contenido Web accesible.

·           Como los desarrolladores incrementan la capacidad de los navegadores y de los lenguajes de marcado para los documentos Web, lograr la accesibilidad será cada vez más fácil.

Considera usar software automatizado.

En el mercado hay muchas soluciones de software, para ayudarte a verificar y lograr el cumplimiento de las leyes de accesibilidad. HiSoftware tiene una serie de soluciones para satisfacer tus necesidades específicas. Las soluciones de HiSoftware, cumplen con las leyes de accesibilidad para las aplicaciones informáticas.[5]. Visita http://www.hisoftware.com, o llama al +1- (603) 229-3055 para obtener más información.

¿Quién puede ayudarte?

La Access Board, proporciona ayuda técnica en cuanto a la aplicación de las normas de la Sección 508.

 

La Access Board, proporciona documentación en línea para ayudarte a comenzar. Visita http://www.access-board.gov/sec508/guide/1194.22.htm para obtener más información. O contacta con el servicio de soporte de la Access Board.

 

 

Access Board

Oficina Técnica y Servicios de Información

1331 F Street, NW, Suite 1000

Washington, DC 20004-1111

Tel.: (800) 872-2253 o (800) 993-2822 (TTY), días laborables de 10:00-17:30 EST (Miércoles, 10:00–14:00)

Fax: (202) 272-5447

Web: http://www.access-board.gov

E-mail: 508@access-board.gov


Creando Contenido Web Accesible

Las leyes de accesibilidad han sido promulgadas en la publicación S-40, Electronic Information Technology Accessibility Standards; Final Rule.

 

Las normas que aparecen en este libro, han sido interpretadas desde el documento original. Para leer las normas en el documento original, solicita una copia de la publicación S-40, Electronic Information Technology Accessibility Standards; Final Rule.

La Sección 508, en la Subsección B, §1194.22, explica las normas de accesibilidad para las aplicaciones e información con base en la Web, de intranets e Internet.

 

Diferencias entre la Sección 508 y el W3C

Las Normas de la Sección 508, que se presentaron como norma para el desarrollo de los sitios Web de la administración Federal de Estados Unidos, son una extensión y/o modificación de las Directrices de Accesibilidad del W3C. En el apéndice de este libro, hay una tabla comparativa de las normas del W3C y de la 508. Las diferencias entre estas dos normas son mínimas. 

 

En resumen, se puede decir con seguridad que, si tu intención es desarrollar un sitio con el objetivo de que sea accesible, entonces puedes seguir las normas de Prioridad Uno del W3C o las Normas de la Sección 508. Seguir ambas normas es también sencillo, una vez que has tomado la decisión de crear un sitio Web accesible.

 

¿Por qué debes construir de forma accesible?

A menudo los desarrolladores preguntan: “¿Por qué debe ser accesible nuestro sitio?” Independientemente de cualquier exigencia legal o estatutaria, la respuesta e esta pregunta es simple: ofrecer igual acceso a los usuarios con discapacidad es una cuestión apremiante por muchas razones:

 

 

Es difícil imaginar, por qué alguien puede no querer contar con un sitio Web accesible. La información y las ideas expresadas en este libro, demostrarán que no es difícil conseguir y mantener un sitio Web accesible. El resto de este capítulo, trata sobre cómo hacer tu contenido accesible. Se proporcionan ejemplos completos como parte de las descripciones.

 

Una versión del contenido

Es muy importante formar, a tu equipo Web, en contenido Web accesible. Un frecuente “malentendido” sobre conformidad con la accesibilidad, se refiere al uso de una segunda versión del contenido desarrollada como una versión solo-texto del sitio. Algunos diseñadores han dicho que una segunda versión del contenido, proporcionada como un sitio solo-texto, será una forma aceptable de reemplazar la creación de un sitio accesible.

 

Esto, simplemente no puede ser verdad y vence el espíritu que hay detrás de los años de trabajo e investigación, para hacer la información electrónica accesible para todos en igual forma y contenido. Una página toda texto, no puede transmitir el verdadero significado del contenido, a menos que el contenido sea, por defecto, solo texto por las siguientes razones:

 

 

Hazte a ti mismo una simple pregunta:

 

Si yo creo una página todo texto, que realmente contiene el mismo contenido que la página principal, ¿satisfará los requerimientos de accesibilidad, de todas las personas con discapacidades que potencialmente pueden estar viendo el sitio?

 

 

 

Respuesta: Incluso si fueras capaz de cubrir todos estos problemas en tu versión solo-texto del sitio Web, desde una perspectiva de gestión, ahora tendrás que ocuparte de la sincronización, actualización, y mantenimiento de dos versiones del mismo sitio. ¡Cuando se trata de la cuestión de la accesibilidad, es más económico hacer una versión del contenido que sea accesible para todos!.

 

Por qué el texto sÓlo no es manejable

Desde otra perspectiva, el texto sólo, puede ser una pesadilla para la gestión. La meta es distribuir contenido con exacto significado, para todos los usuarios, en todo momento. Las páginas con solo texto se crean de varias maneras:

 

automáticamente

Este es probablemente el mejor método, aunque hay una alta probabilidad de que algunos datos no se trasladen, lo que significa que el contenido no será el mismo. La traducción automática de un sitio Web en un sitio solo-texto, encontrará las mismas limitaciones que encaran las ayudas técnicas – sólo pueden trabajar con información que tiene ya el texto equivalente, tras los elementos no textuales.

 

Manualmente

Este método puede consumir mucho tiempo, no solo durante la creación, sino también desde la perspectiva del mantenimiento. El hacer un simple cambio en una página, significa que tendrás que recordar actualizar la página de texto. Hay una alta probabilidad de que las páginas no estén sincronizadas, tras varias actualizaciones.

 

SISTEMAS DE GESTIÓN DE CONTENIDO

Los sistemas de gestión de contenido, encontrarán los mismos desafíos descritos en el ejemplo de arriba para la traducción automática. Porque una simple traducción no es igual, la mejor manera de manejar esto, es crear plantillas y código accesibles desde el principio, versus intentar proponer una alternativa al contenido de solo texto, con significado equivalente.

 

Ahora, si la versión sólo texto es la única vía que encuentras, puedes hacerlo – solo recuerda los desafíos:

 

 


2. Los puntos de control y su significado

 

Divider

 

En este capítulo

 

·        Introducción a la Sección 508 y a las Directrices del W3C

·        Detalle de las discapacidades tratadas por cada punto de control

·        Resumen de cómo verificar cada punto de control

 

Divider

 

Las normas de la Sección 508 y la Prioridad Uno de las Directrices del W3C son muy similares, con sutiles diferencias. En este capítulo trataremos los puntos de control de la sección 508 y su significado.

 

Véase el Apéndice A, para obtener un resumen completo de la Sección 1194.22 vs. W3C Prioridad Uno. Esta comparativa, les permitirá a los desarrolladores usar la siguiente información, independientemente de las normas a cumplir con las que ellos estén desarrollando su sitio.

 

Este capítulo, proporciona una visión general conceptual de los requisitos de accesibilidad, detallando ambos, porque son importantes, y proporcionando una visión general de cómo corregir los problemas de accesibilidad. Para tener una referencia completa del lenguaje de marcado HTML para el diseño accesible, por favor, ve al Capítulo 7 en el que encontrarás el “Tutorial” y los Ejemplos en HTML.

Entendiendo el Párrafo (a) / W3C P1 (1.1)

(a) Debe proporcionarse un texto equivalente para todos los elementos no textuales.

 

Un texto equivalente, transmite la misma información al usuario que el elemento original no textual. Las pautas de la sección 508, apuntan los siguientes elementos, como ejemplos de elementos que requieren equivalentes en texto.

 

 

W3C vs. 508 especial

La pauta del W3C correspondiente, 1.1, incluye otros elementos, no especificados en la Sección 508 (a), que sin embargo están incluidos en las directrices federales.

 

 

Estos, están cubiertos más adelante en la 508, en otras secciones como la (n) y son requeridos, pero no están mencionados explícitamente en el párrafo (a).

 

discapacidades cubiertas por este párrafo

Las siguientes discapacidades son tratadas por este párrafo:

 

 

 

TRABAJANDO con elementos no textuales

El capítulo 6 de este libro, detalla cómo escribir texto equivalente. Los puntos  más importantes a recordar son:

 

 

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (a)

Es fácil probar la conformidad de tu página con el párrafo (a). Las herramientas de revisión, tales como HiSoftware’s AccVerify, pueden revisar rápidamente una página o un sitio entero.


 

Entendiendo el Párrafo (b) / W3C P1 (1.4)

(b) Los equivalentes alternativos para cualquier presentación multimedia, deberán estar sincronizados con la presentación. 

 

discapacidades atendidas por este párrafo

Las siguientes discapacidades son tratadas por este párrafo:

 

TRABAJANDO con alternativas para contenido multimedia

Una presentación en video, con un componente de audio, requiere subtitulado. El subtitulado debe estar completamente sincronizado con el audio, para permitir a quienes lo ven seguir el significado del contenido.

 

Si se trata solo de un componente en formato audio, no hay necesidad de subtítulos, sin embargo, “debe” estar disponible un equivalente textual (la trascripción completa).

 

Si hay una presentación de transparencias como, por ejemplo, una presentación en PowerPoint pero es “solo visual”, los gráficos necesitan tener una representación en texto alternativo.

 

ejemplos y consejos para las presentaciones powerpoint

Quienes proporcionan presentaciones sin sonido en Microsoft PowerPoint, a través de Internet, deben recordar proporcionar texto alternativo para sus imágenes. En PowerPoint 2000 y superior, puedes hacerlo siguiendo los siguientes pasos:

 

  1. Selecciona la imagen que necesita el texto alternativo
  2. Selecciona el menú Formato | Imagen...
  3. Selecciona la pestaña “Web”
  4. Escribe el texto alternativo en el cuadro de diálogo
  5. Haz clic en Aceptar

 

 

REVISANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (b)

Este es un punto de control visual. Cuando los desarrolladores de contenido distribuyen contenido multimedia, deben asegurarse de que están cumpliendo con el párrafo (b)



Comprendiendo el Párrafo (c) / W3C P1 (2.1)

(c) Las páginas Web deberán diseñarse de manera, que toda la información transmitida con el color esté también disponible sin color.

 

discapacidades cubiertas por este párrafo

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO con el color

El uso del color, no impide que una página cumpla los requerimientos de accesibilidad. Un diseñador novel puede creer que este es el caso, es importante que los diseñadores entiendan que, pueden usar color y estar cumpliendo con las normas de accesibilidad. Este párrafo (punto de control), trata del uso del color para indicar acción o significado.

 

Notas sobre el color

No representes el énfasis de una palabra sólo con el color. Por ejemplo, no crees un formulario que requiera que, los usuarios rellenen todos los campos cuyos valores están “marcados en rojo”. Usa el marcado de HTML <Strong> o <EM>.  En una imagen para indicar una acción, no uses sólo el color.

 

Ejemplo: No digas: “Presione el botón rojo para cancelar su pedido o el verde para continuar”. Definitivamente, el color puede ser usado para mejorar el diseño de un formulario, pero usa el texto alternativo y/o texto en las imágenes, para significar cancelar y terminar.

 

probando la conformidad de tus páginas con el párrafo (c)

Es fácil probar la conformidad de tus páginas con el párrafo (c). Esta revisión es claramente una revisión visual y puede complementarse probando cómo aparecería, en un dispositivo de salida en blanco y negro.

 

Impresora

Imprime tu página Web en una impresora de blanco y Negro. Fíjate en que todos los textos e imágenes sigan siendo visibles y que el énfasis requerido sigue siendo visible.

 

Pantalla

Mira tu página en un monitor en blanco y Negro, o ajusta tu monitor a la vista antedicha y mira la pantalla, para asegurarte de que el color no es la única vía en que la información se ha presentado.


Comprendiendo el Párrafo (d) / W3C P1 (6.1)

(d) Los documentos deberán estar organizados de manera que, sean legibles sin requerir una hoja de estilos asociada.

 

discapacidades cubiertas por este párrafo

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON HOJAS DE ESTILO

Las Hojas de Estilo, han sido pensadas para separar la presentación del contenido. Proporcionan una manera sencilla y eficaz de dar formato a los documentos HTML. Las hojas de estilo, refuerzan la efectividad del HTML, así como simplifican el mantenimiento de un sitio Web. Además, el uso de las hojas de estilo, capacita a los usuarios para ajustar sus preferencias de visión y acomodarlas a sus discapacidades.

 

Con esto en mente, es importante que un desarrollador de un sitio Web, no diseñe una página que interfiera con las hojas de estilo definidas  por los usuarios.

 

probando la conformidad de tu página con el párrafo (d)

Es fácil probar la conformidad de tu página con el párrafo (d). Simplemente, deshabilita el soporte de hojas de estilo, toda la información y su significado deberán seguir estando presentes sin las hojas de estilo. Además, puedes probar con una hoja de estilo definida por un usuario, para asegurarte de que no interfiere con la capacidad para entender y navegar por el sitio.


Comprendiendo los párrafos (e) & (f) / W3C P1 (1.2) & (9.1)

(e) Deben proporcionarse enlaces en formato texto, redundantes con cada región activa de un mapa de imagen de tipo servidor. 

 

(f) Deben proporcionarse mapas de imagen de tipo cliente, en vez de los dependientes del servidor, excepto cuando las regiones no puedan ser definidas con una forma geométrica disponible. 

 

DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON MAPAS DE IMAGEN

Un mapa de imagen, es una imagen única que se usa para ofrecer múltiples enlaces al contenido en un sitio Web. ¡Rara vez los mapas de imagen son realmente mapas! Cuando un usuario selecciona un enlace en un mapa de imagen, éste le lleva al enlace conectado con la parte de la imagen referida.

 

Hay dos tipos de mapas de imagen, de tipo cliente y del lado del servidor. La diferencia principal entre los dos es, dónde se traduce el procesamiento real de la acción de un visitante en el mapa.

 

La norma del párrafo (e) es necesaria, ya que el enlace real es procesado en el servidor, de manera que no está disponible para el usuario de ayudas técnicas, debido a su incapacidad para ver el mapa. Proporcionándole al usuario una lista de enlaces, el mapa se hace accesible.

 

La norma del párrafo (f) es necesaria, debido a que permite al usuario de ayudas técnicas, activar fácilmente regiones del mapa de imagen. Norma relacionada: Párrafo (a)

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (e) Y (f)

Es fácil probar la conformidad de tu página con el párrafo (e) & (f). AccVerify puede revisar rápidamente una página o un sitio entero.


Comprendiendo los párrafos (g) y (h) / W3C P1 (5.1) y (5.2)

(g) En las tablas de datos, los encabezados de las filas y columnas deben estar identificados.

(h) Debe utilizarse marcado para asociar las celdas, de datos y encabezados de celda en las tablas de datos que tienen dos o más niveles lógicos de encabezados de fila o columna.

 

DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON TABLAS

 

Las tablas pueden ser usadas para el diseño/maquetación, o como medio de presentar datos. Las tablas que se usan para presentar datos, deben estar estructuradas de manera que aquellos usuarios que no pueden ver los datos, con sus puntos de referencia visual, puedan navegarlos fácilmente. La estructura de estas tablas, implica significado para la información que hay dentro de ellas, basado en la organización de la tabla. Por tanto, un lector de pantalla debe ser capaz de utilizar esa estructura de tabla.

 

HACIENDO ACCESIBLE UNA TABLA

Los siguientes pasos, han sido diseñados para habilitar a los usuarios de ayudas técnicas a comprender y navegar por las tablas con éxito.

 

1.      Determina el Tipo de Tabla (Si se trata de una tabla para disponer el contenido (maquetación) en vez de una tabla de datos, entonces, no necesitas hacer más. *Nota: los desarrolladores deben asegurarse de que las tablas usadas para maquetar, tienen sentido cuando se linearizan.)

 

2.      Para las tablas de datos, primero escriba el resumen:

El atributo summary, permite a los desarrolladores proporcionar un resumen de la información en las tablas.

 

Los lectores de pantalla, pueden sacar partido de este atributo no-visual (no aparece en la página cuando es vista con un navegador).

 

El resumen debe proporcionar al visitante de la página:

·        Resumen de la tabla

·        Resumen de los contenidos de la tabla

·        Resumen de la estructura

·        Resumen del propósito de la tabla

 

Opcionalmente, el desarrollador puede usar la etiqueta “Caption”.

La leyenda, aparece como parte del texto del documento en una página que tiene una tabla. La etiqueta “Caption” es visible en las páginas Web.

 

  1. En la tabla, hay celdas que sirven como encabezados, o etiquetas para la información en la respectiva fila o columna. Los encabezados, deben estar identificados como celdas de encabezado. En este paso, de la creación de una tabla accesible, es necesario colocar celdas de encabezado en la tabla, y por tanto, cambiar la etiqueta TD por una etiqueta TH.

 

4.      Identifica los encabezados de Filas y Columnas

 

Tablas sencillas – considera identificar los encabezados de fila y columna con el atributo “scope”.

 

Tablas complejas – considera identificar los encabezados de fila y columna con los atributos de encabezado. Si la tabla tiene más de una fila o más de una columna de celdas de encabezamiento, considera usar el atributo “axis” para agruparlas.

 

 

  1. Agrupa varios encabezados de fila o de columna. Cuando las celdas de encabezado están identificadas claramente, el significado de las celdas de datos es fácilmente identificable.

 

PROBANDO LA CONFORMIDAD DE SU PÁGINA CON EL PÁRRAFO (G) & (H)

Es fácil probar la conformidad de tu página con el párrafo (g) y (h). AccVerify puede revisar rápidamente tu página Web o tu sitio entero. Recuerda que una herramienta que puede filtrar las tablas usadas para maquetar, ofrecerá una aproximación simplificada a la revisión de la accesibilidad de las tablas.


Comprendiendo el Párrafo (i) / W3C P1 (12.1)

(i) Los marcos, deben titularse con un texto que facilite su identificación y navegación.

 

DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON MARCOS

Un sitio con marcos, utiliza una combinación de documentos HTML, que se presentan juntos en el navegador, dividiendo la pantalla del ordenador visualmente en distintas y separadas áreas, que pueden ser reformadas por separado, dependiendo de la acción del usuario. Los marcos le crean dificultades a los usuarios con discapacidad, cuando estos marcos no son identificables para las ayudas técnicas. Los usuarios de ayudas técnicas, encontrarán difícil navegar por los marcos, si la diferencia entre ellos no está claramente identificada.

 

Para facilitar una navegación sencilla con marcos, usa el atributo “title”, disponible para el elemento “frame”.

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (i)

Es fácil verificar la conformidad de tu página con el párrafo (I). AccVerify puede revisar rápidamente una página o un sitio entero.


Comprendiendo el Párrafo (j) / W3C P1 (7.1)

(j) Las páginas deben estar diseñadas para evitar provocar que la pantalla parpadee, con una frecuencia mayor de 2 Hz. y menor de 55 Hz. 

 
DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON EL PÁRRAFO (j)

Los desarrolladores deben evitar que la pantalla:

Si la pantalla se comporta de alguna de las maneras enumeradas arriba, puede provocar una ataque a un individuo con la discapacidad citada.

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (j)

Los elementos que destellan o parpadean, deben ser evitados y deben ser identificados por tu herramienta de revisión. Esta es una revisión tanto manual como automática.


Comprendiendo el Párrafo (k) / W3C P1 (11.4)

(k) Una página solo-texto, con equivalente información o funcionalidad, debe proporcionarse para hacer que un sitio Web cumpla con lo previsto en estas normas, cuando la conformidad no puede lograrse de otra manera. El contenido de la página solo-texto, debe actualizarse siempre que cambie la página primaria.

 
DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON PÁGINAS SOLO-TEXTO

El párrafo (k), proporciona una medida de seguridad para las páginas o el contenido, que no pueden hacerse accesibles. Exige que haya una alternativa accesible. A esto, normalmente se le llama una versión “Solo Texto” de una página o sitio Web. Esta alternativa debe evitarse de verdad. El coste de mantener esta solución y la probabilidad de que el contenido quede incompleto, es demasiado alto. Además, la tarea de hacer accesible el contenido Web, o el sitio Web, generalmente no queda fuera del alcance de ninguna organización.

 

Véase el Capítulo uno, para obtener más información sobre las versiones de contenido solo texto.

 

PROBANDO LA CONFORMIDAD DE SU PÁGINA CON EL PÁRRAFO (k)

Esta práctica es costosa de mantener y de revisar. El requerimiento es claro, en cuanto a que el contenido de una página no sólo texto, debe ser idéntico en la versión sólo texto. Cada página de contenido, debe ser revisada para garantizar que está cumpliendo con la norma. Debido a la minuciosa revisión que este método requiere, es absolutamente recomendable que, esta alternativa sea usada sólo cuando no hay manera en absoluto de hacer la página accesible.


Comprendiendo el Párrafo (l) / W3C P1 (partial 6.3)

(l) Cuando las páginas utilizan lenguajes de “scripting” para presentar contenido, o para crear elementos de interfaz, la información proporcionada por esos scripts, deberá estar identificada con texto funcional que pueda ser leído por las ayudas técnicas. 

 

DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON SCRIPS

Todas las URL con JavaScript, deben tener texto significativo, de manera que las personas con discapacidad puedan seguirlas. Los desarrolladores, deben evitar los navegadores de eventos como único método de navegación, o de completarse una página.

 

Manejadores problemáticos:

 

 

Los manejadores de eventos que no requieren una interacción por parte del usuario y que son independientes del tipo de dispositivo, no son problemáticos:

 

 

Recuerda que, todas las funciones creadas con scripts, deben incluir una etiqueta NOSCRIPT, para aquellos navegadores o ayudas técnicas que no soportan scripts.

 

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (l)

Es fácil verificar la conformidad de tu página con el párrafo (l). AccVerify puede revisar rápidamente la conformidad de una página o sitio completo. La identificación de todos los manejadores de evento JavaScript, es una buena forma de comenzar el proceso de evaluación de todo un sitio.


Comprendiendo el Párrafo (m)

(m) Cuando una página Web requiera que un applet, plug-in u otra aplicación esté presente en el sistema cliente, para interpretar el contenido de la página, la página debe proporcionar un enlace a un plug-in o applet, que cumpla con §1194.21(a) pasando por (l). 

 

DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON appletS o plug-ins

Este es uno de los párrafos o puntos de control más complejo, con los que un desarrollador de contenido Web o administrador de un sitio tiene que tratar. La razón de su complejidad, se debe a que se convierte en un problema de verificación de la accesibilidad, tanto de contenido Web como potencialmente de una aplicación informática.

 

La parte sencilla de este párrafo es, que si se requiere un plug-in, objeto, applet o visor; entonces el desarrollador debe proporcionar un enlace a la página, en la que el usuario pueda obtener fácil acceso al componente requerido.

 

NOTA: ¡Si usted tiene un enlace a 30 archivos en formato pdf en su página, no es necesario que coloque 30 enlaces al visor de PDF! Esta es una práctica común e innecesaria.

 

El problema con el cumplimiento de este párrafo es, que los desarrolladores deben asegurarse de que el plug-in requerido sea accesible. El Capítulo ocho de este libro, proporciona más información sobre accesibilidad del software.

 

PROBANDO LA CONFORMIDAD DE SU PÁGINA CON EL PÁRRAFO (m)

Uno debe revisar las normas Web o de software para cualquier applet, objeto o plug-in usado por separado. Verifica con el proveedor del plug-in o del applet/object, el estado de la accesibilidad de sus productos.


Comprendiendo el Párrafo (n)

(n) Cuando los formularios electrónicos están diseñados para ser rellenados on-line, el formulario debe permitir que la gente utilice ayudas técnicas para acceder a la información, campos y funciones requeridas para cumplimentar y enviar el formulario, incluyendo todas las instrucciones e indicaciones. 

 

DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON FORMULARIOS ELECTRÓNICOS

La cosa más importante que hay que recordar cuando se proporcionan formularios electrónicos es, que “DEBES” diseñar el formulario para que sea accesible para lectores de pantalla, simples o sofisticados y para las ayudas técnicas. Esto significa que, para hacer el formulario accesible puede usarse lo siguiente: 

 

 

Estate atento a las soluciones que no funcionan con todos los lectores de pantalla.

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (N)

Es fácil verificar la conformidad de tu página con el párrafo (n). AccVerify puede revisar rápidamente la conformidad de tu página o de un sitio entero.


Comprendiendo el Párrafo (o)

(o) Debe proporcionarse un método, que permita a los usuarios saltar los enlaces de navegación repetitivos. 

 

DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON ENLACES DE NAVEGACIÓN

La mayoría de los sitios, se desarrollan con una estructura. Teniendo una estructura, seguramente tendrás secciones en tu sitio Web, diseñadas específicamente para la navegación dentro de todo el sitio. Una de las formas más sencillas de seguir este párrafo es, poner una señal (un ancla) en donde comienza el contenido y un enlace a ella en la sección de navegación de la página. Esto le permite al usuario, seleccionar el enlace para saltarse el menú e ir directamente al contenido.

 

 

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (o)

Este es un punto de control de revisión visual. Cuando revises si funcionan los enlaces para saltar el menú de navegación, debes revisar visualmente que:

 

 


Comprendiendo el Párrafo (p)

(p) Cuando se requiera una respuesta en un tiempo dado, una contestación cronometrada, el usuario deberá ser alertado y deberá dársele suficiente tiempo para indicar que requiere más tiempo. 

 
DISCAPACIDADES CUBIERTAS POR ESTE PÁRRAFO

Las siguientes discapacidades son tratadas por este párrafo:

 

 

TRABAJANDO CON TIEMPOS DE RESPUESTA

Una contestación cronometrada, se describe mejor como una página que requiera alguna clase de entrada por parte del usuario, basada en un script o código, que sólo le deja al usuario una cantidad determinada de tiempo para llevar a cabo la acción antes de que:

 

 

La culminación de la acción requerida en el tiempo asignado, puede significar una dificultad para el usuario con una discapacidad cubierta por este párrafo y en general por las normas de la Sección 508.

 

Cualquier contenido que requiera una respuesta en un tiempo dado, debe alertar al usuario de que está corriendo el tiempo y permitirle solicitar más tiempo a través de un mensaje del sistema.

 

 

PROBANDO LA CONFORMIDAD DE tU PÁGINA CON EL PÁRRAFO (p)

Esta revisión, debe llevarse a cabo en todas las páginas que exijan un tiempo de respuesta dado, lo que puede ser tanto una revisión visual como automatizada.


3. Introducción a la Revisión de la Accesibilidad

 

Divider

 

En este capítulo

 

·        Introducción a los errores de accesibilidad más comunes

·        Introducción a los programas de revisión de la calidad

·        Introducción a la revisión de la accesibilidad con herramientas informáticas

·        Uso de herramientas de Verificación, Reparación y Seguimiento con explicación de qué pueden y qué no pueden hacer

·        Revisión de la accesibilidad y gestión de contenido / arquitecturas de revisión actuales

 

Divider

 

 

La manera más fácil de garantizar que un sitio Web sea accesible es, aplicar revisiones de accesibilidad a tus prácticas actuales de garantía de calidad para tu sitio Web. Este capítulo, te introduce en los errores más comunes y en el proceso de garantía de calidad.

 

Errores Comunes de la Accesibilidad

Las normas y directrices de accesibilidad, proporcionan una excelente guía para hacer accesible tu sitio. Ya sea que estés siguiendo las directrices de Prioridad Uno del W3C, o las Normas 508, es importante comprender cuales son los errores más comunes que cometen los desarrolladores de sitios Web. Esto es importante desde la perspectiva de la revisión, porque si comprendes los errores más frecuentes, puedes diseñar un plan y metodología de revisión apropiados. Para el propósito de este libro, los errores más comunes están divididos en dos grupos, errores de Diseño y errores por incumplimiento de las Directrices/Normas.

 

Nota:  “Directrices” se refiere a las directrices del W3C/WCAG. Las directrices, son una propuesta y no una norma que los desarrolladores de sitios Web deban seguir si quieren conseguir la accesibilidad. “Normas”, se refiere a la Sección 508 Electronic Information Technology Accessibility Standards; Final Rule. (Las actuales Normas Federales, de los Estados Unidos, que se exige cumplir a los sitios de la administración.)

 

Los errores más comunes de diseño, que impactan en la  accesibilidad de un sitio Web, son: 

 

 

Errores de accesibilidad más comunes, que impiden que un sitio sea utilizado, eficazmente, por personas con discapacidad:

 

o       Objetos

 

Los sitios que puedan manejar los elementos arriba mencionados, se encontrarán cerca de la conformidad o en conformidad con las directrices y normas. Esto tendrá un profundo impacto, en la accesibilidad global, del contenido de Internet.

 

Una introducción a la garantía de calidad

La garantía de calidad para los sitios Web, es una actividad esencial para las empresas u organizaciones que desarrollan contenidos, o aplicaciones Web, que serán usados por otros. Se puede afirmar, con seguridad, que cualquier organización que tiene un sitio Web para uso público o privado, sigue alguna práctica de auditoría de la calidad de su sitio. Estos grupos internos de garantía de calidad, sirven como representantes de los clientes. Cuando lleva a cabo sus tareas, el grupo de garantía de la calidad mira el sitio Web desde la perspectiva de un visitante.

 

Al igual que las revisiones de software, las revisiones de sitios Web comienzan por las normas y requerimientos del producto o sitio Web y su funcionalidad. Esto significa que, si un sitio Web es diseñado inicialmente para cumplir una serie de funciones, o para proporcionar información en un formato específico, entonces, debe cumplir esa tarea tal como está especificado.

 

 

Objetivos de la revisión de un sitio Web:

 

 

 

En el caso de la accesibilidad, habría un plan de revisión en los sitios diseñados, para garantizar la detección efectiva de errores. La tarea de detectar errores no termina con la revisión inicial “básica”. Nosotros debemos, entonces, mirar más allá de los requisitos básicos.

 

Tipos de test que pueden aplicarse a la Revisión de la Accesibilidad de un sitio Web:

 

 

 

 

 

 

 

 

 

Revisando la versión Beta

Uno de los pasos más importantes que podrías dar, es hacer un test de la versión beta. Esto significa revisar tu página o sitio antes de llevarlo a producción. Ya sea la tuya una organización grande o una empresa pequeña, debes tomarte el tiempo para hacerlo. Una vez hayas terminado el desarrollo de tu sitio o página, y una vez que hayas concluido las revisiones de accesibilidad, debes tener la versión beta del producto revisada. 

 

Este proceso, contiene una revisión individual desde el exterior, para ver si la página se desempeña tal como para lo que fue diseñada. Este usuario, no forma parte del equipo desarrollador del producto o sitio y no tiene que ser necesariamente un revisor. Una vez que ha sido probada la versión beta del producto o sitio Web puede, entonces, enviarse a producción.

 

Introducción a la Revisión de la Accesibilidad

Los desarrolladores o auditores de sitios Web, en el punto de control clave en un proceso completo, determinarán mediante test si los objetivos y o requerimientos están siendo cumplidos. La revisión de la accesibilidad (comúnmente llamada verificación) tiene dos componentes principales – visual y automatizada. Para concluir un test o auditoría de contenido con éxito, debes comprender cómo implantar un plan de revisión logrado.

 

Revisión automatizada se realiza tanto con agentes buscadores de sitios Web como con escáneres de archivos. El agente imitará un agente de usuario o navegador, obteniendo el contenido de las páginas Web, y entonces, lleva a cabo una evaluación del contenido, para ver si cumple con las directrices.

 

Revisión Visual se usa para verificar los puntos de control de las directrices que no tienen la estructura o que no pueden ser previstos al pasar por una detección automatizada de fallos.

 

Una Buena solución sería, combinar la revisión visual y la automatizada, requiriendo por tanto una verificación visual, de las páginas en las que haya elementos que exijan una revisión visual. Las organizaciones pequeñas con sitios Web estáticos, encontrarán la tarea de crear un sitio Web accesible relativamente sencilla. Las organizaciones medianas o grandes, encontrarán la tarea un tanto más desafiante.

 

Página versus Sitio

Cuando se revisa el contenido de un sitio, hay dos cuestiones que la empresa debe tener en cuenta. La primera es la creación de contenido. La segunda es el contenido existente en el sitio. Al igual que con cualquier otro esfuerzo de desarrollo, de software o de contenido Web, siempre es menos costoso encontrar y corregir errores antes, que hacerlo en el entorno de producción (cuando realmente han sido publicados). Esto significa que, una empresa necesita llevar a cabo una revisión, tanto en el nivel de la página como en el nivel del sitio.

 

Página

El autor que desarrolla la página real, debe revisar la conformidad con las normas, antes de publicar el contenido. Esta debe ser la parte final de cualquier proceso, que se ocupe de la publicación de contenido electrónico.

 

Sitio

Desde la amplia perspectiva de un sitio, las empresas deben instrumentar servicios desatendidos, tanto hospedados, como situados en sus servidores internos, que constantemente monitoricen sitios o porciones de sitios Web y alerten a los grupos responsables, si existe algún problema que les haga quedar fuera de la conformidad con las normas.

Distribución Avanzada de Contenido

Cada vez es más común, que los sitios Web sean generados dinámicamente, distribuidos a través de gestión de contenido o servidores de publicación. En este caso, hay que considerar un tipo diferente de revisión: revisión de plantillas. Los sitios dinámicos, usan plantillas para distribuir el contenido. En este caso, es importante revisar todas las plantillas antes de llevarlas a producción. 

 

Para saber más sobre Contenido Dinámico y su Accesibilidad véase, por favor, el capitulo 5. El Capítulo cinco trata con detenimiento el Contenido Dinámico y, también, muestra cómo, un error en las plantillas puede crear errores catastróficos de accesibilidad, en tu sitio Web. 

Usando Herramientas

Cada vez es más común, para los Autores/Administradores de sitios Web, implantar el uso de herramientas de verificación, rehabilitación y reparación de la accesibilidad,  para garantizar la accesibilidad del sitio. Estas soluciones, pueden ayudar a disminuir el tiempo de procesamiento de las Tecnologías de la Información y los recursos humanos implicados en el desarrollo de proyectos. Esta sección, tratará sobre los tipos de herramientas disponibles y sobre cómo  debes aplicarlos en tu proceso de revisión.

 

Herramientas de verificación

Una herramienta de verificación de la accesibilidad es, una solución informática o un servicio, que te permite revisar una página, en la que estás trabajando, o un grupo de páginas de un sitio Web (Lógico o Físico) para cumplir con los estándares de accesibilidad. Esta tecnología, puede ser un instrumento en el desarrollo de contenido accesible rápido y con un costo considerablemente reducido. Las soluciones, están disponibles en muchas formas diferentes:

 

 

 

 

 

Como parte de tu evaluación, busca soluciones que proporcionen archivos de ejemplo, que demuestren todos los problemas potenciales de accesibilidad que pueden ser revisados. Esto, ayudará a garantizar que las revisiones que se lleven a cabo, cumplirán con los estándares.

 

Las aplicaciones de verificación, deben también soportar los siguientes tipos de verificación:

 

 

 

 

 

 

 

 

Emulación de navegador (Esencial para Sitios Dinámicos) – El contenido Web, puede diferir basándose en los requisitos del programador del sitio, codificados para cada agente. Por tanto, el programa debe tener la posibilidad de interactuar con un servidor Web y, al hacerlo, identificar el navegador como un agente distinto para probar cómo reaccionaría el servidor con cada navegador.

 

 

 

 

Si quieres hacer una prueba rápida y gratuita, de una herramienta que funciona constantemente, visita:

 

http://www.accessibilitywatch.com/

 

Este sitio, permite hacer una verificación gratuita de 5 páginas, inmediatamente. ¡Se te enviará un mensaje con enlaces a los informes del estado de la accesibilidad de tu sitio!.

 

Herramientas de Rehabilitación (Reparación)

Las herramientas de reparación, son siempre controvertidas para los desarrolladores de HTML. La razón es que, el autor teme que las herramientas invalidarán su código HTML, llevando a cabo malas modificaciones. Sin embargo, las herramientas de reparación, pueden ser valiosas en la gestión de la accesibilidad de un sitio Web.

 

 

 

 

 

 

 

Si una herramienta de reparación se aplica adecuadamente, está probado que será esencial en el proceso de hacer un sitio accesible. Además, una buena herramienta de reparación, disminuye los requerimientos de formación de personal de desarrollo Web, así como también disminuye la probabilidad de existencia de errores.

 

Herramientas de monitoreo

Recuerda que, debido a que el contenido de los sitios web es dinámico, éste, por naturaleza, está siempre cambiando. Esto significa que, una pieza importante de cualquier estrategia de accesibilidad es, una solución que te permita garantizar que tu sitio permanecerá en conformidad con las normas progresivamente. Desde una amplia perspectiva del sitio, las empresas deben implantar servicios que no requieran atención continua, bien alojados o localizados en sus servidores internos, que una vez configurados, constantemente monitoricen los sitios Web, o partes de ellos, y alerten a los responsables si hay un problema, que les haya dejado fuera de conformidad con las normas. 

 

Qué no pueden hacer las herramientas automáticas

Una herramienta de revisión automática, puede usarse para revisar tu sitio o un grupo de documentos, sin requerir atención, una vez que se ha configurado. Es muy importante recordar que, la herramienta por sí sola “NO” puede validar toda la accesibilidad de tu sitio Web.

 

Sin embargo, una buena herramienta puede identificar la mayoría de lo que requiere ser verificado visualmente. Una buena herramienta, adicionalmente, te permitirá saber qué páginas no necesitan ser revisadas visualmente, basándose en la ausencia de elementos que requieren verificación visual. Recuerda: sigues necesitando estar seguro de que, todos los puntos de control identificados como visuales por la solución, son accesibles.

 

Evaluando Herramientas de Revisión y Reparación de la Accesibilidad

Al igual que con cualquier requerimiento de revisión para el contenido Web, al seleccionar una solución de revisión de la accesibilidad, tendrás elecciones a hacer. Debes evaluar la solución que has elegido, para asegurarte de que puede cumplir con la tarea que necesitas que lleve a cabo. Además, debes verificar que la herramienta tiene:

 

Un diseño común – Disminuye el nivel de entrenamiento necesario para implantar la solución.

 

Completa Ayuda y Documentación de Usuario – Sin tener en cuenta la herramienta, será necesario dedicarle algún tiempo para acelerar su uso. Cuando evalúes una herramienta, asegúrate de que hay disponible una documentación completa.

 

La capacidad de automatizar – Tu herramienta de revisión debe permitir automatizar funciones en el cliente o en el servidor. Esto es importante, debido a que el proceso de revisión de la accesibilidad puede llegar a ser un recurso intenso, si el número de páginas es superior a unos pocos cientos. Además, la solución debe permitirte revisar páginas sin interacción por parte del usuario.

 

Los siguientes elementos pueden representar la capacidad de automatización:

 

·        Una Applications Programmers Interface (API) publicada, pública y documentada

 

·        Soporte para Scripting – La capacidad de crear y ejecutar scripts de prueba.

 

·        Un Subsistema de Programación (Generalmente con productos del servidor)

 

·        Integración con el Subsistema de Programación del Sistema Operativo (Ej.: la agenda de tareas de Windows)

 

·        Alertas de Accesibilidad Automatizadas

 

 

Sistemas existentes de Gestión de Contenido

Está claro que, con formación y con la gestión del contenido, puedes obtener un impacto positivo sobre la accesibilidad total de tu sitio Web. Tu sistema de gestión de contenidos (si lo tienes) es un buen punto de comienzo.

 

Utilizando una herramienta de verificación o reparación, que soporte la automatización, o usando una herramienta con base en el servidor como parte de la preparación del contenido; puedes prevenir de forma rápida y automática que se publique contenido inaccesible. También puedes usar herramientas de verificación para garantizar que las plantillas, que se usan para presentar datos, son también accesibles. La verificación y reparación de la accesibilidad puede crearse dentro de las revisiones y balances de garantía de calidad, de tu sistema de gestión de contenido, previos a la publicación.

 

 

Arquitecturas de revisión existentes

La mayoría de las organizaciones, tienen ya implantados procesos de revisión y garantía de calidad para sitios Web. Este proceso, además, puede incluir el uso de herramientas y o servicios generales o especializados.

 

Las revisiones de accesibilidad, podrían adaptarse dentro de este proceso, si el mismo equipo que se ocupa de la garantía de calidad, fuera responsable de revisar la accesibilidad, o se utilizara el mismo sistema de revisión de gestión.

 

Esto significa que, si estás usando herramientas de revisión para el sitio, es importante que tu herramienta de revisión de la accesibilidad pueda integrarse con la aplicación de revisión, a través de tu API o a través de la API  de la solución de revisión de la accesibilidad.

 

Las herramientas de revisión, que incorporan la verificación de la accesibilidad, te permitirán llevar a cabo valoraciones del sitio, planes de proyectos de accesibilidad, requisitos de revisión, gestión de revisiones y traspaso y seguimiento de faltas.

¿Qué es un API?

API es el acrónimo de Application Programmers Interface. Si un producto tiene un API, significa que puede accederse informáticamente a algunas o a todas sus funciones.  Esto permite la programación automatizada y la integración con tus sistemas o procesos existentes.


 

4. Desarrollando una Estrategia de Conformidad con la Accesibilidad

Divider

 

En este capítulo

 

·        Llevando a cabo una valoración del sitio

·        Estableciendo metas

·        Estableciendo directrices de diseño

·        Formando a los desarrolladores

·        Planificando un proyecto de reconversión

·        Introducción a la unidad de revisión

·        Introducción a la revisión de la conformidad

·        Introducción a la revisión de la compatibilidad

·        Introducción al mantenimiento de la accesibilidad

·        Una aproximación, paso a paso, al contenido accesible

·        Introducción a las intranets

·        Introducción a la planificación de la accesibilidad para Intranets

 

Divider

 

 

La práctica del diseño accesible de sitios Web no es nueva, sin embargo, la adopción de este concepto por parte de la mayoría, lo es. Esta nueva práctica, puede producir nuevos y significativos requerimientos de formación.

 

Durante un tiempo, las organizaciones han estado intentando conseguir el más rico y atractivo contenido Web posible, forzando los elementos de diseño.  Ahora tienen que reconvertirse a la accesibilidad, al darse cuenta de que han dejado fuera a más de 50 millones de clientes potenciales, o visitantes de su sitio Web. Mientras ésta no fuera la intención original de los diseñadores, es un problema que debe tratarse.

 

Mirando adelante

En los capítulos anteriores, hemos definido claramente las directrices de accesibilidad y a aquellos sobre los que repercuten. Tras haber leído las secciones anteriores, deberías tener una mayor comprensión del nivel de esfuerzo que se requiere para construir un sitio Web, accesible para todos.

 

Una estrategia de accesibilidad, le proporcionará a tu organización la capacidad de ver la accesibilidad desde la perspectiva de la gestión de un proyecto. Esto habilitará a tu organización para:

 

 

La mayoría de las empresas y administraciones públicas, que tienen presencia en la Web, tienen equipos de desarrollo de aplicaciones o contenido Web. Muchas de estas organizaciones, tienen varios equipos, cada uno con responsabilidades específicas, diferentes, sobre los contenidos o aspectos del diseño de una aplicación o sitio dados. Cada uno de estos equipos, necesita ser responsable de las cuestiones de accesibilidad y requerimientos que les conciernen. Para el propósito de este libro, estos equipos se clasificarán en 5 grupos principales:

 

Un equipo desarrollador de contenido, consiste en las personas que generan el contenido real que el sitio presentará. Además, probablemente serán también responsables de colocar contenido y cualquier gráfico y/o objetos juntos en el sitio. En esta definición, contenido se refiere al texto o escritos, no a los componentes gráficos o funcionales del sitio. Esto es aplicable tanto al contenido dinámico como al estático. 

 

Un equipo desarrollador de multimedia es, el que es responsable de la creación de contenido enriquecido. Algunos tipos de contenido enriquecido son:

 

 

Un equipo de diseño y maquetación es, el responsable de la creación de toda la navegación del sitio y/o su distribución.

 

Un equipo de administración es, el que es responsable de la arquitectura central del sitio Web y su conformidad con los estándares de la organización.

 

 

 

Un equipo de desarrollo de gráficos es, el responsable de todas las representaciones gráficas o imágenes para el sitio.

 

Estos grupos, son divisiones lógicas de lo que se requiere para crear un portal de información Web. Dependiendo de tu estructura organizativa, puede haber cruces de funciones y responsabilidades, entre los grupos y diseñadores Web.

 

La Dirección Correcta

Al igual que con cualquier otro proyecto, asegúrate de poner el equipo de dirección correcto en su lugar. Tu equipo para el proyecto de accesibilidad, debe incluir individuos de cada uno de los grupos que contribuyen al desarrollo y mantenimiento de tu sitio Web. En una organización media, los siguientes grupos podrían estar representados:

 

 

El nivel de participación variará para cada grupo, sin embargo, todos ellos cumplirán una importante función en el proyecto.

 

Una aproximación por fases

Las siguientes, son las cuatro fases básicas del desarrollo y mantenimiento de un sitio Web accesible:

 

 

Es altamente recomendable, que las organizaciones completen cada una de las fases antes mencionadas, para garantizar que las metas de la organización, en cuanto a la accesibilidad del sitio Web, se logran. Esta aproximación por fases, es una estrategia muy básica basada en lo fundamental. Tu organización puede requerir una estrategia más completa o una más sencilla. El proceso de planificar un proyecto podría llenar muchas páginas. Este proceso, representa la necesidad de un plan real y sirve como introducción, para aquellos que no han trabajado antes en un proceso formal de proyección.

 

Por ejemplo: Una organización puede tener un plan fantástico, crear directrices, hacer una revisión inicial, pero no llevar a cabo nunca los pasos de mantenimiento. En este ejemplo, este sitio podría volver a hacerse inaccesible, muy rápidamente.

 

La evaluación de un sitio

Para un sitio pequeño, la evaluación puede hacerse mirando cada página para ver si hay fallos. Para los sitios grandes, con muchas páginas de contenido, este método se convierte en engorroso e incluso inmanejable. Es recomendable el uso de una herramienta de evaluación.

 

El primer paso de una evaluación es, determinar la condición de accesibilidad de todo su sitio Web. Utilizando herramientas de evaluación de la accesibilidad, fácilmente disponibles, las organizaciones pueden recibir inmediatamente, una instantánea de la accesibilidad de su sitio Web.

 

3D Pie Graph showing 52.173 % Files Passed, 47.827 % Files Failed

Imagen 3.1 – Representación gráfica del cumplimiento de las normas de accesibilidad de un sitio, producida por AccVerify Professional.

 

Una herramienta de evaluación puede, además, mostrar a los equipos desarrolladores, información importante sobre qué normas de accesibilidad se están violando.

 

3D Bar Graph showing 1.1=30, 7.1=2, 9.1=3, 12.1=3, 6.3=5, 11.4=0

Imagen 3.2 – Representación gráfica del cumplimiento de los estándares de accesibilidad llevada al detalle exacto de qué errores existen, producida por AccVerify Professional.

 

Independientemente de la herramienta utilizada, es importante conseguir una evaluación válida, de manera que los equipos de desarrollo o gestión, sean capaces de determinar el alcance y la naturaleza del trabajo que requerirá, por parte del equipo, desde la perspectiva de la reparación, así como cuántas páginas en el sitio requerirán una verificación visual.

 

3D Pie Graph showing 34.782 % Require Visual Verification, 65.218 % Do Not Require Visual Verification

Imagen 3.3 – Representación gráfica del porcentaje de páginas del sitio que requieren una revisión visual, para garantizar su conformidad con las normas de accesibilidad, producida por AccVerify Professional.

 

Para distribuir apropiadamente los recursos de la empresa, las organizaciones necesitarán también una vista de las verificaciones visuales, individuales, requeridas.

 

3D Bar Graph showing 1.2=3, 5.1=7, 5.2=7, 6.3=19, 1.4=2

3.4 – Representación gráfica de los elementos reales en tu sitio que requieren una verificación visual, para garantizar la conformidad con las normas de accesibilidad, producida por AccVerify Professional.

 

Al pensar en la accesibilidad, es importante comprender, cómo los equipos de desarrollo del sitio usan los elementos Web. Tu herramienta de evaluación, debe proporcionarte la siguiente información:

 

RESUMEN ESTADÍSTICO DE LA ACCESIBILIDAD

Con la siguiente información, las organizaciones pueden asignar, adecuadamente, las tareas requeridas para lograr que el proyecto de accesibilidad tenga éxito.

 

Resumen de imágenes

El resumen de imágenes de un sitio Web, proporciona una vista inmediata de cuantas referencias a imágenes existen, y cuantas no cumplen con las Directrices del W3C o la Sección 508. En el ejemplo de abajo, diez de las referencias a imágenes no cumplen con las directrices.

 

Resumen de imágenes
Imágenes: 13
Imágenes sin el atributo Alt: 10
Imágenes con el atributo Alt: 3
Imágenes con el atributo Alt en blanco: 0
Imágenes con el atributo Alt nulo: 0
Imágenes contadas por su extensión de archivo:

 

Extensión de Archivo     Cantidad

.gif                                           12

.jpg                                          1

 

 

Resumen de formularios

El resumen de formularios en un sitio Web, proporciona una vista inmediata de cuántos formularios existen, así como de cuántos no cumplen con las Directrices del W3C o de la Sección 508. En el ejemplo de abajo, una de las imágenes de entrada de datos del formulario no tiene texto alternativo.

 

Resumen de formularios
Formularios: 3
Formularios con Controles Etiquetados: 0
Formularios con Entradas (input) usando el atributo Alt: 0
Formularios sin elementos de entrada: 0
Formularios con imágenes de entrada que no usan el atributo Alt: 1

Formularios sin ningún uso de TabIndex: 3
Formularios sin ningún uso de AccessKey: 3

 

Resumen de Marcos

El resumen de marcos de un sitio Web, proporciona una vista inmediata de cuántos marcos (frames) existen y, de estos, cuántos no cumplen con las Directrices del W3C o de la Sección 508. En el ejemplo de abajo, ninguno de los marcos está en conformidad con las Directrices del W3C y la Sección 508.

 

Resumen de Marcos
Marcos: 3
Marcos sin el atributo Title: 3

IFrames: 1
IFrames sin el elemento content: 1

 

 

 

Resumen de scripts

El resumen de scripts de un sitio Web, proporciona una vista inmediata de cuántos elementos script existen y, de estos, cuántos no cumplen con las Directrices del W3C o la Sección 508.

 

 

Resumen de scripts
Elementos Script: 2
Elementos Script sin NOSCRIPT: 2

 

 

Resumen de enlaces

El resumen de enlaces de un sitio Web, proporciona vistas inmediatas de cuantos enlaces se han encontrado, que contienen “Pincha aquí”, o que contienen enlaces a documentos externos que deben ser accesibles o deben cumplir con las directrices de accesibilidad.

 

Resumen de enlaces
Enlaces con la frase "Pincha aquí" en el texto del enlace: 0
Enlaces a archivos DOC: 0
Enlaces a archivos MP3: 0
Enlaces a archivos MPG: 0
Enlaces a archivos PDF: 0
Enlaces a archivos PPT: 0
Enlaces a archivos SWF: 0
Enlaces a archivos XLS: 0

 

 

Resumen de Tablas, Objetos y Applets

Estos resúmenes de sitios Web, proporcionan información valiosa sobre la conformidad, o la falta de ella, para estos elementos esenciales del diseño y/o contenido interactivo.

 

Resumen de tablas
Tablas: 8
Tablas con el atributo Summary: 0
Tablas con Caption: 0
Tablas con Summary y Caption: 0
Tablas con el atributo ID: 8
Tablas con celdas con el atributo ID: 0
Tablas con celdas que usan Scope: 0
Tablas de Datos: 7

 

Resumen de objetos
Objetos: 6
Objetos sin el elemento content: 4

 

Resumen de Applets
Applets: 1
Applets sin el atributo Alt o el elemento Content: 1

 

Estableciendo metas

Establecer metas formales para cumplir con la accesibilidad en tu organización, es crucial para el éxito del proyecto. Una parte de las metas de tu proyecto, depende en gran medida de:

 

Estableciendo Directrices de Diseño

El nivel de cumplimiento de la accesibilidad, altamente recomendable para todas las organizaciones, es la Prioridad Uno del W3C y la Sección 508. Esta es una meta alcanzable, y permitirá a las organizaciones satisfacer tanto las directrices internacionales como las de Estados Unidos. Las otras directrices y/o recomendaciones disponibles, hoy en día, no están tan ampliamente aceptadas. Sería imprudente establecer metas más altas para tu organización, hasta que las demás recomendaciones sean aceptadas más ampliamente.

 
UsANDO LA EVALUACIÓN

Una vez que tengas una evaluación válida de la accesibilidad del sitio Web, puedes comenzar a planear los pasos que serán necesarios para hacer accesible tu sitio. Esto, deberá comenzar con el entrenamiento y formación de los equipos de desarrollo específico, responsables de todo el contenido de tu sitio.

 

Desarrollo de Contenido

Si el contenido desarrollado es dinámico por naturaleza, entonces, puede ser que un alto porcentaje de los métodos de distribución de contenido tengan que hacerse accesibles, lo que requerirá la formación de los desarrolladores en esas metodologías. Los desarrolladores, necesitarán formarse en la creación y revisión de plantillas accesibles, así como sobre los datos accesibles que llenarán las plantillas de acuerdo con las solicitudes del usuario final. Por ejemplo, en el caso de un catálogo de productos, un equipo de desarrollo puede necesitar automatizar la introducción de todos los textos alternativos, para las imágenes que se presentarán. Los desarrolladores de sitios dinámicos, necesitan formarse sobre todas las cuestiones de accesibilidad, basándose en las prácticas de desarrollo actual. La formación también puede proporcionarse, con la finalidad de nivelar los cambios y actualizaciones tecnológicas.

 

Desarrollo Multimedia

El uso de contenido multimedia en tu sitio Web, debe valorarse cuidadosamente, pues puede requerir un tiempo de desarrollo significativo para aplicar la accesibilidad. El programa de entrenamiento, debe formar a los desarrolladores multimedia en los problemas de accesibilidad asociados con los elementos multimedia en la Web, y debe pasar revista a las herramientas y tecnologías disponibles para tratar, o solucionar, esos problemas.

 

Maquetación y diseño del sitio

La accesibilidad, debe ser un elemento que forme parte de cada paso del proceso de diseño Web. La valoración es el primer nivel del entrenamiento, y yendo un poco más allá, puedes querer asignar un miembro del equipo para verificar la accesibilidad de cualquier propuesta de modificaciones en el diseño.

 

Gestión del sitio

Los gestores de sitios, quienes normalmente tratan con los fallos y errores del sitio, necesitan ser formados en los requisitos de accesibilidad. La revisión de la accesibilidad debe implantarse como parte de las prácticas de Garantía de Calidad, que estén ya establecidas en tu organización. Desarrollando y garantizando que el contenido sea accesible antes de publicarlo,  así como monitorizar en vivo los sitios Web, puede ayudar a los gestores del sitio, a garantizar que su sitio sea accesible. La verificación de la accesibilidad será más eficaz, si se incorpora a los reglamentos y procedimientos operativos, estándar, de la organización.

 

Desarrollo Gráfico

Los desarrolladores gráficos, necesitan ser entrenados en los requisitos de accesibilidad para el contenido gráfico. Debe proporcionarse formación en cómo escribir textos equivalentes, y en que debe darse un texto equivalente a cada imagen.

 

Implantando directrices corporativas

Una vez desarrolladas las directrices y metas de accesibilidad, comienza la siguiente fase. En esta fase los desarrolladores y equipos de garantía de calidad, recibirán formación, y el proceso de reconversión del sitio Web de la empresa comienza. Como política corporativa, las empresas deben monitorizar cualquier problema, en todos los nuevos desarrollos en el sitio Web, o establecer estándares, para garantizar que todas las nuevas páginas, plantillas, y contenido; se desarrollan en conformidad con los nuevos estándares.

 

Formando a los desarrolladores

Al menos la mayoría de las organizaciones, se han ocupado de algunos problemas de accesibilidad en su contenido Web, otras, no se han ocupado de ninguno, y unas pocas, se han ocupado de todos. Con esto en mente las organizaciones deben, antes de nada, hacer una valoración de lo que está bien hecho, y de lo que no ha sido desarrollado de manera que sea accesible.

 

La valoración de la accesibilidad, es la fase más importante para determinar la estrategia de accesibilidad de una empresa. Si no estás seguro de cuáles son los problemas, y su dimensión, no serás capaz de proporcionar los recursos adecuados y planificar lo necesario para llegar a una solución.

 

Reconvertir el contenido actual y desarrollar todo el contenido nuevo, de acuerdo con las directrices

La evaluación del sitio permite proyectar metas. Una vez que una empresa tiene bien definidas las metas proyectadas, es fácil determinar qué pasos serán necesarios para el proyecto, que hitos se lograrán, y lo qué requerirá el plan. Para determinar los recursos, hay que considerar varios factores que determinan el número real de recursos, que serán necesarios para el proyecto.

 

  1. La cantidad total de contenido, o el número de páginas estáticas
  2. El número de plantillas para contenido dinámico
  3. El tiempo requerido para arreglar una página o plantilla (en horas)
  4. El crecimiento del sitio Web (Cuántas páginas nuevas se añaden cada semana o mes)
  5. El total de los recursos disponibles para el proyecto
  6. La prioridad del proyecto
  7. La fecha de inicio del proyecto
  8. Fecha requerida para la finalización del proyecto

 

El análisis de los elementos mencionados arriba, permitirá a los sistemas de gestión de proyectos comunes, determinar el número de recursos requeridos. Si tu empresa no usa un sistema de gestión de proyectos, haz el siguiente cálculo:

 

A+B*C = total de horas requeridas para arreglar el sitio

H-G= total de días asignados al proyecto

 

Basándose en un promedio de trabajo al día de seis (6) horas, divide entonces el total de las horas por seis (6) para llegar al número de días, de recursos necesarios para completar el proyecto.

 

Por ejemplo: Si son necesarios 40 días de recursos para completar el proyecto, y realmente sólo cuentas con 20 días para completarlo, divide los días de recursos (40) por los días requeridos (20) para obtener el número de recursos necesarios. En este ejemplo, el número de recursos requeridos para completar el proyecto, a tiempo, será dos.

 

Una vez está definido claramente el proyecto, y se han distribuido los recursos, una empresa está lista para comenzar el proyecto de reparación de la accesibilidad. 

 

Revisando la Accesibilidad

La aproximación por fases, a la sección de revisión implica dos tipos distintos de revisión: revisión de “Desarrollador” y de “Usuario”.

 

El desarrollador es responsable de seguir las directrices y garantizar que las plantillas y/o las páginas estáticas, cumplen con las Directrices de Accesibilidad, antes de ser entregadas a la revisión de Garantía de la Calidad o del Usuario. En el mundo de la revisión de software, el equivalente sería las pruebas “unitarias” o las pruebas de “Caja Blanca”. 

 

La revisión de usuario, normalmente es responsabilidad del equipo de garantía de calidad. Este equipo puede ser un equipo de revisión formal o, para las empresas pequeñas, simplemente otro desarrollador que está entrenado para revisar páginas Web. Este equipo, es responsable de revisar la conformidad y compatibilidad.

 

Unidad de revisión

Los desarrolladores deben revisar su trabajo utilizando una lista de comprobación, ya sea generada manual o automáticamente, que les permita verificar que cada página o plantilla, produce contenido accesible. Para esta fase nosotros recomendamos trabajar con tecnologías de revisión, que permiten al desarrollador probar la página o plantilla, durante el proceso de desarrollo. Es importante que la herramienta proporcione, tanto informes detallados de errores, como listados de comprobación de la página. Recuerda, este esfuerzo debe formalizarse. El costo de corregir errores encontrados tras la entrega, a los equipos de producción o de garantía de calidad, será de tres a cinco veces mayor.

Revisión de conformidad

La revisión de conformidad verifica que tu sitio, página o plantilla, conforman las directrices y/o normas de accesibilidad. Al igual que con la unidad de revisión, es recomendable que uses herramientas de revisión automática, para determinar más eficazmente la conformidad de tu sitio Web.

Revisión de compatibilidad

La revisión de compatibilidad, garantiza la compatibilidad de las aplicaciones con base en la Web, o sitios Web, cuando son vistos por distintos navegadores y sistemas operativos. Aunque las revisiones de compatibilidad pueden llevarse a cabo a mano, recomendamos usar una herramienta de revisión automática para manejar esta etapa de revisión. Es importante que la herramienta proporcione la capacidad de configuraciones, de prueba y scripts, para minimizar el número de recursos por hora, requeridos para esta revisión.

 

Revisión con Ayudas Técnicas

El equipo de garantía de calidad, debe también ser responsable de verificar cómo se presentan los contenidos Web, a través de las ayudas técnicas. En esta fase, un revisor debe probar la página, realmente, con diversas ayudas técnicas, para garantizar que el verdadero significado del contenido es comunicado y/o presentado, de forma clara, para el visitante del sitio.

 

Por ejemplo:

 

Mantenimiento de la accesibilidad

Una vez se han completado las fases previas, debe diseñarse un plan que ofrezca un desarrollo y revisión progresivas, para garantizar la conformidad con las directrices y estándares de la organización. El capítulo anterior introdujo el monitoreo de la accesibilidad. En la fase de mantenimiento, querrás establecer la monitorización del sitio, y:

 

 

La aproximación por fases, ofrece la mejor oportunidad para el cumplimiento de las directrices y normas de accesibilidad en el sitio Web. Las empresas pueden buscar la continuidad de la accesibilidad de su sitio Web, una vez hayan desarrollado las disciplinas explicadas arriba.

Introducción a las Intranets

Una Intranet, es una red de ordenadores privada. Esta red puede ser utilizada por usuarios autorizados por el dueño de la red. Las Intranets se utilizan para la distribución interna de información, comunicación, y/o compartir aplicaciones.

 

Los usos más comunes de una intranet son:

 

 

Una de las metas generales de la Intranet es, reducir las estaciones de trabajo individuales y mantener el costo, a la vez que se incrementa el conocimiento compartido. Naturalmente, esto lo hacen muchas organizaciones.

 

Sitios en Internet vs. Sitios en Intranet

Internet y las Intranets tienen en común muchas características, y se basan en idénticas tecnologías. La principal diferencia es, que una empresa es dueña de su Intranet, e Internet es de acceso público. Algunas empresas expanden las capacidades de su Intranet, haciendo que partes de sus recursos estén disponibles a través e Internet, de manera segura; a esto se le llama una Extranet. El acceso a sitios en la Extranet y a la Intranet, generalmente está controlado por un esquema de seguridad, de acceso del usuario.

 

Creando una Intranet accessible

La sección previa de este libro, ha cubierto los problemas de accesibilidad, normas, y desafíos. Sin embargo, el libro estaría incompleto si no tratara la accesibilidad en intranets. Las empresas comprometidas con el desarrollo de información accesible, y con proporcionar soluciones accesibles para sus empleados, para que puedan llevar a cabo su tarea, deben hacer accesibles sus intranets.

 

Prioridades en la Intranet

Las Intranets casi siempre tienen más contenido y aplicaciones, que un sitio en Internet. ¡La tarea de hacer una Intranet accesible puede parecer imposible!. Sin embargo, de hecho es fácil. La razón de que sea fácil, corregir los problemas de accesibilidad de una Intranet, es que es privada. Esto permite a las empresas tener un gran control sobre el proyecto, siguiendo la misma aproximación por fases, que fue descrita arriba, para desarrollar su planificación y metas para la Intranet. Los proyectos de accesibilidad para Intranets, deben estar divididos y ordenados por prioridades, como sigue:

 

 

Las tareas de arriba pueden planificarse. Las organizaciones deben establecer metas realistas y desarrollar sistemas de medición, que puedan usarse para medir sus logros. Es altamente recomendable que se haga público este proceso para hacer accesible la Intranet. Pregunta y acepta las sugerencias de tus empleados.

Da Pequeños Pasos para obtener Grandes Ganancias en Accesibilidad

Recientemente, una de las empresas incluidas en la lista Fortune 100 , solicitó una revisión de su sitio con  AccessibilityWATCH, de HiSoftware. El sitio tiene una proporción de fallos del 96% en todas sus páginas. Cuando se presentó esta información a la empresa, parecía una tarea de reparación abrumadora y no creían que la empresa la aprobaría.

 

Usando las tecnologías de valoración mencionadas arriba, la empresa fue capaz de separar los errores y, al hacerlo, se descubrió alguna información interesante:

 

 

 

 

 

Saber esto, les proporcionaba la convicción de que el problema no era tan grande, ni tan aplastante, como parecía inicialmente, y que ellos podrían, con el tiempo, llevar a cabo un plan de proyecto que podría mejorar considerablemente los niveles de accesibilidad de su sitio Web.

 

Recuerda que, Roma no se construyó en un día y que, debes dar pequeños pasos para comenzar con lo que puedas:

 

·        Formación en la dirección apropiada

·        Planifica tu proyecto de reparación de la accesibilidad

·        Observa y registra los resultados positivos de tus esfuerzos


5. Accesibilidad y Contenido Dinámico

Divider

 

En este capítulo

 

·        Una introducción al Contenido Dinámico

·        Qué es una emulación de navegador y por qué es necesario llevarla a cabo como parte del proceso de revisión

·        Ejemplo I – Problemas comunes con el Contenido Dinámico

·        Ejemplo II – Proponer tu sitio a un Buscador Popular.

 

Divider

 

Definición de Contenido Dinámico

El término “contenido dinámico”, se usa para describir muchos tipos diferentes de contenidos, presentados por diferentes tipos de fuentes. Esta sección del libro, tratará de la revisión y evaluación del contenido dinámico de sitios Web. Se discutirán los siguientes tipos de contenido dinámico:

 

 

El contenido dinámico introduce problemas especiales. La simple revisión de la plantilla, puede no garantizar la accesibilidad del producto final. La única forma de asegurarse de que determinadas normas de accesibilidad se están cumpliendo, es revisar el sitio “en vivo”.

 

Esto significa que, si tienes un sitio que presenta datos diferentes, basándose en el navegador que es usado para acceder al sitio, debe hacerse una revisión con cada uno de los navegadores relevantes. Las soluciones que proporcionan revisión de la accesibilidad, deben tener soporte para la revisión de sitios en la Web y para la revisión emulando navegadores.

 

Hay bastantes aproximaciones diferentes, para garantizar la accesibilidad del contenido Web generado dinámicamente. Un componente destacado serán las plantillas accesibles. Las plantillas deben revisarse con herramientas de verificación. El siguiente paso es revisar la salida generada a solicitud del usuario. De nuevo, deben usarse herramientas de verificación para emular tantos ejemplos como sea posible. La formación en accesibilidad, puede ayudar a los desarrolladores a diseñar elementos de salida accesibles, así como plantillas accesibles. Las herramientas de accesibilidad, pueden utilizarse de manera independiente o pueden estar integradas en las soluciones de distribución, revisión y de monitoreo de contenido.

 

Un ejemplo de la emulación de navegador en herramientas de verificación

Cuando un navegador Web, u otro tipo de agente de usuario, envía una solicitud para una página, desde un servidor Web, parte de la solicitud desde el navegador incluye información sobre el navegador en sí, incluyendo el nombre del agente, su versión, etc. (un ejemplo de un agente de usuario es Internet Explorer). El servidor Web, en la mayoría de los casos, devuelve una página Web, válida para el agente o navegador Web. En tanto que los navegadores Web más nuevos, soportan este contenido, los desarrolladores Web, deben asegurarse de que la información sea accesible para los individuos que utilizan navegadores antiguos.

 

A continuación, hay un ejemplo de algún seudo-código que un desarrollador podría usar en la creación de una página Web basada en esta idea.

 

<%

var browser = Server.CreateObject("MSWC.BrowserType")

ie4 = (browser.version>=4) && (browser.browser=="IE")

ns4 = (browser.version>=4) && (browser.browser=="Netscape")

if (ie4)

 { %> <P>Do something for Internet     Explorer 4 and greater <% }

else if (ns4)

{ %> <P>Do something else for Netscape 4 and greater <% }

else

{%> <P>Give this content here for everything else <% }

%>

 

El código JavaScript de arriba, cuando se usa en una Active Server Page (ASP) en un servidor Web, distribuye el contenido al navegador, o agente Web, basándose en la identidad del agente de usuario. Dependiendo del diseño del sitio Web, y de las diferentes opciones usadas en la escritura y distribución del script, el código de arriba podría no ser visible para un usuario, que esté mirando el código, e incluso, a través de un programa navegador tal como Internet Explorer o Netscape, o al guardar la página localmente para revisarla. Esos usuarios podrían ver sólo el código para sus respectivos navegadores.

 

En la revisión de un sitio Web en cuanto a su accesibilidad, el usuario quiere estar seguro de que el sitio Web es accesible, para todos los usuarios que podrían ver la página. Esta funcionalidad es crucial. A menudo, el grupo que informa sobre la accesibilidad de un sitio, no es el mismo grupo que desarrolla el sitio. En estos casos, el grupo responsable de la accesibilidad del sitio, podría no ser consciente de la existencia de una funcionalidad específica para un determinado navegador y podría, posiblemente, pasar por alto revisar el código que fue escrito específicamente para una determinada marca y versión de un navegador Web.

 

Las páginas pasadas por alto en la revisión, pueden carecer de elementos que podrían no ser detectados por medios convencionales.

 

Quién debe revisar el Contenido Dinámico

A menos que la tuya sea una “sociedad unipersonal”, el desarrollador del sitio dinámico no debe ser responsable de garantizar que su accesibilidad es conforme con las normas globales de accesibilidad.

 

Debe haber una persona designada, o un equipo, encargados de revisar el sitio dinámico para garantizar que cumple con las normas de accesibilidad.

 

Algunos mitos comunes o generalizaciones inexactas sobre la revisión del contenido dinámico:

 

 

Aunque cualquiera de estas declaraciones puede ser verdad, hay que revisarlas para probar si son correctas o erróneas.

 

Aplicaciones con base en la Web

Una aplicación con base en la Web puede, generalmente, ser revisada de la misma manera que se revisa el contenido dinámico de un sitio. Esto es cierto si el contenido que presenta la aplicación es de tipo HTML o XHTML, si no, las revisiones se sustentarán en directrices diferentes a las que se ofrecen en este libro.

 

Puedes consultar esto con los desarrolladores del sitio, si no estás seguro de qué formatos se entregan al navegador.

 

Caso I – Problemas Comunes con el Contenido Dinámico, vistos en uno de los mayores sitios de comercio electrónico

ABC Company es el mayor portal distribuidor de software online. La empresa revende productos software, y se paga una cuota por proporcionar transacciones seguras y protección contra el fraude, para las casas comerciales que ellos representan. La empresa proporciona servicios de catálogo de productos y pedidos, desde la información almacenada en una base de datos Oracle.

 

Los vendedores/clientes pueden añadir información a su presencia en el portal, incluyendo logos de productos y texto descriptivo, a través de una interfaz Web o actualizando la aplicación. Un usuario con discapacidad (en este caso un  usuario ciego) trabajando con la aplicación Web de los distribuidores, tendría que enfrentarse a muchos desafíos.

 

Introduciendo la Información del Producto

Para poner productos en el Mercado, el primer paso que tiene que dar el usuario de la aplicación para los vendedores es identificarse, en el sistema de gestión de productos. Una rápida revisión de la accesibilidad de esta pantalla, muestra errores graves de incumplimiento de las Sección 508 y/o directrices del W3C.

 

En el ejemplo de datos de abajo, Los errores de Prioridad Uno que encontrará el usuario podrían simplemente impedirle el acceso al sistema y hacerle muy difícil una mínima navegación. Esto se debe a los siguientes errores de accesibilidad:

 

Punto de control 12.1 / (i) - Fallado
Titule cada marco para facilitar su identificación y navegación.

·         Norma 12.1: Todos los elementos FRAME deben contener el atributo 'title'.

o        Fallo – Elemento FRAME en línea: 9, Columna: 3

o        Fallo - Elemento FRAME en línea: 11, Columna: 5

o        Fallo - Elemento FRAME en línea: 12, Columna: 5

Dato 5.1 – Caso de Ejemplo

 

Al igual que con la pantalla de acceso, las páginas interiores tienen múltiples problemas de accesibilidad.

 

Las imágenes carecen de Texto Alternativo.

 

 

 

Nota: Es fácil decir que el cliente de este sitio podría asignar a una persona sin discapacidad, para llevar a cabo las tareas requeridas para crear o actualizar el catálogo.

 

Sin embargo, si el cliente fuera el gobierno y hubiera un competidor que ofreciera el mismo servicio, pero de manera accesible, el gobierno estaría obligado, por ley, a elegir a la competencia.

 

 

Tras introducir el cliente del sitio de comercio electrónico, a través de la interfaz, el contenido sobre el producto; el dato, que se almacena en una base de datos Oracle, se presenta cuando el comprador (el cliente final) selecciona el producto a comprar, desde el sitio Web de comercio electrónico dirigido a clientes finales.

 

Vendiendo el producto

La primera pantalla que el cliente ve es la página de descripción del producto. La página consiste en los siguientes importantes elementos:

 

 

También se proporciona un texto que indica que se haga clic en “compra ahora” para hacer el pedido.

 

Ahora, los usuarios ciegos no pueden:

 

 

Nota: Probablemente acabas de perder un cliente, y no te habría costado nada hacer esta página accesible, de manera que cualquier usuario pudiera haber tenido acceso a toda la información.

 

Ahora digamos al cliente figurado cómo conseguir llegar a la siguiente página. La siguiente página contiene el acuerdo de licencia que debe ser aprobado, antes de continuar adelante.

 

Al cliente se le presentan cuatro imágenes, cada una con un enlace a otra página o acción. Hay que elegir el enlace que permita aceptar el acuerdo de licencia.

 

Esta página no tiene ningún texto alternativo, así que, una vez más, el cliente se verá forzado a hacer una suposición para conseguir llegar a esta fase del pedido.

 

El cliente tendrá que hacer clic en todas las imágenes, hasta encontrar la correcta y ser capaz de continuar con el pedido.

 

 

La página siguiente tiene:

 

 

Nota: el cliente ciego, encontrará incluso más dificultades para introducir su dirección, o la información sobre la tarjeta de crédito.

 

Arreglemos el problema

Parece que ahí hay tres problemas reales.

 

  1. Las plantillas no son accesibles.
  2. Los datos de cliente no son accesibles.
  3. El contenido generado dinámicamente no es accesible.

 

Arreglando el problema nº 1

Los equipos de desarrolladores Web, deben garantizar que todas las plantillas sean accesibles. Ellos deben esforzarse como mínimo en cumplir con la Sección 508 de Estados Unidos, pero pensando globalmente, deben evolucionar hasta cumplir con los estándares del W3C.

 

arreglando el problema nº 2

Todas las aplicaciones de entrada de datos y modificaciones del sitio, respecto al cliente, deben cambiarse para permitir la introducción de información accesible para las imágenes y otros elementos de accesibilidad, que necesita el contenido accesible.

 

Nota: La mayoría de este tipo de arreglos, requerirá modificaciones de la base de datos de almacenamiento de la información.

 

arreglando el problema nº 3

El desarrollador del sistema, de catálogo de la tienda, necesita modificar más en sus plantillas el código de generación de página, para permitir el uso de los nuevos datos del cliente, que pueden ahora introducirse a través de la aplicación Web mejorada que gestiona los productos cliente.

 

¿Cuándo debe comenzar la empresa de comercio electrónico?

La empresa de comercio electrónico debe comenzar inmediatamente. Hay muchas razones pero las más apremiantes son:

 

  1. Realizar los cambios basándose en su agenda.
  2. Realizar los cambios antes de perder clientes.
  3. El probable aumento de los ingresos.
  4. La gran oportunidad de conseguir marketing gratuito y presencia en la prensa.
  5. Aunque en este momento es solo una ley federal, la mayoría de los expertos predicen que, dentro de 2-4 años la accesibilidad estará recogida como parte de la ADA.

 


Caso de ejemplo II – Proponiendo tu sitio Web a un motor de búsqueda popular

Uno de los líderes mundiales entre los portales buscadores, permite a los usuarios remitir su sitio Web para ser incluido en su índice. Esta propuesta la hace el usuario introduciendo un código, la URL del sitio Web y una dirección de correo electrónico.

 

Abajo están los problemas de accesibilidad que tendrían que enfrentar los usuarios con discapacidad. 

 

Archivo: MajorSearchEngine.htm – Fallado

Proporcione un texto equivalente para cada elemento no textual (Ej.: vía “alt”, “longdesc”, o en el elemento “content”) Esto incluye: imágenes, representaciones gráficas de texto (incluyendo símbolos), regiones de mapas de imagen, animaciones (Ej.: GIFs animados) applets y objetos programáticos, arte ascii, marcos, scripts, imágenes usadas como viñetas de listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin la intervención del usuario), archivos de audio autónomos, pistas de audio de vídeo y vídeo.

El efecto de estos problemas de accesibilidad es, que una persona ciega podría no añadir su URL al índice.

 

Otros problemas de accesibilidad para la sumisión incluyen:

 

 

 

 

 

 

Esto parece relativamente simple, sin embargo, se convierte en complejo si el usuario no puede leer la imagen e introducir en el formulario el código. Si este es el caso, el usuario NO PUEDE añadir una página por medio del formulario, incluso, aunque fuera capaz de pasar por encima de los otros errores que hay en el sitio.

 

La aplicación tampoco proporciona instrucciones para hacer una propuesta al índice, si no se puede leer la imagen.

 

El buscador usa esta práctica para “Combatir el Spam” en su motor. Esto impide la inclusión en su índice por medio de herramientas automáticas. Es recomendable que la empresa del motor de búsqueda,  lleve a cabo los siguientes pasos para reparar los errores de accesibilidad:

 

 


6. El significado inadvertido

 

Divider

 

En este capítulo

 

·        Una introducción a los metadatos para mejorar la accesibilidad del contenido

·        Una guía para escribir textos equivalentes

·        Escribiendo textos equivalentes para las imágenes

·        Prácticas y errores comunes al escribir textos equivalentes

 

Divider

 

En esta sección discutiremos los componentes no visuales, que pueden tener un impacto significativo en la accesibilidad de una página.

Metadatos para la  Accesibilidad

Los metadatos son una excelente vía para comunicar información, sobre un documento, o sobre los recursos que directamente se relacionan con la accesibilidad.

Una introducción a los metadatos

Los metadatos son información sobre un documento. La información que uses para describir un documento, puede ayudar a los usuarios a identificar si el documento es útil para ellos y a localizarlo rápidamente.

 

El precursor de los metadatos es el catálogo con tarjetas. Para cada elemento en una biblioteca, hay tres entradas en la tarjeta del catálogo: título, autor, y tema. Una tarjeta, indica la localización de un elemento en la biblioteca, y proporciona información adicional sobre él, tal como el editor, formato, género, fecha de publicación, y número de volúmenes. Mientras que la tarjeta sirve como base de datos para la biblioteca, los metadatos van un paso más allá – los metadatos vienen a ser parte del archivo electrónico y, permanecen en el código fuente sin importar que el archivo sea movido. Cuando usas los metadatos correctamente, puedes proporcionar información provechosa para el usuario. El uso de metadatos ha sido recomendado por el W3C®, o World Wide Web Consortium, como punto de control con nivel de Prioridad 2 para la accesibilidad de la Web.

Metadatos para la Accesibilidad

El Punto de Control 13.2 de las directrices e accesibilidad del W3C establece que, debes proporcionar metadatos para añadir información semántica a las páginas y sitios.

 

Debes incluir el nombre del autor, derechos de la empresa, tipo de contenido, etc. ...

 

 

Los metadatos se almacenan en forma de etiquetas Meta. Hay algunas etiquetas de metadatos que son rápidamente reconocidas por los servicios de indexación en Internet. Además, puedes crear etiquetas Meta personalizadas que son útiles para los miembros de tu organización.

 

La cuestión más importante al utilizar metadatos es, aplicarlos uniformemente a tu colección de documentos y usarlos de manera precisa. Cuando usas los metadatos de forma inapropiada, con la intención de ganar mayor visibilidad en Internet,  puedes comprometer tu ranking en los motores de búsqueda. Además, desde el punto de vista de la accesibilidad, estas básicamente proporcionando información engañosa o inexacta sobre un recurso.

 

La estructura de la etiqueta Meta

La etiqueta meta está localizada en la sección HEAD de un documento HTML.

 

Ejemplo:

 

<HEAD>

<Meta name=”Author” content=”Yonaitis”>

</HEAD>

 

Puedes colocar tantos elementos de metadatos en un documento, como sean necesarios para describir adecuadamente el recurso.

 

Eligiendo las etiquetas Meta

Aunque muchas organizaciones han recomendado el uso de los metadatos para impulsar la usabilidad e incrementar la accesibilidad, es difícil encontrar información específica sobre las etiquetas Meta que deben usarse. A continuación algunas de las etiquetas Meta utilizadas más comúnmente.

 

Keywords

Cada documento debe tener palabras clave. Las palabras que uses para describir tu documento deben aparecer en el cuerpo de texto del documento.

 

Description

Cada documento debe tener una descripción. Las palabras que uses para describir tu documento deben aparecer en el cuerpo de texto del documento.

 

 

Author

Cada documento debe tener al menos un autor. El autor puede ser una organización o más de un individuo, o ambos.

 

Language

La etiqueta Meta para idioma indica el idioma principal del documento. Existe una lista de códigos para los idiomas más comunes. Por ejemplo, el código de idioma para el Inglés hablado en Estados Unidos es en-us.

 

Robots

El valor de la etiqueta Meta robots, proporciona instrucciones a los rastreadores sobre cómo rastrear o indexar, el documento y otros documentos enlazados con él.

 

Rating

La etiqueta rating revela información sobre el contenido de su documento para los usuarios. Esto ayuda a los usuarios, a ocultar la información que puede no ser adecuada para todos los visitantes.

 

Copyright

La etiqueta Meta copyright, incluye el nombre de los dueños del copyright y una declaración del uso lícito.

 

Añadiendo etiquetas Meta a los documentos

Puedes añadir metadatos directamente a la sección de encabezado del documento, usando un editor Web, como Microsoft® FrontPage®. Este método manual, funciona para autores de documentos que necesitan añadir metadatos para describir un documento en particular.

 

Algunos valores de metadatos deben ser consistentes a través de la colección de documentos. Esto ayuda a evitar inconsistencias y errores de entrada de datos por los autores de un documento. Hay herramientas informáticas, que te ayudan a añadir metadatos sistemáticamente a documentos individuales, o a una colección entera de documentos.

 

Escribiendo Textos Equivalentes

La accesibilidad desde el punto de vista del contenido Web tiene dos significados:

 

  1. Que un usuario pueda obtener ese contenido.
  2. Que un usuario pueda comprender ese contenido.

 

Los textos equivalentes, son necesarios para los elementos no textuales, elementos multimedia, tablas, marcos, y scripts.

 

Pistas para escribir textos equivalentes

Cuando escribes textos equivalentes, estás proporcionando información sobre los elementos Web ala gente con deficiencias visuales o auditivas.

 

Un texto equivalente, transmite la misma información al usuario que el elemento original. ¡Proporciona suficientes detalles!.

 

Para disminuir la confusión al usuario, ten en cuenta las siguientes recomendaciones:

 
ENLACES

 

 

IMÁGENES Y ANIMACIONES

 

TABLAS Y OTROS ELEMENTOS QUE REQUIEREN DESCRIPCIONES LARGAS

Las tablas y otros elementos pueden requerir descripciones extensas.

 

 

Evitando textos de enlaces sin sentido

Uno de los principales problemas que los usuarios de lectores de pantalla encuentran, es el uso de textos de enlaces repetitivos, o sin sentido, que se usan para dirigir al usuario a contenido adicional del sitio.

 

Esto es un problema porque el lector de pantalla recogerá todo los enlaces que hay en una página. Luego, los enlaces se presentarán de una manera fácil de seleccionar para el usuario e ir a los recursos adicionales. Cuando el lector de pantalla hace esto, no presenta todo el texto asociado de alrededor del enlace.

 

Por esto las convenciones comunes que los diseñadores usan para la navegación visual, pueden causar problemas a los usuarios ciegos o con visión limitada.

 

Ejemplo del problema

La lista de abajo muestra algunos contenidos que aparecen en la  Web y cómo el uso de “clic aquí”, puede dificultar la navegación por el sitio a los usuarios de ayudas técnicas.

 

El texto en itálica representa el texto del enlace.

 

El producto “a”, es un Sustituto de la Fruta recomendado por muchos médicos destacados.

Para saber más sobre el producto “a”, haga clic aquí.

 

El producto “b”, es un Sustituto de la Carne recomendado por muchos médicos destacados.

Para saber más sobre el producto “b”, haga clic aquí.

 

El producto “c”, es un Sustituto de los Cereales recomendado por muchos médicos destacados.

Para saber más sobre el producto “c”, haga clic aquí.

 

En el ejemplo de arriba los lectores de pantalla presentarán el texto del enlace “clic aquí”, para todos los productos, a-c. Esto no tendría significado para alguien que no pudiera ver el emplazamiento del enlace.

 

La forma apropiada de crear el enlace, sería, haciendo que el texto del enlace fuera más descriptivo.

 

El texto en itálica representa el texto del enlace

 

El producto “a”, es un Sustituto de la Fruta recomendado por muchos médicos destacados.

Para saber más sobre el producto “a” haga clic aquí.

 

El producto “b”, es un Sustituto de la Carne recomendado por muchos médicos destacados.

Para saber más sobre el producto “b” haga clic aquí.

 

El producto “a”, es un Sustituto de los Cereales recomendado por muchos médicos destacados.

Para saber más sobre el producto “c” haga clic aquí.

 

En el texto del enlace de arriba toda la línea que contiene el clic aquí es ahora el enlace, permitiendo una fácil identificación de lo que el enlace realmente proporciona y a dónde va.

 

Imágenes y Accesibilidad

Las imágenes se usan por su significado y en muchos casos añaden significado debido a su colocación y función en la página. Con esta perspectiva necesitas proporcionar representaciones de texto alternativo completas y competentes para las imágenes, de manera que las personas con discapacidad, que no pueden ver la imagen, por cualquier razón, entiendan el significado completo de la imagen. Al desarrollar exclusivamente para seguir los estándares, puedes perder el sentido y la importancia de las normas. Si haces esto puede obtener la aprobación al usar herramientas de revisión automática pero tu sitio puede NO ser accesible.

Prácticas comunes pero ERRÓNEAS

Las siguientes prácticas no deben seguirse, pues consiguen exactamente el resultado contrario, al deseado con el uso del texto alternativo en las imágenes.

 

Haciendo marketing

Muchos desarrolladores, acostumbrarán usar las propiedades del texto alt de las imágenes, para introducir palabras clave para el marketing sobre su sitio Web, en vez de describir la imagen o su propósito. Esto, se hace introduciendo palabras clave, en vez del texto descriptivo. Por ejemplo, hay una imagen del logo de una empresa, en el texto alt debe leerse: alt=”Logo de tal empresa” y en vez de ese texto alternativo dice: alt=”palabra clave 1, palabra clave 2, palabra clave 3, frase clave 1, frase clave 2, frase clave 3...”

 

Esta práctica, debe cesar y deben corregirse todos los textos que han sido incorrectamente introducidos.

 

El nombre de la imagen como texto alternativo

En el pasado había muchos editores, o sistemas de generación dinámica, que ponían el nombre de la imagen como texto alternativo.

 

Ejemplo:

<img border="0" src="images/logo32-gif.gif" alt="logo32-gif.gif ">

 

Esto, claramente, no tiene ningún significado para la mayoría de las personas que ven la página. Todos los editores, necesitan ser informados sobre la forma correcta de añadir el texto alternativo. Cualquier texto alternativo incorrecto, debe ser actualizado.

 

Texto incompleto

Este también es un problema común. Para satisfacer los requisitos de accesibilidad, algunas instituciones se están apresurando a añadir el texto alternativo, sin tomarse el tiempo para hacerlo de forma que tenga sentido.

 

Ejemplo:

Hay una imagen que es un enlace a un servicio prioritario, la imagen consiste en texto 100% con un fondo degradado.

 

En el texto de la imagen se lee:

 

Sea más competitivo con un servicio Prioritario – Vaya allí ahora..

 

En el texto alternativo se lee:

 

Alt=”Servicio Prioritario

 

Aunque en este ejemplo se proporciona un texto alternativo, es incorrecto, ya que no representa claramente el significado de la imagen. Haría falta un mínimo esfuerzo, para modificar el texto alternativo, para representar con precisión la imagen y su significado intencional.

 

Una vez modificado, el texto alternativo se leería:

 

Alt=” ¡Sea más competitivo con un servicio Prioritario – Vaya allí ahora!”

 

Es fácil ver cómo esta diferencia en el contenido ha traído nuevo significado a la imagen. El esfuerzo asociado a alterar el texto y hacer “accesible” la imagen, ha sido mínimo. Un punto a tener en cuenta es, que cuando las tareas de accesibilidad se hacen correctamente desde el principio, no hay un costo relacionado con la creación y mantenimiento de un sitio accesible.

 

 

Hazlo legible

Muchos editores WYSIWYG o HTML, no proporcionan por defecto, opciones de revisión de la ortografía de las propiedades de los elementos como ALT. Teniendo esto en mente, recuerda verificar la ortografía de tus textos alternativos. Nota: es difícil leer “bus” desde “bsu”. Asegúrate de que tu texto es legible y tiene una ortografía correcta.

 

Errores Comunes a Evitar – Textos como Imágenes

El uso del texto alternativo para las imágenes, puede ser confuso, especialmente en cuanto a una imagen que está simplemente formada por texto. Es común que, los diseñadores hagan esto para proteger y controlar el aspecto del texto.

 

El problema ocurre, cuando el desarrollador del sitio o el experto en accesibilidad antepone, para el texto alternativo, el significado del diseño al significado proyectado. En el ejemplo de abajo, tienes la línea de la etiqueta de Ediciones HiSoftware como una imagen.

 

HiSoftware Publishing - Peel open the cover on one of these useful books

 

Diseño: HiSoftware Publishing Tag Line

Texto Alt:  HiSoftware Publishing - Peel open the cover of one of these useful books

 

Así que, si nosotros malinterpretamos los requisitos del texto alternativo y anteponemos el significado del diseño, al propósito que tiene la imagen para el visitante del sitio, no satisfaremos los requisitos.

 

Sigue una simple regla: Si la imagen contiene texto, entonces el mismo texto debe aparecer en el atributo para el texto alternativo.

Buenas prácticas

Aunque es fácil hacer una lista de malas prácticas, es más importante centrarse en los simples pasos asociados a proporcionar a las imágenes, texto alternativo accesible. El libro, ahora introducirá algunas buenas prácticas y sugerencias sobre proporcionar texto alternativo, significativo para las imágenes. A continuación una lista de prácticas recomendadas:

 

 

Algunas de las preguntas más comunes, en cuanto a proporcionar texto alternativo accesible, se enumeran a continuación:

 

 

¿Cuándo debo colocar el texto alternativo?

 

La aplicación del texto alternativo a las imágenes, debe hacerse tan pronto como se colocan en la página. Esto garantizará exactitud y eficiencia.

 

En mi organización, enviamos el contenido a diseñadores gráficos y ellos nos proporcionan una imagen, yo no siempre puedo expresar adecuadamente, en el texto alternativo, lo que los diseñadores quieren decir ¿qué me recomienda?

 

Esta es una buena pregunta, plantea un problema muy importante para las organizaciones que usan un grupo diferente para el contenido y otro para el diseño, para crear la página definitiva.

 

La respuesta obvia es, preguntar al diseñador ¿por qué esa imagen? y ¿por qué la usa?.

 

Pero más importante aún quizás es, que la compañía establezca la política de, que las imágenes necesitan que el diseñador envíe no sólo la imagen sino también el texto alternativo base.

 

En segundo lugar, el diseñador de la página, puede añadir más significado a través de la colocación de la imagen, así como de la función que cumple, o bien como enlace, o bien como mapa de imagen.

 

Mi imagen es transparente y no puede ser vista, se usa sólo para espaciar el contenido, como una herramienta de diseño. ¿Tengo que ponerle un texto alternativo?

 

La mejor práctica es, usar el texto alternativo con el valor de un espacio, porque así transmitirá eficazmente su función.

 

Ejemplo:

<img src="images/spacer.gif" alt=" ">

 

Mi imagen no puede ser descrita brevemente.¿Debo usar un texto alternativo mayor de 80 caracteres para describir mi imagen?

 

Cuando una imagen no puede ser descrita brevemente, usa el atributo longdesc. El atributo longdesc, te permite indicar la URL que contiene una descripción extensa de la imagen.

 

Esto podría ser útil, para las imagines que transmiten una información detallada al usuario, tales como los diagramas y mapas.

 


 

7. Tutorial: Corrigiendo Errores de Accesibilidad

Divider

 

En este capítulo

 

·        Aprende cómo hacer IMAGES Y FORMS accesibles

·        Aprende cómo hacer APPLETS y OBJECTS accesibles

·        Aprende cómo crear un D-Link y una IMAGE con el Atributo “longdesc”

·        Aprende cómo crear marcos accesibles

·        Aprende cómo crear apropiadamente una lista con viñetas que utiliza imagines para las viñetas

·        Aprende cómo crear enlaces de texto redundantes para los mapas de imagen del lado del servidor

·        Aprende cómo trabajar con el color

·        Aprende cómo producir mapas de imagen accesibles

·        Aprende por qué necesitas evitar usar BLINK y MARQUEE

·        Aprende cómo hacer una TABLE accesible

·        Aprende cómo corregir errores de accesibilidad comunes en los SCRIPT

·        Aprende cómo seguir el párrafo (o) de la Sección 508

·        Ejemplos completos para cada una de las tareas de la accesibilidad

 

Divider

 

 

 

Esta sección del libro, proporciona directrices y ejemplos diseñados, para enseñar al lector cómo desarrollar contenido accesible. La sección, está organizada siguiendo las siguientes convenciones:

 

Sección + Pauta (Section 508 / W3C)

 

HTML actual – original HTML de ejemplo

HTML corregido – HTML accesible

 

Nota: Si tienes más preguntas sobre las pautas en sí, o sobre qué discapacidades están tratadas por una pauta específica, mira por favor el Capítulo Dos.

 

Para este tutorial, miraremos diferentes páginas, en Internet, estas páginas se diseñan para cubrir defectos de accesibilidad específicos. Aquellos que estén desarrollando un sitio, para cumplir con las normas de la Sección 508, o con las directrices del W3C, encontrarán esta sección valiosa.

 

Usando el tutorial

El tutorial, puede usarse como ejercicio para introducirte en la Sección 508, o las directrices de accesibilidad del W3C/WCAG. También puede usarse como guía de referencia general, sobre cómo corregir problemas específicos de accesibilidad.

 

Si eres nuevo en la creación de contenido accesible, es recomendable que lo uses como ejercicio. Una vez hayas completado los ejemplos, estarás listo para aplicar a tu sitio Web lo que has aprendido.

 

 

 


Sección 1 – Sección 508 (a) Directrices W3C 1.1

El archivo de demostración para esta sección, puede descargarse desde Internet en:

 

http://www.hisoftware.com/uaccess/fpdemo1.htm

 

Recuerda que, para seguir el ejercicio con tu editor de páginas Web, debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro siguiendo los siguientes pasos:

 

1        Abre la página de arriba en tu navegador

2        Selecciona Archivo |Guardar cómo...

3        Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

4        Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluidos en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Abre ahora en tu editor de páginas Web el archivo guardado. Los problemas de accesibilidad que quedarán cubiertos en esta sección son:

 

Se proporcionará un texto equivalente para cada elemento no textual (Ej.: vía “alt”, “longdesc”, o en el contenido del elemento).

 

·        Todos los elementos IMG, requieren contener, o bien el atributo 'alt', o bien el atributo  'longdesc'.

·        Todos los elemento INPUT, requieren contener el atributo 'alt', o usar una LABEL.

·        Todos los elementos OBJECT, requieren contener el elemento ‘content’.

·        Todos los elementos APPLET, requieren contener tanto el elemento ‘content’, como el atributo ‘alt’.

·        Todos los elementos IFRAME, requieren contener el elemento ‘content’.

·        Todos los elementos ANCHOR, que se encuentren dentro de elementos MAP, requieren contener el atributo ‘alt’.

·         Todos los elementos AREA, requieren contener el atributo ‘alt’. 


1.  Las Imágenes sencillas requieren texto alternativo

La primera imagen representa “reciclado”. El propósito de la imagen es, simplemente, añadir el significado de reciclaje. La norma establece que, todos los elementos IMG requieren contener o bien el atributo ‘alt’, o el atributo ‘longdesc’.

 

 

Conservation Symbol

 

Esta imagen requiere texto alternativo.

 

HTML actual – EJEMPLO 1

En el código HTML actual, falta el atributo alt.

 

<IMG border="0" src="../images/j0293240.gif" width="165" height="122">

 

HTML corregido – EJEMPLO 1

En el código HTML corregido, se utiliza el atributo alt.

 

<IMG border="0" src="../images/j0293240.gif" width="165" height="122" alt=”Icono de Reciclado”>


2. Misma imagen: también sirve como enlace de navegación

Este ejemplo, muestra una imagen dedicada a ser un elemento de navegación. El propósito es, proporcionar un enlace de navegación a la página principal de HiSoftware. La norma establece que, todos los elementos IMG requieren contener, o bien el atributo ‘alt’, o bien el atributo ‘longdesc’.

 

HTML actual – EJEMPLO 2

En el código HTML actual, falta el atributo alt.

 

<IMG border="0" src="../images/j0293240.gif" width="165" height="122">

 

HTML corregido – EJEMPLO 2

En el código HTML corregido, se usa el atributo alt y el texto alternativo también muestra el propósito de la imagen.

 

<a href="http://www.hisoftware.com/">

<IMG border="0" src="../images/j0293240.gif"

alt="Símbolo de reciclado y enlace a la página principal de HiSoftware" width="165" height="122"></a>

 

Nota: Para crear un texto alternativo eficaz, para tus elementos no textuales, asegúrate de:

 

·        Seguir la guía que hay en este libro para redactar texto alternativo

·        Usar un revisor ortográfico

3. Una imagen que requiere una descripción larga

Este ejemplo demuestra el uso de “longdesc”. Sería difícil describir esta imagen sólo con el texto alternativo. En ese caso, debe usarse una descripción larga. La norma establece que, todos los elementos IMG requieren contener bien el atributo ‘alt’, o bien el atributo ‘longdesc’.

 

 

HTML actual – EJEMPLO 3

En el código HTML actual, falta el atributo alt y no hay atributo longdesc.

 

<Img border="0" src="../../images/j0301076.gif" width="192" height="192"></font></p>

 

HTML corregido – EJEMPLO 3

En el código HTML corregido, se usan los atributos alt y logndesc. Además de ellos, se usa también un d-link.

 

<Img border="0" src="../../images/j0301076.gif" alt="Objetos relacionados con el Espacio – Véase la descripción larga" width="192" height="192" longdesc="AboutSpace.html">

<A  href="AboutSpace.html">[D]</A>

4. Objeto hoja de cálculo de MS Office

El ejemplo cuatro, demuestra la codificación apropiada para hacer accesible un objeto ActiveX. El objeto es un componente Web de Microsoft Office. La norma establece que, TODOS los elementos OBJECT requieren contener el elemento content.

 

HTML actual – EJEMPLO 4

Falta el elemento content en el código HTML actual.

 

<object classid="clsid:0002E551-0000-0000-C000-000000000046" id="Spreadsheet1" width="319" height="249">

<param name="DataType" value="XMLDATA">

</object>

 

HTML corregido – EJEMPLO 4

En el código HTML corregido, el elemento content está presente.

 

<object classid="clsid:0002E551-0000-0000-C000-000000000046" id="Spreadsheet1" width="319" height="249">

<param name="DataType" value="XMLDATA">

 

Su navegador no soporta este objeto.

Este es un objeto que representa datos que están también disponibles en:  http://www.hisoftware.com/uaccess/demo1.htm

 

</object>


5. Applet

El ejemplo cinco, demuestra la codificación apropiada para hacer accesible un applet de Java. La norma establece que, todos los elementos APPLET requieren contener un atributo alt.

 

HTML actual – EJEMPLO 5

En el HTML actual, faltan el elemento content y el atributo alt.

 

<applet width="128" height="128"

code=""

codebase="http://Example.js.class/">

</applet>

 

HTML corregido – EJEMPLO 5

En el código HTML corregido, están presentes el elemento content y el atributo alt.

 

<applet width="128" height="128"

code=""  alt=”Descripción de mi applet”

codebase="http://Example.js.class/">

 

Este es un applet para la navegación. Una forma alternativa de navegación puede encontrarse en: http://www.hisoftware.com/uaccess/navigate.html

 

</applet>


6. Elementos Input (también en 508 (n))

El ejemplo seis, demuestra la codificación apropiada para hacer accesible un formulario HTML. La norma establece que, todos los elementos INPUT requieren contener el atributo ‘alt’, o usar una LABEL.

 

HTML actual – EJEMPLO 6

En el código HTML actual, no está presente el texto alternativo para el elemento input.

 

 <Form method="POST" action="-WEBBOT-">

<Input type="text" name="T1" size="20">

</form>

 

HTML corregido – EJEMPLO 6

En el código HTML corregido, está presente el texto alternativo para el elemento input.

 

<Form method="POST" action="-WEBBOT-">

<Input type="text" name="T1" size="20" alt=”Nombre”> </form>

 

Añadiendo LABELS: En el código HTML corregido, está presente el texto alternativo para el elemento input y se ha añadido la etiqueta LABEL.

 

<Form method="POST" action="-WEBBOT-">

<Label for="T1"> Nombre de usuario: </label>

<Input type="text" name="T1" size="20" alt=”Nombre”> </form>

 

Nota: Usando ambos, el texto alternativo y la etiqueta label, incrementas la usabilidad de tu formulario.

7. Inline Frame (IFRAME)

El ejemplo siete, demuestra la codificación apropiada para hacer accesible los marcos en línea (Inline frame). Los “inline frames”, resultan ser una excelente alternativa a TABLE o FRAME. La norma establece que, todos los elementos IFRAME requieren contener el elemento ‘content’.

 

HTML actual – EJEMPLO 7

En el código HTML actual, el elemento content para el IFRAME no está presente.

 

<Iframe name="I1" SRC="sample.htm">

</iframe>

 

HTML corregido – EJEMPLO 7

En el HTML corregido, el elemento content está presente.

 

<Iframe name="I1" SRC="sample.htm">

 

Su navegador no soporta inline frames, o está configurado actualmente para no mostrar los inline frames. El contenido puede verse en el código fuente de la página actual: http://www.hisoftware.com/sample.htm

 

</iframe>


8. Ejemplo de Mapas de Imagen (Section 508 (f))

El ejemplo ocho, demuestra la codificación apropiada para un Mapa de Imagen. La norma establece que, todos los elementos AREA requieren contener el atributo ‘alt’. 

 

HTML actual – EJEMPLO 8

En el código HTML actual, no están presentes ni el texto alternativo para los elementos area ni el texto alternativo para la imagen.

<map name="FPMap0">

<area href="#Go Here for Links!!!" shape="rect" coords="13, 5, 172, 75">

<area href="#Go Here for Links!!!" shape="rect" coords="8, 92, 119, 187">

<area href="#Go Here for Links!!!" shape="rect" coords="125, 91, 191, 180">

</map>

<img border="0" src="../../images/j0301076.gif" usemap="#FPMap0" width="192" height="192">

 

HTML corregido – EJEMPLO 8

En el código HTML corregido, están presentes el texto alternativo para los elementos area y para la imagen.

<map name="FPMap0">

<area href="#Go Here for Links!!!" shape="rect" coords="13, 5, 172, 75" alt=”Mi texto alternativo”>

<area href="#Go Here for Links!!!" shape="rect" coords="8, 92, 119, 187" alt=” Mi texto alternativo”

<area href="#Go Here for Links!!!" shape="rect" coords="125, 91, 191, 180" alt=” Mi texto alternativo”>

</map>

<img border="0" src="../../images/j0301076.gif" usemap="#FPMap0" width="192" height="192" alt=”Imagen del espacio”>

9. Ejemplo de imágenes como viñetas

El ejemplo nueve, demuestra la codificación apropiada para hacer accesible una lista con bolos o viñetas, en la que los bolos son realmente imágenes. La norma establece que, todos los elementos IMG requieren contener, o bien el atributo ‘alt’, o bien el atributo ‘longdesc’.

 

HTML actual – EJEMPLO 9

En el HTML actual, hay cinco productos enumerados, esos productos tienen una imagen antes del nombre del producto, para crear una elegante lista con viñetas.

 

<p>HiSoftware Accessibility Products</p>

<p><img border="0" src="BD10263_.GIF">

Understanding Accessibility Book</p>

 

<p><img border="0" src="BD10263_.GIF">

AccVerify</p>

 

<p><img border="0" src="BD10263_.GIF">

AccRepair</p>

 

<p><img border="0" src="BD10263_.GIF">

AccMonitor</p>

 

<p><img border="0" src="BD10263_.GIF">

AccessibilityWATCH</p>

 

 

HTML corregido – EJEMPLO 9

Las directrices establecen que, el propósito de la imagen es muy importante, el propósito en este caso no tiene nada que ver con la representación visual, y es solamente un bolo. Esta es, definitivamente, una excepción a las normas establecidas previamente. La excepción es que: describir la imagen en el texto alternativo podría no ser eficaz, en vez de ello, describiremos el propósito.

 

HiSoftware Accessibility Products

<p><img border="0" src="BD10263_.GIF" alt=”*”>

Understanding Accessibility Book</p>

 

<p><img border="0" src="BD10263_.GIF" alt=”*”>

AccVerify</p>

 

<p><img border="0" src="BD10263_.GIF" alt=”*”>

AccRepair</p>

 

<p><img border="0" src="BD10263_.GIF" alt=”*”>

AccMonitor</p>

 

<p><img border="0" src="BD10263_.GIF" alt=”*”>

AccessibilityWATCH</p>

 

En este caso, el asterisco describe claramente el valor y propósito de la imagen como bolo o viñeta. 


Sección 2 – Sección 508 (b) Directrices W3C 1.1

Esta sección no contiene archivos de demostración, sino que simplemente, enumera pistas para cumplir con la Sección 508 (b), sobre los equivalentes alternativos, para cualquier presentación multimedia, que deben estar sincronizados con la presentación.

 

Archivos de Audio

Existen diferentes tipos de archivos de audio, pero todos ellos requieren equivalentes en formato texto. Ten en cuenta los siguientes tipos de archivos de audio:

 

 

 

CREANDO ARCHIVOS DE AUDIO ACCESIBLES

Tienes varias opciones si necesitas crear texto equivalente para sonidos y archivos de audio.

 

Texto Equivalente Estático

Puedes presentar texto estático, o que no se mueve, durante la ejecución del sonido. Esta técnica es más eficaz, para los sonidos que requieren una entrada por parte del usuario, tales como los sonidos autónomos o los interactivos.

 

Un sonido autónomo, es un archivo que el usuario ejecuta mediante alguna acción o comando. Por ejemplo, haciendo clic en un elemento, se ejecuta un archivo sonoro.

 

El audio interactivo, es sonido que suena debido a ha llevado a cabo una acción o comando. Por ejemplo, cualquier error o acción interactiva, que dé como resultado una alerta o aviso sonoro basándose en la acción del usuario, debe tener también un equivalente visual.

 

Enlace a la Trascripción en Texto.

Puedes proporcionar un enlace a una trascripción en texto, de un archivo sonoro. Esta técnica es más eficaz para los archivos de audio autónomos, tales como la música.

 

Cuando proporciones un enlace a la trascripción en texto, coloca el enlace cerca de la parte superior de la página, marco o celda de la tabla que contiene el enlace al sonido. Cuando crees una trascripción en texto, usa una descripción que tenga en cuenta tanto los sonidos hablados como los no hablados, y asegúrate de diferenciarlos.

 

Por ejemplo, supón que estás viendo una página sobre la historia de los Estados Unidos. Cerca de la parte superior de la página hay dos enlaces:

 

 

Sin embargo, si la página ejecuta automáticamente el himno nacional, debe haber alguna indicación para el usuario, de que se está usando ese sonido. La mejor técnica para los sonidos que se ejecutan automáticamente, es un texto estático creado mediante scripting.

 


Sección 3 – Sección 508 (c) Directrices W3C  2.1

El archivo de demostración para esta sección puede descargarse desde Internet en:

 

http://www.hisoftware.com/uaccess/fpdemo3.htm

 

Recuerda que, para seguir el ejercicio con tu editor de páginas Web debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro siguiendo los siguientes pasos:

 

1        Abre la página de arriba en tu navegador

2        Selecciona Archivo |Guardar cómo...

3        Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

4        Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluidos en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Ahora, abre en tu editor de páginas Web el archivo guardado y estaremos listos para comenzar. El problema de accesibilidad que cubriremos en la sección tres es:

 

Las páginas web, deben diseñarse de manera que toda la información transmitida por el color, esté también disponible sin color, por ejemplo por el contexto o en el marcado.

 

1. Texto coloreado como única manera para determinar un paso requerido

El ejemplo uno demuestra un uso incorrecto del color. Se usa el color para comunicar la navegación al usuario. En este ejemplo, el usuario tiene que llevar a cabo una acción, basándose en el texto coloreado. Esta, puede ser una práctica de diseño deseable, sin embargo, puede no significar nada para alguien con una deficiencia visual, que le impide a él o a ella identificar el color.

 

HTML actual – EJEMPLO 1

En el HTML actual, el color es la única manera de determinar cómo ir al producto correcto.

 

Gracias por su interés en nuestros productos. Para

quienes tengan:</font>

<p><font size="2" face="Verdana">El producto A, siga las instrucciones que están en rojo</font></p>

<p><font size="2" face="Verdana">El producto B, siga las instrucciones que están en verde</font></p>

<p><font color="#FF0000" size="2" face="Verdana">Registre su producto aquí</font></p>

<p><font color="#008000" size="2" face="Verdana">Registre su producto aquí</font></p>

 

Información

Este código HTML podría corregirse, simplemente proporcionando un texto más descriptivo. El desarrollar páginas accesibles no te impide el uso del color. Simplemente, debes tener en cuenta que, un visitante de un sitio Web, puede ser ciego o tener ceguera al color. Si este es el caso, entonces, los avisos visuales no le permitirán al usuario completar el proceso que has diseñado.

 
HTML corregido – EJEMPLO 1

En el HTML corregido, el color ya no es la única vía para determinar la acción correcta.

 

Gracias por su interés en nuestros productos. Para

quienes tengan:</font>

<p><font size="2" face="Verdana">El producto A, sigan las instrucciones marcadas como “A” que están en rojo</font></p>

<p><font size="2" face="Verdana">El producto B, siga las instrucciones marcadas como “B” que están en verde</font></p>

<p><font color="#FF0000" size="2" face="Verdana">Registre su producto “A” aquí</font></p>

<p><font color="#008000" size="2" face="Verdana">Registre su producto “B” aquí</font></p>


2. Campos de formularios requeridos

El ejemplo dos, demuestra un mal uso del color. Este ejemplo, usa texto coloreado, para comunicar qué campos de un formulario se requiere sean rellenados para su envío con éxito.

 

HTML actual – EJEMPLO 2

En el código HTML actual, el color es la única manera de determinar, qué campos son requeridos para el envío del formulario.

 

<form method="POST" action="--WEBBOT--">

  <p>Los campos obligatorios están en ROJO</p>

  <p>Nombre de usuario <input type="text" name="T1" size="20"></p>

  <p>Dirección <input type="text" name="T2" size="20"></p>

  <p><font color="#FF0000">Dirección de correo electrónico</font><input type="text" name="T3" size="20"></p>

  <p><input type="submit" value="Submit" name="B1"></p>

</form>

 
HTML corregido – EJEMPLO 2

En el código HTML corregido, el color no es la única vía de determinar, qué campos son requeridos para el envío del formulario.

 

<form method="POST" action="--WEBBOT--">

 <p>Los campos obligatorios están en ROJO y marcados con un *</p>

<p>Nombre

<input type="text" name="T1" size="20"></p>

<p>Dirección

<input type="text" name="T2" size="20"></p>

<p><font color="#FF0000">* Dirección de correo electrónico</font>

<input type="text" name="T3" size="20"></p>

  <p>

<input type="submit" value="Submit" name="B1">

</p>

</form>

 

 

Aplicar lo que has aprendido

En el ejemplo de arriba, pude realizarse el rellenado del formulario sin ninguna dependencia del color. Sin embargo, el formulario en sí no es accesible. ¡Usa el texto alternativo y las etiquetas ‘label’, para hacer accesible el formulario!.


Sección 4 – Sección 508 (e) Directrices W3C  1.2

El archivo de demostración para esta sección, puede descargarse desde Internet en:

 

http://www.hisoftware.com/uaccess/fpdemo4.htm

 

Recuerda que, para seguir el ejercicio con tu editor de páginas Web, debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro, siguiendo los siguientes pasos:

 

5        Abre la página de arriba en tu navegador

6        Selecciona Archivo |Guardar cómo...

7        Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

8        Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluido en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Ahora, abre en tu editor de páginas Web el archivo guardado y estaremos listos para comenzar. El problema de accesibilidad que cubriremos en la sección cuatro es:

 

Deben proporcionarse enlaces en formato texto, redundantes con cada región activa, de un mapa de imagen del lado del servidor.


1. Proporciona Enlaces redundantes en formato Texto para los Mapas de Imagen del lado del servidor

El ejemplo uno, demuestra cómo usar enlaces redundantes en formato texto, para hacer accesible un mapa de imagen del lado del servidor.

 

HTML actual

 

<A href="http://www.hisoftware.com/scripts/imagemap/accessmap">

<IMG src="../../images/ACCVerifybut88.gif"

     ismap width="88" height="31"></A>

 

Información

Recuerda, al corregir este mapa de imagen, tendrás que poner texto alternativo a la imagen.

 

HTML corregido

<A href="http://www.hisoftware.com/scripts/imagemap/accessmap">

<IMG src="../../images/ACCVerifybut88.gif"

alt="Consigue el logo de aprobado por AccVerify (Siguen enlaces en formato texto)"

     ismap width="88" height="31"></A></font>

<p> [<A href="../access/vindex.html">

AccVerify</A>]&nbsp;</font></p>

<p> [<A href="../access/approved.html">

Significado del Logo de Aprobado</A>]</p>


Seción 5 – Sección 508 (g&h) Directrices W3C  5.1 &5.2

El archivo de demostración para esta sección, puede descargarse desde Internet en:

 

http://www.hisoftware.com/uaccess/fpdemo5.htm

 

Recuerda que, para seguir el ejercicio con tu editor de páginas Web, debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro, siguiendo los siguientes pasos:

 

9        Abre la página de arriba en tu navegador

10   Selecciona Archivo |Guardar cómo...

11   Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

12   Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluido en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Ahora, abre en tu editor de páginas Web el archivo guardado y estaremos listos para comenzar. El problema de accesibilidad que cubriremos en la sección cinco es:

 

(g) / 5.1

·        Todas las celdas en la primera fila, deben ser celdas de encabezado de columna

·        Todas las celdas en la primera columna, deben ser celdas de encabezado de fila

·        Las tablas de datos, deben tener una leyenda

 

 

(h) / 5.2

 


1. Las Filas y Columnas, deben identificarse en las Tablas de Datos

El ejemplo uno, demuestra cómo añadir encabezados a las filas y columnas.

 

HTML actual – EJEMPLO 1

El código HTML actual del ejemplo, no tiene identificados los encabezados de fila y columna.

 

<table border="1" cellpadding="4" cellspacing="0" width="100%">

  <tr>

    <td width="25%">Hora del día</td>

    <td width="25%">Comida</td>

    <td width="25%">Bebida</td>

    <td width="25%">Tiempo asignado para la comida</td>

  </tr>

  <tr>

    <td width="25%">06:00</td>

    <td width="25%">Huevos</td>

    <td width="25%">Zumo</td>

    <td width="25%">30 minutos</td>

  </tr>

  <tr>

    <td width="25%">11:00</td>

    <td width="25%">Sandwich</td>

    <td width="25%">Agua</td>

    <td width="25%">30 minutos</td>

  </tr>

</TABLE>

 

 
 
HTML corregido – EJEMPLO 1

Para corregir el código HTML, añadimos encabezados de Fila y Columna

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

 

  <TR>

    <TH width="25%">Hora del día</TH>

    <TH width="25%">Comida</TH>

    <TH width="25%">Bebida</TH>

    <TH width="25%">Tiempo asignado para la comida</TH></TR>

  <TR>

    <TD width="25%">06:00</TD>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <TD width="25%">11:00</TD>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR></TABLE>


2. Todas las tablas de datos deben tener una leyenda

El ejemplo dos, demuestra cómo añadir una CAPTION (leyenda) a la tabla de datos.

 

HTML actual – EJEMPLO 2

El código HTML actual carece del elemento CAPTION. Recuerda que la CAPTION debe ser visible en la pantalla.

 

<TABLE cellSpacing=0 cellPadding=4 width=”100%” border=1>

 <TR>

    <TH width=”25%”>Hora del día</TH>

    <TH width=”25%”>Comida</TH>

    <TH width=”25%”>Bebida</TH>

    <TH width=”25%”>Tiempo asignado para la comida</TH></TR>

  <TR>

    <TD width=”25%”>06:00</TD>

    <TD width=”25%”>Huevos</TD>

    <TD width=”25%”>Zumo</TD>

    <TD width=”25%”>30 minutos</TD></TR>

  <TR>

    <TD width=”25%”>11:00</TD>

    <TD width=”25%”>Sandwich</TD>

    <TD width=”25%”>Agua</TD>

    <TD width=”25%”>30 minutos</TD></TR>

  <TR>

    <TD width=”25%”>15:00</TD>

    <TD width=”25%”>Filete</TD>

    <TD width=”25%”>Agua</TD>

    <TD width=”25%”>1 Hora</TD></TR></TABLE>

 

 

HTML corregido – EJEMPLO 2

El código HTML corregido ahora tiene añadida la CAPTION, justo debajo del elemento TABLE.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

  <CAPTION>Tabla con el menú y tiempo asignado para comer</CAPTION>

 

  <TR>

    <TH width="25%">Hora del día</TH>

    <TH width="25%">Comida</TH>

    <TH width="25%">Bebida</TH>

    <TH width="25%">Tiempo asignado para la comida</TH></TR>

  <TR>

    <td width="25%">06:00</td>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <td width="25%">11:00</td>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <td width="25%">15:00</td>

    <TD width="25%">Filete</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">1 Hora</TD></TR></TABLE>


3. Todas las celdas de encabezado de fila y columna requieren contener el atributo scope

El ejemplo tres, demuestra cómo añadir el atributo scope.

 

HTML actual – EJEMPLO 3

El código HTML actual del ejemplo no contiene el atributo scope.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

  <TR>

    <TD width="25%">Hora del día</TD>

    <TD width="25%">Comida</TD>

    <TD width="25%">Bebida</TD>

    <TD width="25%">Tiempo designado para la comida</TD></TR>

  <TR>

    <TD width="25%">06:00</TD>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <TD width="25%">11:00</TD>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR></TABLE>

 


HTML corregido – EJEMPLO 3

El código HTML, está modificado y ahora contiene el atributo scope.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

 

  <TR>

    <TH scope="col" width="25%">Hora del día</TH>

    <TH scope="col" width="25%">Comida</TH>

    <TH scope="col" width="25%">Bebida</TH>

    <TH scope="col" width="25%">Tiempo asignado para la comida</TH></TR>

  <TR>

    <TD width="25%">06:00</TD>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <TD width="25%">11:00</TD>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR></TABLE>


4. Todas las celdas de DATOS, requieren contener el atributo header

El ejemplo cuatro, demuestra el uso correcto del atributo header.

 

HTML actual – EJEMPLO 4

El código HTML actual del ejemplo, no contiene atributos header.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

  <TR>

    <TD width="25%">Hora del día</TD>

    <TD width="25%">Comida</TD>

    <TD width="25%">Bebida</TD>

    <TD width="25%">Tiempo asignado para la comida</TD></TR>

  <TR>

    <TD width="25%">06:00</TD>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <TD width="25%">11:00</TD>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR></TABLE>

 


HTML corregido – EJEMPLO 4

El HTML  corregido, tiene los atributos header requeridos.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

<TR>

    <TH id="header5" width="25%">Hora del día</TH>

    <TH id="header6" width="25%">Comida</TH>

    <TH id="header7" width="25%">Bebida</TH>

    <TH id="header8" width="25%">Tiempo asignado para la comida</TH></TR>

  <TR>

    <TD headers="header5" width="25%">06:00</TD>

    <TD headers="header6"  width="25%">Huevos</TD>

    <TD headers="header7"  width="25%">Zumo</TD>

    <TD headers="header8" width="25%">30 minutos</TD></TR>

  <TR>

    <TD headers="header5" width="25%">11:00</TD>

    <TD headers="header6"  width="25%">Sandwich</TD>

    <TD headers="header7"  width="25%">Agua</TD>

    <TD headers="header8" width="25%">30 minutos</TD></TR></TABLE>


5. Todas las celdas de DATOS, requieren contener el atributo AXIS

El ejemplo cinco, demuestra el uso correcto del atributo axis.

 

HTML actual – EJEMPLO 5

El actual código HTML de ejemplo, no contiene el atributo axis.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

  <TR>

    <TD width="25%">Hora del día</TD>

    <TD width="25%">Comida</TD>

    <TD width="25%">Bebida</TD>

    <TD width="25%">Tiempo asignado para la comida</TD></TR>

  <TR>

    <TD width="25%">06:00</TD>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <TD width="25%">11:00</TD>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR></TABLE>

 


HTML corregido – EJEMPLO 5

El código HTML corregido, contiene los atributos axis.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

 

  <TR>

    <TH id="header9" width="25%">Hora del día</TH>

    <TH id="header10" width="25%">Comida</TH>

    <TH id="header11" width="25%">Bebida</TH>

    <TH id="header12" width="25%">Tiempo asignado para la comida</TH></TR>

  <TR>

    <TD axis="header9" width="25%">06:00</TD>

    <TD axis="header10" width="25%">Huevos</TD>

    <TD axis="header11" width="25%">Zumo</TD>

    <TD axis="header12" width="25%">30 minutos</TD></TR>

  <TR>

    <TD axis="header9" width="25%">11:00</TD>

    <TD axis="header10" width="25%">Sandwich</TD>

    <TD axis="header11" width="25%">Agua</TD>

    <TD axis="header12" width="25%">30 minutos</TD></TR></TABLE>


6. Cuando se usan elementos de agrupamiento, todas las filas requieren estar agrupadas

El ejemplo seis, demuestra el uso correcto del agrupamiento de filas.

 

HTML actual – EJEMPLO 6

El ejemplo HTML actual, no usa el agrupamiento de filas.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

<TR>

    <TD width="25%">Hora del día</TD>

    <TD width="25%">Comida</TD>

    <TD width="25%">Bebida</TD>

    <TD width="25%">Tiempo asignado para la comida</TD></TR>

  <TR>

    <TD width="25%">06:00</TD>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <TD width="25%">11:00</TD>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR></TABLE>

.


HTML corregido – EJEMPLO 6

El código corregido HTML del ejemplo, usa el agrupamiento de filas requerido.

 

<TABLE cellSpacing=0 cellPadding=4 width="100%" border=1>

<thead>

<TR>

    <TH width="25%">Hora del día</TH>

    <TH width="25%">Comida</TH>

    <TH width="25%">Tiempo asignado para la comida</TH></TR>

</thead>

<TBODY>

<TR>

    <TD width="25%">06:00</TD>

    <TD width="25%">Huevos</TD>

    <TD width="25%">Zumo</TD>

    <TD width="25%">30 minutos</TD></TR>

  <TR>

    <TD width="25%">11:00</TD>

    <TD width="25%">Sandwich</TD>

    <TD width="25%">Agua</TD>

    <TD width="25%">30 minutos</TD></TR>

 </TBODY>  

 </TABLE>


Sección 6 – Sección 508 (i) Directrices W3C  1.1 &12.1

El archivo de demostración para esta sección, puede descargarse desde Internet en:

 

Ejemplo inicial: http://www.hisoftware.com/uaccess/frames/FPDemoFrames.htm

Ejemplo arreglado:

http://www.hisoftware.com/uaccess/frames/FPDemoFramesFixed.htm

 

Recuerda que, para seguir el ejercicio con tu editor de páginas Web, debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro, siguiendo los siguientes pasos:

 

13   Abre la página de arriba en tu navegador

14   Selecciona Archivo |Guardar cómo...

15   Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

16   Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluidos en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Ahora, abre en tu editor de páginas Web el archivo guardado y estaremos listos para comenzar.

 

El problema de accesibilidad que cubriremos en la sección seis es:

 


1. Todos los elementos Frame, requieren contener el atributo title

El ejemplo uno, demuestra cómo usar los atributos title de los FRAME.

 

HTML actual – EJEMPLO 1

El código HTML actual, no incluye el atributo title

 

<FRAMESET

cols="40%,60%">

<FRAME src="left_frame.htm">

<FRAME src="right_frame.htm" >

</FRAMESET>

 

HTML – EJEMPLO 1

El código HTML corregido, incluye el atributo title

 

<FRAMESET

cols="40%,60%"

title="Nuestra línea de productos">

<FRAME src="left_frame.htm"

title="Marco izquierdo:

Menú de navegación">

<FRAME src="right_frame.htm"

title="Marco derecho: Cuerpo del texto">

</FRAMESET>


2. Todos los elementos FRAMESET, requieren contener el elemento noframes

El ejemplo dos, demuestra cómo usar el elemento NOFRAMES.

 

HTML actual – EJEMPLO 2

El código HTML actual, no aplica el elemento NOFRAMES.

 

<FRAMESET

cols="40%,60%"

title="Nuestra línea de productos">

<FRAME src="left_frame.htm">

<FRAME src="right_frame.htm" >

</FRAMESET>

 

HTML corregido – EJEMPLO 2

El código HTML corregido, aplica el elemento NOFRAMES.

 

<FRAMESET

cols="40%,60%"

title="Nuestra línea de productos">

<FRAME src="left_frame.htm">

<FRAME src="right_frame.htm" >

<NOFRAMES>

 Esta página usa marcos, pero su

 buscador o navegador Web no los soporta.

  <A href="products.html" title="Enlace a productos">

     Seleccione este enlace para ir a la página de productos</A>

</NOFRAMES>

</FRAMESET>

 

HTML con el elemento NOFRAMES añadido y con el atributo title

El código HTML de abajo, está corregido y hace que los marcos sean completamente accesibles.

.

 

<FRAMESET

cols="40%,60%"

title="Nuestra línea de productos">

<FRAME src="left_frame.htm"

title="Marco izquierdo:

Menú de navegación">

<FRAME src="right_frame.htm"

title="Marco derecho: Cuerpo de texto">

<NOFRAMES>

 Esta página usa marcos, pero su

 Buscador o navegador Web puede que no lo soporte.

  <A href="products.html"

title="Enlace a productos">  

     Seleccione este enlace para ir a la página de productos</A>

</NOFRAMES>

</FRAMESET>


Sección 7 – Sección 508 (j) Directrices W3C  7.1

El archivo de demostración para esta sección, puede descargarse desde Internet en:

 

http://www.hisoftware.com/uaccess/FPDemo6.htm

 

Recuerda qu, para seguir el ejercicio con tu editor de páginas Web, debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro siguiendo los siguientes pasos:

 

17   Abre la página de arriba en tu navegador

18   Selecciona Archivo |Guardar cómo...

19   Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

20   Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluido en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Ahora abre el archivo guardado con tu editor de páginas Web y estaremos listos para comenzar. Esta sección cubre las formas más comunes de hacer que la pantalla parpadee. Si quieres más información sobre este requerimiento, ve al Capítulo Dos de este libro. Los problemas de accesibilidad cubiertos por la sección siete son:

 

1. No uses el elemento BLINK

El ejemplo uno demuestra alternativas al elemento BLINK.

 

HTML actual – EJEMPLO 1

El código HTML actual, usa el elemento BLINK para que el agente de usuario (navegador) parpadee repetidamente (que el mensaje destelle), dando a entender al usuario la importancia del texto.

 

<blink>Preste atención a esto</blink>

 

 

HTML corregido – EJEMPLO 1

El código HTML corregido, no usa el elemento BLINK y en vez de ello aplica otros métodos de formateo, para mostrar la importancia del mensaje.

 

<strong><u>Preste atención a esto</u></strong>


2. No use el elemento MARQUEE

El ejemplo dos, demuestra una alternativa para el elemento MARQUEE.

 

HTML actual – EJEMPLO 2

El código HTML actual, usa el elemento MARQUEE para desplazar un mensaje a través de la pantalla, con la intención de captar la atención del usuario.

 

<marquee align="bottom" bgcolor="#C0C0C0" direction="right" scrolldelay="91" width="100%" height="16">

El uso

de ‘Marquee’ puede causar que falle el test de accesibilidad

</marquee>

 

HTML corregido – EJEMPLO 2

El código HTML corregido, usa métodos alternativos para hacer que el texto capte la atención del usuario.

 

<em><strong><u>

El uso de ‘Marquee’ puede causar que falle el test de accesibilidad

</u></strong></em>


Sección 8 – Sección 508 (l)&(m) Directrices W3C  6.3

El archivo de demostración para esta sección, puede descargarse desde Internet en:

 

http://www.hisoftware.com/uaccess/FPDemo7.htm

 

Recuerda que, para seguir el ejercicio con tu editor de páginas Web, debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro siguiendo los siguientes pasos:

 

21   Abre la página de arriba en tu navegador

22   Selecciona Archivo |Guardar cómo...

23   Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

24   Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluidos en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Ahora, abre en tu editor de páginas Web el archivo guardado y estaremos listos para comenzar. Los problemas de accesibilidad que cubriremos en la sección ocho son:

 

Asegúrese de que las páginas pueden usarse cuando los scripts, applets, u otros objetos de programación están apagados o no son soportados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible.

 

·        Los anclajes, requieren que no se use javascript para el enlace diana, cuando no está presente el elemento NOSCRIPT en el cuerpo del documento.

·        Los elementos AREA, requieren que no se use javascript para el enlace diana cuando no está presente el elemento NOSCRIPT en el cuerpo del documento.

·        Cuando se usa el elemento SCRIPT, el elemento NOSCRIPT se requiere en el cuerpo del documento.


1. Si usas el elemento SCRIPT usa el elemento NOSCRITP

El ejemplo uno demuestra el uso apropiado del elemento NOSCRIPT

 

HTML actual – EJEMPLO 1

El código HTML actual, usa el elemento script, que puede usarse para abrir otra ventana de navegador. Esto se usa para presentar al usuario una oferta.

 

<SCRIPT language="JavaScript">

<!-- function popwin(){

window.open('http://www.hisoftware.com/acctest.htm','','width=400,height=200, scrollbars=1');

} // --> </script>

 

HTML corregido – EJEMPLO 1

El código HTML corregido, usa el elemento NOSCRIPT para el elemento SCRIPT. De esta manera, los usuarios que tienen un navegador que no soporta scripts, reciben la misma oferta.

 

<SCRIPT language="JavaScript">

<!-- function popwin(){

window.open('http://www.hisoftware.com/acctest.htm','','width=400,height=200, scrollbars=1');

} // --> </script>

<noscript> Estas páginas usan JavaScript para abrir una ventana que lleva al usuario a <a href="http://trial.accessibilitywatch.com/scripts/tryaccwmh.exe" class="thenav">Prueba de las Soluciones para la Revisión y Reparación de la Accesibilidad</a>

Este enlace es para una prueba de los servicios de revisión de la accesibilidad de sitios Web</noscript>

2. No uses script en elementos ANCHOR

El ejemplo dos, demuestra cómo corregir elementos ANCHOR  que usan script.

 

HTML actual – EJEMPLO 2

El código HTML actual, usa una función de navegación JavaScript, dentro de un elemento ANCHOR. Esto es imprudente y no debe hacerse.

 

<a href="javascript:displayWindow('sample.htm',360,145)">

 

HTML corregido – EJEMPLO 2

El código HTML corregido, usa un enlace directo a la página.

 

<a href="http://www.hisoftware.com/sample.htm">

 

NOTAS – EJEMPLO 2

Usar JavaScript en tus anclajes, puede funcionar para muchos visitantes, sin embargo, la complejidad del elemento NOSCRIPT debe disuadirte de hacerlo. Es recomendable NO USAR JavaScript en los elementos ANCHOR.


3. No uses script en elementos AREA

El ejemplo tres, demuestra cómo corregir los elementos AREA que usan script.

 

HTML actual – EJEMPLO 3

El código HTML actual, usa unas funciones JavaScript para enlaces en elementos AREA. Esto es imprudente y no debe hacerse.

 

<map name="FPMap0">

<area href="javascript:displayWindow('hit.htm',360,145)" shape="rect" coords="61, 24, 132, 92">

<area href="javascript:displayWindow('miss.htm',360,145)" shape="rect" coords="16, 101, 179, 215"></map>

<img border="0" src="PE01496_.gif" width="184" height="217" usemap="#FPMap0" alt="Imagen objetivo"></p>

 

HTML corregido – EJEMPLO 3

El código HTML corregido, usa un enlace directo a la página.

 

<map name="FPMap1">

<area href="hit.htm" coords="61, 24, 132, 92" shape="rect">

<area href="miss.htm" coords="16, 101, 179, 215" shape="rect"></map><img border="0" src="PE01496_.gif" width="184" height="217" usemap="#FPMap1" alt="Imagen objetivo"></p>

 

Sección 9 – Sección 508 (0)

El archivo de demostración para esta sección, puede descargarse de Internet desde:

 

http://www.hisoftware.com/uaccess/FPDemo8.htm

 

Recuerda que, para seguir el ejercicio con tu editor de páginas Web, debes antes descargarlo. Para ello: Abre la página citada arriba en Internet Explorer y guárdala en tu disco duro siguiendo los siguientes pasos:

 

25   Abre la página de arriba en tu navegador

26   Selecciona Archivo |Guardar cómo...

27   Escribe fpdemo1.htm en el campo para el nombre de archivo, asegúrate de seleccionar guardarlo como página Web completa, de manera que tengas todos los archivos de demostración.

28   Haz Clic en el botón Aceptar

 

Si has comprado el eBook, estos archivos estarán incluidos en un archivo comprimido llamado demos.zip. Expande estos archivos en tu disco duro.

 

Ahora, abre en tu editor de páginas Web el archivo guardado y estaremos listos para comenzar. Los problemas de accesibilidad que cubriremos en la sección nueve son:

 

Debe proporcionarse un método que, permita al usuario saltar los enlaces de navegación repetitivos.


1. Enlaces para saltar el menú de navegación

El ejemplo uno, demuestra cómo usar un HYPERENLACE a un BOOKMARK en tu página, para saltar los enlaces del menú de navegación.

 

HTML actual – EJEMPLO 1

El código HTML actual, tiene una serie de enlaces de navegación y un contenido principal. No tiene un método para saltar los enlaces de navegación y obtener acceso directo al contenido.

 

<p><a href="http://www.hisoftware.com/">Principal</a> | <a href="http://www.hisoftware.com/press/">Noticias</a> | <a href="http://www.hisoftware.com/support/">Soporte</a></p>

<p>Esta es la página de contenido principal... La Seccion 508

(o) establece que debe haber un método para saltar los enlaces de navegación de arriba

y permitir al usuario ir directamente al contenido </p>

 

HTML corregido – EJEMPLO 1

El código HTML corregido, tiene una serie de enlaces de navegación y un contenido principal. La página satisface el párrafo (o) de las Normas de la Sección 508, por medio de la creación de un BOOKMARK, donde comienza el contenido y colocando, entonces, un hyperenlace, para ir a ese bookmark, antes de encontrar cualquier enlace del menú de navegación.

 

<p><a href="#test">Skip Navigation Links</a> | <a href="http://www.hisoftware.com/">Principal</a>

| <a href="http://www.hisoftware.com/press/">Noticias</a> | <a href="http://www.hisoftware.com/support/">

Soporte</a></p>

<p>

<a name="test"></a>

Esta es la página de contenido principal... La Sección 508 (o) establece que es necesario que haya un método para saltar los

Enlaces de navegación de arriba y permitir al usuario ir directamente a este contenido

 

 

 

 


8. Usa Soluciones Accesibles

Divider

 

En este capítulo

 

·        Discusión sobre, qué relación hay entre las normas de accesibilidad del software, con las de accesibilidad Web

·        Introducción a la Sección 508 y a la Plantilla Voluntaria de Accesibilidad de Producto

·        Software y características que apoyan la accesibilidad

·        Observaciones y explicaciones sobre la conformidad del software con la Sección 508

·        Introducción a las Directrices para Software del EITACC (Information Technology Access Advisory Committee)

·        Introducción a las Directrices de Accesibilidad de Microsoft

 

Divider

 

Normas para Software

Las normas para el software, para los plug-ins o componentes, son tan importantes como la accesibilidad de tu sitio Web. Esto es verdad ya que:

 

 

Las directrices de la Sección 508, establecen claramente que, las páginas Web que requieran un applet o plug-in en el sistema cliente, deben  asegurarse de que el applet o plug-in es accesible en sí mismo. En muchos casos, el plug-in u objeto se descarga automáticamente en el cliente. Si no es así, debe proporcionarse un enlace a, donde el usuario pueda obtener el plug-in. Esto se establece en el párrafo (m) de las normas de la Sección 508.

 

Esto presenta un problema en el desarrollo de sitios Web dinámicos. Simplemente, porque si presentas al usuario una información que requiere un componente separad, para ejecutar o ver la información, ese programa cliente debe ser accesible. Muchos componentes o aplicaciones usuales con base en la Web, no lo son.

 

Algunos ejemplos:

 

Un documento PDF antiguo, podría no ser accesible en el visor Acrobat 5.0. El documento no tiene las propiedades correctas, para permitir a las ayudas técnicas obtener el contenido.

 

Un documento PDF nuevo, puede ser utilizado por las ayudas técnicas, sin embargo, si tienes un visor antiguo, no podrá sacar partido del nuevo formato de la información.

 

Un objeto muy usado es el que se desarrolla para mostrar la agenda de eventos de una empresa. El objeto en sí no es accesible. Si esta información no estuviera disponible de otra manera, entonces, el sitio no sería accesible ya que el objeto no lo es.

 

La idea más importante que un desarrollador Web debe recordar es que:

 

El sitio Web, su contenido, y cualquier componente usado o de terceras partes, debe ser accesible.

 

El resto de este capítulo nos introducirá en las normas de accesibilidad del software.

 

 

Sección 508

Cuando estás seleccionando soluciones informáticas, para implantar la accesibilidad en tu sitio, debes considerar la accesibilidad del software en sí mismo, así como sus salidas. (Este es un requisito para los departamentos Federales de los Estados Unidos, según la Sección 508.)

 

La Plantilla Voluntaria de Accesibilidad de Producto

El Consejo Industrial de las Tecnologías de la Información, ha desarrollado un formulario llamado Voluntary Product Accessibility Template (VPAT.) Este formulario, sirve para la autocertificación, permitiendo a los vendedores de software, identificar la accesibilidad de los componentes de sus aplicaciones, y proporcionar esa información a sus clientes. Las empresas de software, deben ser capaces de darte sus declaraciones voluntarias, de la accesibilidad de sus productos. Esto te dará una mejor idea, sobre si el software es accesible o no lo es. Recuerda que, es tu responsabilidad verificar si la solución es accesible o no.

 

Los siguientes elementos, deben revisarse cuando se selecciona una herramienta:

 

(a)   Cuando el software ha sido diseñado para correr en un sistema que tiene un teclado, las funciones del producto deberán ser ejecutables desde un teclado, cuando la función en sí o el resultado de llevar a cabo una función puede discernirse textualmente.

(b)   Las aplicaciones, no interrumpirán o deshabilitarán las características activadas de otros productos, que se identifican como opciones de accesibilidad, cuando esas características han sido desarrolladas y documentadas, de acuerdo con los estándares de la industria. Las aplicaciones tampoco interrumpirán o deshabilitarán las características activadas de cualquier sistema operativo, que estén identificadas como opciones de accesibilidad, cuando la interfaz programada de la aplicación ha sido documentada por los fabricantes del sistema operativo y está disponible para los desarrolladores de productos.

(c)   Debe proporcionarse una forma inequívoca de reflejar en la pantalla dónde se encuentra el foco. El foco debe también moverse entre los elementos de las interfaces interactivas, según va cambiando el foco de entrada.  El foco debe ser generado por una función del sistema, de manera que las ayudas técnicas puedan localizar y seguir sus cambios.

(d)   Debe estar disponible para las ayudas técnicas, suficiente información sobre un elemento de la interfaz de usuario, incluyendo la identidad, funcionamiento y estado del elemento. Cuando una imagen represente un elemento del programa, la información transmitida por la imagen debe estar disponible en formato texto.

(e)   Cuando se usan imagines bitmap para identificar controles, indicadores de estado, u otros elementos de programación; el significado asignado a estas imágenes debe ser consistente a lo largo de la actuación de la aplicación.

(f)     Debe proporcionarse información en formato texto a través de las funciones del sistema operativo para representar texto. La información mínima que debe estar disponible es el contenido en texto, la localización del cursor de introducción de texto, y los atributos del texto.

(g)   Las aplicaciones no deben invalidar las selecciones de contraste y color hechas por el usuario, ni otros atributos individuales de presentación.

(h)   Cuando se presente una animación, la información debe poder presentarse al menos en una forma no animada, a elección del usuario.

(i)      No debe usarse una codificación por color como la única manera de transmitir información, indicar una acción, una respuesta, o distinguir un elemento visual.

(j)      Cuando un producto permita a un usuario ajustar opciones de color y contraste, debe proporcionarse una variedad de colores a elegir, capaces de producir un amplio rango de niveles de contraste.

(k)   El software no debe usar texto, objetos u otros elementos que parpadeen o destellen con una frecuencia superior a 2 Hz. e inferior a 55 Hz.

(l)      Cuando se usen formularios electrónicos, el formulario debe permitir a las personas que usan ayudas técnicas acceder a la información, rellenar campos, y toda la funcionalidad requerida para completar y enviar el formulario, incluyendo todas las instrucciones y pistas.

 

 

Salidas del Software

Las secciones de arriba, han tratado sobre características del software, sin embargo, muchas aplicaciones informáticas generan salidas por pantalla. Recuerda que, todas las salidas generadas, tanto si son HTML, XHTML, PDF, o cualquier otro formato, deben ser accesibles.

 

Características soportadas

Si es necesario, la VPAT para la aplicación informática, debe enumerar las características que soportan un punto de control de la accesibilidad.

 

Criterio

Cuando el software se ha diseñado para correr en un sistema que tiene un teclado, las funciones del producto deben poder ejecutarse desde un teclado, en el que la función en sí misma o el resultado de llevar a cabo una función pueda discernirse textualmente.

 

APOYANDO CARACTERÍSTICAS

Todas las características y funciones del software, tienen equivalentes en texto. 

 

En el ejemplo de arriba, el desarrollador del software tuvo en cuenta que, todas las características y funciones tuvieran textos equivalentes tal como exige el punto (a). Si un desarrollador de software distribuye una VPAT que no está completa, puedes pedir a la empresa que certifique por escrito el  soporte para estas características, esenciales para la accesibilidad.

 

Comentarios y explicaciones

Si es necesario, la VPAT del software debe enumerar los comentarios o explicaciones adicionales, requeridas para describir la accesibilidad del producto.

 

Criterio

Cuando el software es diseñado para correr en un sistema que tiene un teclado, las funciones del producto deben poder ejecutarse desde un teclado, en el que la función en sí misma o el resultado de llevar a cabo una función pueda discernirse textualmente.

 

Comentarios y explicaciones

Las funciones son accesibles para el usuario a través de los elementos de la barra de menús y de atajos de teclado. HiSoftware, usa los atajos de teclado estándar de Windows®, así como atajos adicionales que se incluyen en la documentación de AccMonitor.

 

En el ejemplo de arriba, el desarrollador del software enumera el alcance del cumplimiento con las características de accesibilidad requeridas.

 

Introducción a las Normas EITACC para Software

Puede encontrarse información completa sobre estas normas en:

 

http://trace.wisc.edu/docs/eitaac_desktop_software_standards/desktop_software_standards.htm

 

Las normas cubren:

 

 

Los desarrolladores encontrarán el tipo de información que les exige cumplir con esta norma, claramente detallada en el sitio citado arriba.

 

 

Introducción a las Directrices de Accesibilidad de Microsoft

Las directrices completas de Microsoft, para el diseño de aplicaciones informáticas accesibles, pueden encontrarse en:

 

http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc/html/accessibilitydsgn.asp

 

Esta es, quizás, una de las más completas guías disponibles en Internet. Yo añadiría que, también necesitan ser cubiertos por el Diseño de Ssoftware Accesible de Microsoft:

 

 

¡Esta es la guía más leída por los desarrolladores de software!


 

9. Recursos de Accesibilidad para Lecturas Posteriores

Esta sección del libro, introduce al lector a los recursos adicionales disponibles relativos a la accesibilidad. Los recursos se dividirán por temas:

 

 

 

 

Sección 508

 

Architectural and Transportation Barriers Compliance Board

Electronic Information Technology Accessibility Standards; Final Rule (Las normas de la Sección 508)

http://www.access-board.gov/sec508/508standards.htm

 

Federal IT Accessibility Initiative (La iniciativa federal de Estados Unidos para las tecnologías de la información) :

http://www.section508.gov

 

Center for IT Accommodation (Centro para la adaptación de tecnologías de la informa