Portada > Artículo > Comentarios

Accesibilidad

12-01-2006 - César Martín

Resumen: Un par de ideas sobre las páginas de validación en castellano y código para copiar y pegar para conseguir una web más accesible.

Leer artículo »

Comentarios

Hablar, escuchar, debatir... Alzado es un espacio de conversación abierto. Algunos consejos:

Procura que tus comentarios sean relevantes y relacionados con el artículo
Escuchar es una virtud. Lee los comentarios anteriores para no repetirte
Pon un título a tu mensaje aue permita identificar su contenido
Usa un tono respetuoso. Los comentarios inapropiados o en tono ofensivo podrán ser editados o eliminados.

#1 Me quedó claro Por Mariana

Pues no se de esto, pero me quedó clara la idea, una página web más accesible. Algo que tiene que ver con el diseño, orden, limpieza, visualización, información estratégicamente colocada. ¡Bien!

Enviado 12-01-2006

#2 Hera no valida a si misma... Por Jordi

Felicidades por el artículo.
Pero que tengo que decir si he validado Hera, con la misma Hera y ha dado errores...
No he querido probar con el otro, pero bién, por mi cuenta aquí dejo la decepción.

Enviado 12-01-2006

#3 Los validadores castigan más que promueven Por César

Creo que ne general los validadores son demasiado rigurosos y no alentan al desarrollador a desarrollar la accesibilidad.

Quiero decir que los validadores son demasiado estrictos y castigan excesivamente (o por lo menos comunican más el castigo que el acierto) alentando poco al desarrollador.

Es decir, si haga lo que haga siempre tengo un mensaje de error, al final lo fácil es "pasar".

Creo que los validadores deberían comunicar de forma más amable los errores.

Por ejemplo:
- Evitando el color rojo en los fallos.
- Comentando de forma más resumida y clara los errores.
- Dando instrucciones claras y sencillas sobre lo que si se puede validar de forma automática dejando en un segundo plano los mensajes "interpretativos" tipo: "Asegurese de que el color de fondo y el texto tienen suficiente contraste"... Creo que no es necesario decir algo como esto y por otro lado, al decirlo como un error suena a regañina...

Creo que la misión de los validadores debería ser la de alentar al desarrollador más que castigarle y este matiz no tiene que ver con el funcionamiento, y si con la comunicación.

Enviado 13-01-2006

#4 http://belingo.net Por Jorge Correa

Para la "propuesta de resultados" de Hera (o cualquier otro validador, no veo apropiado un feedback tan directo como "Sí o No".

En el mismo ejemplo que citas verás que te alerta de una revisión manual necesaria, donde tienes 33 puntos a revisar personalmente.

Si das al desarrollador, o peor, a un cliente, el "SI" te aseguro que te obligará a poner el icono y/o mensaje pertinente en su web, pase o no pase el resto de puntos de verificación manual.

Enviado 13-01-2006

#5 Bien Por Pues yo

Joder. Encontrar artículos sobre lo que es "accesibilidad" en español es raro de cojones. Felicidades pro la claridad.

Enviado 13-01-2006

#6 alzado.org ? Por pablete

Alguno ha probado validar alzado.org? el resultado es interesante ;)

Enviado 13-01-2006

#7 Bien, pero se deberia profundizar mas Por David

Hola:

Se agradece este articulo ya que cualquier cosa sobre este tema viene muy bien. Yo para aprender recomiendo libros sobre xhtml y css y las referencias sobre accesibilidad del w3c.

En cambio, opino que si escribes algo sobre cualquier tema, tienes que tratar de profundizar. Los ejemplos y explicaciones que se dan aqui son muy limitados, apenas se raspa la superficie del problema.

Se podrían aconsejar mil cosas mas. Por ejemplo, a la hora de organizar datos en tablas, no solo usar los th, y caption, sino tambien los campos summary, id, axis y headers, para que los lectores de pantalla lean con coherencia los datos.

Si no los ponemos, es posible que lean lo siguiente en una tabla de tipos de coches comprados por los usuarios:

Pepe, maria, opel, rojo, corsa, verde, ford, mondeo.

Poniendo los atributos citados pondria:

Pepe, opel, corsa, rojo, maria, ford, mondeo, verde.

Hay muchas mas cosas, pero bueno, lo importante es que estos temas se abren camino, y creo que el avance es imparable, cada vez hay mas conciencia.

Un saludo, y suerte!!!

Enviado 13-01-2006

#8 interacción vs. validación Por Eliseo

Creo que los validadores están absolutamente "obsoletos". Sólo sirven para validad una página estática. ¿alguien es capaz de imaginarse la red a base de págins estáticas? ¿alguien es capaz de soportarlas? ¿son eficaces (y eficientes) en todos los casos las páginas estáticas? Puede valer bien para un periódico, un blog, un foro, etc. pero, afortunadamente, la red es algo más.
La interacción es lo que hace que evolucione la red (y cada vez más). Si nos limitamos a nuestras "cómodas" páginas estáticas nos quedaremos aún más obsoletos que esos validadores. Ya no estoy hablando de presentaciones multimedias, Flash, o demás, un simple formulario en el que según cambies un dato actualize automáticamente otro sin necesidad de un viaje al servidor dará una absoluta falta de accesibilidad
¿es falta de accesibilidad o dejadez para que sea accesible al resto de los navegadores "no convencionales"? ¿nos hemos conformado con "tachar" a una página como no accesible en lugar de mejorar nuestra tecnología? ¿no se podrían hacer sillas de ruedas que suban escaleras? (si es que no, simplemente he de decir que es una absoluta pena)

Enviado 13-01-2006

#9 herramientas automáticas Por Carlos Revillo

Sí que creo que una herramienta presentada de esa manera podría servir para vender mejor este asunto... el problema es que ninguna herramienta tiene la capacidad de determinar si una web es accesible o no lo es. puede determinar si le has puesto alt a las imágenes, si has escrito código válido, etc, es decir puede hacer una serie de comprobaciones automáticas pero ellas mismas te avisan de ciertas cosas que tú (o tu cliente) tienes que comprobar a mano. Es decir, la herramienta nunca sabrá, y eso también es parte de la accesibilidad, que los "alt" metidos tengan que ver con la imagen a la que quieren sustituir o si las diferencias de contrastes entre colores de fondo y colores de letra...

Enviado 15-01-2006

#10 validadores automáticos Por Sonia

yo particularmente uso el TAW y aunque no es suficiente para determinar si un site es accesible, si es verdad que facilita en gran medida el trabajo.
Sobre el artículo tengo una duda acerca del uso de medidas relativas. Una de las pautas para AA dice que se deben utilizar medidas relativas tanto en el código de la página como en la CSS, si esto es así como es posible que muchos sites que dicen ser AA tienen un diseño que no se redimensiona. Los validadores no lo marcan como error porque no analizan la css, pero eso no quiere decir que esté mal ¿no?

Enviado 24-01-2006

#11 Poco riguroso Por Rumoroso

Hola. No es por tocar las narices, pero creo que el artículo no es demasiado riguroso y que el enfoque no es (a mi modo de ver) correcto.
Las herramientas de comprobación de la accesibilidad son precisamente eso, "herramientas" que sirven al desarrollador. Las herramientas de comprobación automática sirven para echar un primer vistazo a la web y nunca te van a decir que tu web es accesible. De decir algo, será todo lo contrario. Sirven para comprobar el cumplimiento de ciertas pautas básicas accesibilidad, pero para nada más.
Pienso que deberías haber mencionado que tras el análisis automático, se debe realizar el análisis manual. Por ejemplo, la herramienta te puede decir que no has usado un texto alternativo en una imagen, pero de haberlo puesto no esperes que te digan que es el adecuado para dicha imagen.
Me gustaría saber el enfoque que le tratas de dar a lo de "vender que la página desarrollada es válida". En lugar de eso habría que "vender que la página desarrollada es accesible". No hay que confundir términos. La accesibilidad no se "valida", se "evalua".
Por cierto, te contradices al insistir en separar contenido de presentación y poner luego un ejemplo de tabla que no lo cumple (border="1" cellpadding="0").
Más importante que el caption en la tabla, es el atributo "sumary". Y para indicar los títulos, deberías poner el atributo "scope" en los th.
Otra puntualización. No digas eso de "el viejo HTML". En realidad, el HTML con esas etiquetas (font, leftmargin,...) no es ni viejo ni joven, es el mismo que ahora. Simplemente su uso "hasta el momento fue incorrecto" y eso es lo que hay que evitar.
Y si lo que quieres es convencer a tu cliente de que la web que has hecho para él es accesible, presenta un informe que lo explique.
Un saludo

Enviado 12-01-2006

#12 No está mal para empezar Por Aeon

Despues de leer el documento que no ocupa, y a modo de crítica constructiva, cre que este es un buen documento para partir en cuanto a accesibidad, yo la verdad es que llevo dedicandome a realizar webs accesibles desde hace algún año, y realmente aún después de tanto tiempo, me he dado cuenta de que los validadores simplemente sirven para conseguir un OK de cara al cliente de que la página es accesible, y es más, las empresas que se dedican a dar los certificados de accesibilidad son tanto mas de lo mismo, un documento que te certifica que la web desarrollada es accesible.¿Pero esto siginifica que es 100% accsible?. Mi respuesta es NO.

Tras realizar test de usuarios, por ejemplo nos dimos cuenta que a la hora de maquetar campos de texto de formulario, un validador como el TAW nos obliga a rellenar los campos de texto, y que no estén vacios. Esto es importante de cara a conseguir menos errores automáticos en la validación del TAW pero de cara a un usuario ciego, por poner un ejemplo, es terrible que cada vez que se posicione en un campo tenga que borrar el texto que hay introducido dentro del campo en cuestión. Aunque esto es un solo ejemplo puntual, podría poner una serie de puntos importantes de cara a conseguir una web accesible y que por ejemplo no nos dice ningún validador, como por ejemplo:

Utilizar tittle, en los links, para que?, para informar al usuario que es lo que hace el link en cuestión o mejor dicho, a donde nos va a llevar, si se carga en una ventana a parte informar al usuaario que se cargará en una ventana aparte para que sepa que se sale del flujo de navegación habitual.
- Otra práctica habitual es utilizar textos ocultos para usuarios normales y mostrarlos para los usuarios discapacitados, para que sepan por ejemplo que estan en una zona específica del documento.

- Los alts de las imágenes no sirven que sean siempre el mismo texto, esto está claro que nos dará el OK de la validación pero por ejemplo si tenemos un lista de productos y un icono a su derecha de comprar, no sirve de nada que pongamos como alt de la imagen, "comprar articulo", más bien sería necesario el poner que es lo que se va a comprar, para ser mas concretos.

- En cuanto a lo que he leido por arriba de las tablas, en efecto es mucho mas importante asignar la dirección de lectura de la tabla e igualar los id con los headers para poder ayudar a un usuario discapacitado a leer la tabla en su mayor complejidad. El caso de los summary es exactamente igual de útil y necesario, definir que es la tabla, para que se utiliza, que se muestra en ella e intentar ser lo mas específicos posibles.

- Ademas de ser tambien muy necesario jerarquizar perfectamente los componentes de la páginas, posicionar el menú en el orden lógico de presentación y dar la posibilidad de poder saltar el menu de navegación para así poder acceder directamente al contenido de la página.

Esto entre otras muchas cuestiones, por eso me parece muy útil este artículo como punto inicial del estudio de accesibilidad. Aunque para aprender nada mejor que trabajar en ello, como todo en esta vida....

Un Saludo.

Enviado 22-02-2006

#13 está bueno para principiantes pero... Por Ronald Abegg

Hoy día es mucho mejor ir mostrando ya desarrollo de paginas web utilizando CSS, es decir XHTML en vez de HTML simplemente, puesto que ya está comprobado este estilo de diseño y desarrollo como "lo mejor".

Entonces, sería interesante un documento similar al presentado pero mostrando la utilización de (div) en vez de (table)(tr)(td), de todos modos está muy bueno el articulo, puesto que enfoca otros puntos importantes como el uso de los headings (h1, h2, etc), imagenes, titulos, estilos para definir footer, header, etc.

Saludos y fuerza!

Enviado 17-04-2006