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.
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”, 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.
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.
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:
- Usuarios Ciegos
- Usuarios con Ceguera al Color
- Usuarios con visión débil que no pueden leer
texto pequeño
- Usuarios Sordos
- Usuarios con deficiencia auditiva
- Usuarios que no usan un ratón
- Usuarios con discapacidades debidas a la
artritis u otros problemas de control motor
- Epilepsia fotosensible – No es muy común
pero es atendida por el estándar.
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.
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.
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.
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
impuesta al organismo.”
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:
- La subsección A, contiene información
general sobre el propósito, aplicación y puesta en práctica de las normas
508.
- La subsección B, contiene normas técnicas,
incluyendo aplicaciones e información con base en la Web para intranets
(redes corporativas) e Internet. Otros componentes de la Subsección B
incluyen normas para productos de software, sistemas operativos, productos
de telecomunicaciones, vídeo y multimedia, productos autónomos, y
ordenadores portátiles y de sobremesa.
- La subsección C, contiene criterios
funcionales de actuación.
- La Subsección D, contiene normas para la
información, documentación y soporte técnico.
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
§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
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
El grupo de iniciativa de accesibilidad del
W3Câ
(WAI), persigue la accesibilidad de la Web a través de 5 áreas de trabajo
principales:
- Tecnología
- Directrices
- Herramientas
- Formación y difusión
- Investigación y
desarrollo.
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.
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.
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.
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.
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.
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..
Visita http://www.hisoftware.com, o llama al +1- (603) 229-3055 para obtener
más información.
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
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.
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.
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:
- Para establecer la audiencia de tu sitio
Web.
- Para tomar una posición de liderazgo en tu
sector particular de negocio.
- Para hacerse con una fiel cartera de
clientes.
- Si estás haciendo negocios con el gobierno,
es la ley.
- Está claro que, para los sitios no
gubernamentales se convertirá en ley.
- El costo de reconversión, es superior a la
construcción de un sitio accesible desde su creación.
- Es simplemente una cuestión de buen sentido
comercial, al incrementar el número potencial de tus clientes.
- Es lo correcto a hacer, con un mínimo costo.
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.
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:
- Si una imagen no tuviera ningún significado,
en cuyo caso no se habría usado.
- Si el elemento de navegación no tuviera
ningún significado, en cuyo caso no se habría utilizado.
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?
- Ceguera
- Ceguera al color
- Deficiencia visual
- Sordera o deficiencia auditiva
- Imposibilidad de usar un ratón
- Dificultades motoras
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!.
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:
- El alto costo de llevar a cabo un sistema
efectivo.
- La sincronización del contenido.
- La dificultad de
traducir el significado de gráficos por vía automática.
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
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.
(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.
- Botones
- Cuadros de
verificación
- Fotos/Imágenes
- Audio o video
incrustado o Streaming
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.
- Input
- Object
- Applet
- Frameset
- IFrames
- Anchors
- Area
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:
- Ceguera
- Deficiencia visual
- Sordera o deficiencia auditiva
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:
- El texto alternativo, debe representar
completamente el significado de la imagen y su propósito, para la persona
que está viendo la página.
- Si es necesaria una descripción más amplia
para la imagen, puede utilizarse el atributo longdesc, para enviar
al usuario a otra URL que contendrá información adicional.
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.
(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:
- Ceguera
- Deficiencia visual
- Sordera o deficiencia auditiva
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:
- Selecciona la imagen que necesita el texto
alternativo
- Selecciona el menú Formato | Imagen...
- Selecciona la pestaña “Web”
- Escribe el texto alternativo en el cuadro de
diálogo
- 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)
(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:
- Ceguera
- Deficiencia Visual
- Ceguera al color
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.
(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:
- Ceguera
- Ceguera al color
- Deficiencia visual
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.
(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:
- Ceguera
- Ceguera al color
- Deficiencia visual
- Incapacidad para usar un ratón
- Deficiencias motoras
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.
(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:
- Ceguera
- Deficiencia visual
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.
- 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.
- 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.
(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:
- Ceguera
- Deficiencia visual
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.
(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:
- Oscile
- Destelle
- Parpadee
- O que tenga movimientos vacilantes de un
control como de marquesina (marquee) o de “News Bot”
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.
(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:
- Potencialmente todas las discapacidades
referidas por las normas.
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.
(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:
- Potencialmente todas las discapacidades
referidas en estas normas.
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:
- OnClick
- OnDblClick
- OnMouseDown
- OnMouseUp
- OnMouseOver
- OnMouseOut
- onChange
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:
- OnLoad
- OnUnload
- OnBlur
- OnFocus
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.
(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:
- Potencialmente todas las discapacidades
referidas en las normas.
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.
(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:
- Potencialmente todas las discapacidades
referidas en las normas
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:
- Valores predefinidos en las áreas de texto
- Texto alternativo en elementos de entrada
- Etiquetas para facilitar la navegación
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.
(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:
- Potencialmente todas las discapacidades
referidas en las normas
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:
- La señal a la que envíes al usuario, no debe
saltarse NINGÚN contenido No Textual, que no esté relacionado con la
navegación.
- La señal a la que envíes al usuario, no debe
saltarse NINGÚN contenido de Texto, que no esté relacionado con la
navegación.
(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:
- Potencialmente todas las discapacidades
referidas en las normas
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 página expire
- Despejar las entradas en el formulario
- Redirigir al usuario a otra página
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
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
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.
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:
- Uso de marcos
- Abuso de sistemas de menú basados en Java,
que pueden parecer atractivos pero que tienden a ser abrumantes
- La presunción de que colocar descripciones
de formularios y campos, en tablas, los hace más útiles.
Errores de accesibilidad más comunes, que
impiden que un sitio sea utilizado, eficazmente, por personas con discapacidad:
- Uso de marcos que no son fácilmente
navegables
- No usar texto alternativo, para los
elementos no textuales:
o Objetos
- Y otros elementos no textuales
- Usar las prioridades dos o tres para
intentar satisfacer las normas 508, o las directrices de prioridad uno del
W3C
- No proporcionar un mapa de los contenidos
del sitio
- Mapas de imagen no accesibles
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.
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:
- La revisión de un sitio Web, combina la
revisión tanto de la edición del contenido como de la funcionalidad, con
la intención de encontrar errores.
- El revisor, debe esforzarse por desarrollar
test que tengan la más alta probabilidad de producir errores. Recuerda
que, una revisión lograda, es aquella que descubre errores. (Por ejemplo:
cuando un objeto ha sido desarrollado para funcionar de la mejor manera
con Internet Explorer, una buena prueba sería probarla con todos los otros
navegadores, para garantizar que se obtienen los mismos resultados.)
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:
- Test de Condición – Este tipo de test se
define mejor como un test de verdadero/falso. Por ejemplo: puede haber un
test de un sistema operativo (“OS”) específico, para el que la Condición
sea probada. Otro ejemplo podría ser, probar la presentación a través de
varios navegadores. Los test de Condición, generalmente son relevantes
para probar datos dinámicos y no sitios Web estáticos.
- Test del Flujo de Datos – Basado en el flujo
de entradas a una aplicación Web, se presentarán distintas pantallas y
contenido general. Esta salida para el usuario, necesita ser verificada y
validada para ver si es acorde a los estándares de accesibilidad. Los test
de Flujo de Datos, son también más apropiados para los sitios Web
dinámicos. Es entonces más apropiado para ser usado en una aplicación con
base en la Web (Ej.: un sistema de reservas online.)
- Límite – Probar el límite, puede definirse
como una prueba de los límites de una entrada específica. Al igual que con
el anterior tipo de test, un test límite está más frecuentemente diseñado
para sitios dinámicos, donde las entradas específicas del usuario, OS, o
las Aplicaciones de Usuario, podrían tener un impacto directo sobre el
contenido distribuido.
- Verificación – Es el proceso de determinar
si ha cumplido con los requerimientos de su organización y/o con los
estándares para el sitio Web, tal como estén definidos. (En el caso de la
Accesibilidad, estos pueden ser la Sección 508 o la Prioridad Uno del W3C)
Nota: Este tipo de test, está diseñado para garantizar que se cumplen los
requerimientos, no si esos requerimientos son correctos.
- Validación – Este proceso de test, es un
control de los requerimientos iniciales. Observa los requerimientos y
luego el sitio Web final, para determinar si mientras se han producido
las respuestas deseadas, al contestar al test, también los requerimientos
han cumplido sus objetivos. Por ejemplo: una organización puede tener un
sitio Web revisado por un grupo interno o externo, para determinar la
usabilidad del sitio, incluso aunque cumpla con las normas de
accesibilidad. Esto garantiza, no sólo el cumplimiento sino también la
usabilidad del producto final.
- Test de Cambios – El test de Cambios para
los sitios Web, al igual que para garantizar la calidad del software, es
muy importante. Ya se trate de un sitio dinámico o estático, el contenido
será cambiado o se añadirá contenido. Una vez hechos los cambios, una
página o sitio necesita ser revisado de nuevo. Debido a la naturaleza de
las herramientas de autoría y gestión de contenido, es posible que un
cambio pueda crear innumerables errores de accesibilidad. Por ejemplo: en
una herramienta de autoría, añadir un enlace a un mapa de imagen, puede
despejar todos los otros textos alternativos en todo el mapa. En un
sistema de gestión de contenido, cambiar una plantilla, podría hacer
inaccesible el sitio completo. Alternativamente, la modificación o
eliminación de una propiedad de una imagen, podría hacer inaccesibles una
o muchas páginas.
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.
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.
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.
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.
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.
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:
- De sobremesa –
Se ejecutan sobre un ordenador de sobremesa cliente y funcionan con o sin
la interacción del usuario. Generalmente, las aplicaciones de sobremesa
son apropiadas para la revisión de sitios Web pequeños o páginas locales.
Generalmente, no se usa para difundir información a un equipo. Un
ejemplo de una aplicación de sobremesa sería el programa AccVerify de
HiSoftware.
- De servidor –
Las soluciones basadas en un servidor, generalmente, funcionan sin
requerir ninguna intervención por parte del usuario, excepto para la
configuración inicial. Además, una vez configurado, o para la
configuración inicial, hay generalmente una interfaz Web, de manera que
tras la instalación, no hace falta acceder a la consola del servidor.
- En la Web – Es
similar a las aplicaciones de servidor, la principal diferencia es, que no
se necesita hardware, ya que la aplicación de servidor está instalada,
mantenida, y los medios los proporciona el servidor en la Web.
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:
- FTP – Protocolo
de transferencia de archivos anónima
- FTP Authentication - Protocolo de transferencia de archivos, que requiere que el
usuario se identifique con un nombre de usuario y clave.
- HTTP – Una
aplicación de usuario, capaz de expedir solicitudes y recibir respuestas,
desde un servidor Web anónimo.
- HTTPS - Una
aplicación de usuario, capaz de expedir solicitudes y recibir respuestas
desde un servidor Web, que soporte Secure Socket Layer (un
protocolo de seguridad).
- HTTP(s) Authentication - Una aplicación de usuario, capaz de expedir solicitudes y
recibir respuestas desde un servidor Web, que soporte verificación de
identidad http y opcionalmente, el Secure Socket Layer.
- Escaneado de archivos locales – La capacidad de escanear e identificar los archivos locales en
el sistema y verificar todos los documentos que casan con las extensiones
de documentos para la Web.
- Selección de archivos locales – la capacidad de seleccionar archivos locales, desde un
ordenador de usuario o servidor.
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.
- Soporte para firewall – La capacidad de enviar solicitudes y recibir respuestas, a
través de un firewall (sistema de seguridad) corporativo.
- Por razones de formación, debe haber soporte
de vistas históricas, del estado de la accesibilidad.
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!.
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.
- La solución de reparación que elijas, debe
ser capaz de trabajar con archivos que estén desarrollados o almacenados,
en aplicaciones basadas en sistemas Windows, Unix (Linux), o Apple.
- Los sistemas de reparación, deben incluir la
posibilidad de revisar la ortografía de las representaciones de los textos
alternativos, introducidas para cumplir con la accesibilidad.
- Los sistemas de reparación, deben permitir a
los equipos Web trabajar en colaboración, sobre las reparaciones de una o
múltiples páginas.
- Las herramientas de reparación, deben
aprender el significado de los elementos de entrada de datos, objetos, y
cualquier elemento que requiera del texto alternativo o elemento de
contenido.
- Las herramientas de reparación, deben
permitir editar valores en una biblioteca, fuera del entorno del proceso
de reparación.
- Las herramientas de reparación, deben
permitir las reparaciones automáticas, cuando sean posibles.
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.
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.
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.
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
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.
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.
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
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
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.
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:
- Asignar apropiadamente los recursos
- Seguir el progreso del sitio
- Formar a los empleados
- Identificar áreas problemáticas
- Integrar la accesibilidad en los procesos de
garantía de calidad y publicación de contenidos.
- Mantener una visión histórica del trabajo de
accesibilidad de su sitio Web.
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:
- Presentaciones en PowerPoint
- Audio o archivos de audio bajo demanda
- Vídeo y Vídeo bajo demanda
- Presentaciones Flash
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.
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:
- Marketing – Para
su conocimiento sobre quién usa el sitio y de las estadísticas de uso del
sitio.
- Desarrollo –
Para su conocimiento sobre qué habilidades y tecnologías serán necesarias
para completar la tarea.
- Relaciones Públicas – Involucra a tu equipo de Relaciones Públicas para determinar si
deben hacerse públicos o no, los esfuerzos para conseguir la
accesibilidad.
- Usuarios Finales
– Desde usuarios internos hasta un grupo de “beta testers”, los usuarios
reales te ayudarán a que cualquier proyecto de accesibilidad tenga éxito.
- Ejecutivos de administración – Los socios, o una representación de los ejecutivos, en el
equipo ayudará a mantener consolidado el proyecto.
- Operaciones –
Este grupo, generalmente es el responsable de la realización y revisión de
todo el sitio. Este grupo, será fundamental en el desarrollo de una
estrategia de accesibilidad a largo plazo.
- Formación/desarrollo profesional – Este grupo, debe ser parte del proyecto desde el principio de
manera que pueda comprender mejor las necesidades de formación.
El nivel de participación variará para cada
grupo, sin embargo, todos ellos cumplirán una importante función en el
proyecto.
Las siguientes, son las cuatro fases básicas del
desarrollo y mantenimiento de un sitio Web accesible:
- Diseño de un plan – Llevando a cabo una valoración del sitio, estableciendo las
metas de la empresa, y estableciendo unas normas y directrices de diseño.
- Establecimiento de directrices – Formando a los desarrolladores y modificando el contenido
actual. Todo el contenido nuevo, debe llevarse a cabo basándose en tus
nuevas normas y directrices.
- Revisión de la accesibilidad – Una revisión completa, para garantizar que ha cumplido con tus
nuevas directrices y normas.
- Mantenimiento de la accesibilidad – Evaluando resultados, verificación automática de las normas y
directrices de accesibilidad.
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.
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.
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.
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.
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.
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:
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
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
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:
- El nivel de accesibilidad que quieres
conseguir
- La accesibilidad actual basada en su
evaluación
- Definir los requisitos de formación,
basándose en la evaluación
- Los recursos de la empresa disponibles para
el proyecto
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.
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.
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.
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.
- La cantidad total de contenido, o el número
de páginas estáticas
- El número de plantillas para contenido
dinámico
- El tiempo requerido para arreglar una página
o plantilla (en horas)
- El crecimiento del sitio Web (Cuántas
páginas nuevas se añaden cada semana o mes)
- El total de los recursos disponibles para el
proyecto
- La prioridad del proyecto
- La fecha de inicio del proyecto
- 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.
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.
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.
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.
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.
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:
- Usa el IBM Home Page Reader, para
revisar la accesibilidad de un sitio para personas con deficiencias
visuales.
- Imprime tu página en una impresora de blanco
y negro, para garantizar el cumplimiento de las directrices sobre uso del
color.
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:
- Formación continua – El proceso de
desarrollo profesional continuado para los desarrolladores del sitio y los
revisores de garantía de calidad.
- Información de fallos y procedimientos de
reparación.
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.
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:
- Distribución de información y publicaciones
- Comunicaciones corporativas
- Gestión corporativa
- Compartir aplicaciones corporativas
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.
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.
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.
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:
- Desarrollo de una política de accesibilidad
para la Intranet
- Hacer accesibles todas las aplicaciones de
la Intranet que requieren los empleados para comunicarse entre sí.
- Hacer accesibles todos los repositorios de
información, que son necesarios para que los empleados lleven a cabo su
trabajo.
- Reconvertir todos los otros documentos y
aplicaciones de la Intranet.
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.
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:
- Si se arreglaran todas las imágenes, el 62%
de las páginas pasarían los requisitos de accesibilidad.
- Si se arreglaran todos los elementos de
entrada de información, el 72% de las páginas podrían pasar.
- Si se arreglaran todos los objetos y
applets, entonces, el 77% de las páginas pasarían.
- Si se arreglaran todas las páginas con
marcos, entonces, el 92% de las páginas pasarían.
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
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.
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:
- Contenido distribuido específicamente para
las capacidades de un navegador determinado.
- Contenido distribuido basándose en la
información de acceso de los usuarios.
- Contenido distribuido basándose en las
solicitudes de los usuarios a una base de datos.
- Contenido distribuido basándose en la
programación del lado de un servidor específico.
- Contenido distribuido debido al procesamiento
del lado del servidor.
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.
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.
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:
- Si yo reviso las plantillas del sitio y son
accesibles, entonces la página generada será accesible.
- Yo no necesito revisar mi página ya que es
activada por datos.
- Si yo uso HTML 4.0, mi sitio es accesible.
Aunque cualquiera de estas declaraciones puede
ser verdad, hay que revisarlas para probar si son correctas o erróneas.
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.
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.
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.
- Los elementos Input carecen de
etiquetas o 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.
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:
- La marca de las compañías está visible en la
página.
- Una imagen del producto con un gran texto en
ella como: “Nº 1 en el Ranking”.
- Una imagen que declara orgullosamente que la
tienda es segura, está libre de virus y que eso está garantizado.
- Hay un botón con una imagen apremiante y que
le ordena al usuario “¡Compra ahora!” (Ese producto).
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:
- Ver las marcas de las compañías.
- Ver la imagen del producto, o que este se
encuentra en el ranking en el número 1.
- Ver la orgullosa declaración de cuán segura
es la tienda y cuán libre de virus está.
- ¡Imaginarse cómo podrá comprar el producto o
beneficiarse de la imagen que le ordena que “compre ahora”!.
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:
- Tablas inaccesibles para mostrar una lista
de los productos.
- Formularios inaccesibles para seleccionar
las cantidades.
- Formularios inaccesibles para elegir la
forma de envío.
- Imágenes inaccesibles para elegir la
plataforma (sistema operativo), en la que correrá el producto.
Nota: el cliente ciego, encontrará incluso más
dificultades para introducir su dirección, o la información sobre la tarjeta de
crédito.
Parece que ahí hay tres problemas reales.
- Las plantillas no son accesibles.
- Los datos de cliente no son accesibles.
- 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.
La empresa de comercio electrónico debe
comenzar inmediatamente. Hay muchas razones pero las más apremiantes son:
- Realizar los cambios basándose en su agenda.
- Realizar los cambios antes de perder
clientes.
- El probable aumento de los ingresos.
- La gran oportunidad de conseguir marketing
gratuito y presencia en la prensa.
- 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.
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.
- Norma
1.1: Todos los elementos IMG requieren contener el atributo 'alt' o el
atributo 'longdesc'.
- Fallo - Elemento IMG en Línea: 104, Columna: 1
- Fallo - Elemento IMG en Línea: 157, Columna: 44
- Fallo - Elemento IMG en Línea: 234, Columna: 18
- Norma
1.1: Todos los elementos INPUT requieren contener el atributo 'alt' o usar
LABEL.
- Nota:
Elemento INPUT encontrado en Línea: 82, Columna: 1 no contiene el
atributo 'alt', sin embargo, es de tipo 'hidden' y no representa un problema
de accesibilidad.
- Nota:
Element INPUT encontrado en Línea: 83, Columna: 1 no contiene el atributo
'alt', sin embargo, es del tipo 'hidden' y no representa un problema de
accesibilidad.
- Fallo - Elemento INPUT en Línea: 111, Columna: 48
- Fallo - Elemento INPUT en Línea: 125, Columna: 29
- Fallo - Elemento INPUT en Línea: 133, Columna: 29
- Fallo - Elemento INPUT de tipo IMAGE en Línea: 134,
Columna: 1
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:
- El código de sumisión no tiene texto
alternativo, y es imprescindible para proponer una página al índice.
- No se usa el texto alternativo, ni hay una
etiqueta para el campo de texto, usado para introducir el código de
sumisión.
- No se usa el texto alternativo, ni hay una
etiqueta para el campo de texto, usado para introducir la URL
- No se usa el texto alternativo, ni hay una
etiqueta para el campo de texto, usado para introducir la dirección de
correo electrónico del usuario.
- No se usa el texto alternativo, ni hay una
etiqueta para el elemento input, de tipo imagen, que se usa para
enviar la información.
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:
- Corregir todas las páginas que tienen
errores de accesibilidad.
- Proporcionar un enlace en la página, para
los usuarios con deficiencia visual, o ceguera, a otra en la que ellos
puedan someter páginas a su índice, o solicitar un código que pueda usarse
para completar el formulario normal.
6. El significado inadvertido
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
En esta sección discutiremos los componentes
no visuales, que pueden tener un impacto significativo en la accesibilidad de
una página.
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.
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.
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 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.
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.
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.
La accesibilidad desde el punto de vista del
contenido Web tiene dos significados:
- Que un usuario pueda obtener ese contenido.
- Que un usuario pueda comprender ese
contenido.
Los textos equivalentes, son necesarios para
los elementos no textuales, elementos multimedia, tablas, marcos, y scripts.
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
- Fíjate en qué tipo de documento estas
enlazando. ¿Es una versión solo texto de la misma página?.
- Describe el contenido del documento en el
enlace de descripción. ¿Estás enlazando a una descripción de toda la
página o sólo de un elemento de la página? Por ejemplo, “Versión texto de
la Tabla 1”.
- Describe todos los colores y sonidos con
precisión.
- Considera la orientación, o direccionalidad,
de la imagen o animación. Si la imagen es la de un hombre ¿está mirando a
la derecha o a la izquierda?
- Describe la naturaleza de la imagen o
animación. ¿Es la imagen una foto de la vida real, obra de arte, dibujo,
una caricatura, etc.?
Las tablas y otros elementos pueden requerir
descripciones extensas.
- Cuando te refieras a números, sé claro sobre
qué unidades usas para medir. ¿Estas usando millas, onzas, pulgadas, pies,
o etc.?
- Cuando describas tablas o gráficos, describe
las características generales de los ejes x e y. Esto aclarará lo que
estás comparando o las referencias cruzadas..
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.
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.
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.
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.
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.
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:
- Revisa la ortografía de tu texto
alternativo.
- Usa puntuación, si es necesario.
- Casa el texto con el significado de la
imagen.
- Relee siempre el texto alternativo, para
estar seguro de que transmite el significado proyectado.
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.
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
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.
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.
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’.
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’.
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”>
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
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>
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>
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>
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.
<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.
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”>
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.
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.
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:
- Archivos de audio autónomos, tales como las
músicas que se ejecutan durante una presentación multimedia, o a solicitud
del usuario.
- Archivos de audio interactivos, tales como
un sonido de alerta, que se ejecuta solo cuando el usuario ha llevado a
cabo una tarea específica.
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:
- Escuche la primera grabación del himno
nacional.
- Vea una trascripción de la primera grabación
del himno nacional.
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.
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.
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>
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!.
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.
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>] </font></p>
<p>
[<A href="../access/approved.html">
Significado
del Logo de Aprobado</A>]</p>
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
- Todas las celdas de encabezado de columna,
requieren contener el atributo scope
- Todas las celdas de encabezado de fila,
requieren contener el atributo scope
- Todas las celdas de encabezado de columna,
requieren contener el atributo id
- Todas las celdas de encabezado de fila,
requieren contener el atributo id
- Todas las celdas de datos, requieren
contener el atributo header
- Todas las celdas de datos, requieren
contener el atributo axis
- Cuando se usa el agrupamiento de elementos
de fila, todas las filas requieren estar agrupadas
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>
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>
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>
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>
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>
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>
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:
- Todos los elementos Frame, requieren
contener el atributo title
- Todos los elementos Frame, requieren
contener el elemento noframes
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>
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>
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:
- Los documentos requieren no contener el elemento
BLINK
- Los documentos requieren no contener el
elemento MARQUEE
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>
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>
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.
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>
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.
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>
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.
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
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
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:
- Muchos sitios Web usan presentaciones y
objetos multimedia que requieren plug-ins de terceras partes
- Los controles ActiveX son populares
- Los Applets Java se han hecho muy comunes
- Los sitios Web se vienen usando como
repositorios de documentación
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.
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.)
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.
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.
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.
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.
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:
- Acceso por teclado
- Información de objetos
- Iconos
- Sonidos
- Pantalla
- Sistemas de encendido y apagado
Los desarrolladores encontrarán el tipo de
información que les exige cumplir con esta norma, claramente detallada en el
sitio citado arriba.
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:
- Índice de importancia
- Lista de discapacidades impactadas
- Suministrar unos cimientos firmes para los
programas de revisión
¡Esta es la guía más leída por los
desarrolladores de software!
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
- Recursos Web relacionados
- W3C/WAI
- Soluciones informáticas
- Servicios de accesibilidad
