W3C: fallos de accesibilidad (I)
16:00 H (CET)| Temas: Accesibilidad · How to · W3C
Hoy vamos a empezar una serie de artículos en los que pretendemos explicar los fallos que se cometen en accesibilidad cuando se realizan aplicaciones web y las técnicas que debemos usar para evitar estos fallos. Para ello nos basamos en lo que especifica la W3C en su WCAG 2.0 (aún en estado borrador).
Error 1: modificar el significado del contenido debido al posicionamiento mediante CSS
Se trata de cambiar el significado semántico de una etiqueta, modificando su posicionamiento mediante CSS. Por ejemplo, si queremos crearnos una lista de elementos:
- Elemento 1
- Elemento 1.1
- Elemento 1.2
- Elemento 1.3
- Elemento 2
- Elemento 2.1
- Elemento 2.2
El fallo consiste en usar etiquetas no destinadas a ese sentido, cambiarle los estilos y representarlas como queremos. Por ejemplo podemos usar span para representar cada elemento y disponerlos en la posición que nos conviene:
<span class="cab1">Elemento 1</span>
<span class="cab2">Elemento 2</span>
<span class="ele1">Elemento 1.1</span>
<span class="ele2">Elemento 2.1</span>
<span class="ele3">Elemento 1.2</span>
<span class="ele4">Elemento 2.3</span>
Y con los estilos siguientes:
.cab1 {
position: absolute;
top: 0px;
left: 0px;
}
.cab2 {
position: absolute;
top: 0px;
left: 200px;
}
.ele1 {
position: absolute;
top: 20px;
left: 0px;
}
.ele2 {
position: absolute;
top: 20px;
left: 200px;
}
.ele3 {
position: absolute;
top: 40px;
left: 0px;
}
.ele4 {
position: absolute;
top: 40px;
left: 200px;
}
obtendríamos el mismo resultado visual, pero si quitaramos los estilos obtendríamos lo siguiente:
Elemento 1 Elemento 2 Elemento 1.1 Elemento 2.1 Elemento 1.2 Elemento 2.3
lo cual no tendría mucho sentido.
Error 2: modificar el aspecto del texto para mostrar algo que ya representa una etiqueta
Existen varias etiquetas de texto que tiene diferentes funcionalidades, pero aún así es típico encontrarse textos con sus estilos modificados para mostrar el resultado de una etiqueta ya existente. Un ejemplo muy común es este:
<span class="negrita">Título</span>
.negrita {
font-weight: bold;
}
Lo correcto sería usar la etiqueta strong.
Más información
Relacionados
Feedback (12) » Formulario
1. Carlos ~ Miércoles, 23 May 2007 | 18:05H:
No estoy muy de acuerdo en considerar el span class="negrita" como un error. A fin de cuentas strong tiene carga semántica que puede ser que no te interese si lo único que estás haciendo es modificar el aspecto del texto, sin ningún otro tipo de objetivo.
Vamos, que según lo veo yo, será error o no dependiendo del objetivo que se pretendiese.
2. Luis ~ Miércoles, 23 May 2007 | 19:17H:
Hola Carlos, según yo lo veo (que no tiene que ser lo correcto, por supuesto), si lo que quieres es que por ejemplo el texto de los inputs sea negrita, pues adelante, es un adorno, como quien pone la letra en azul. Pero si en un párrafo, cierto texto lo marcas como negrita, no sé si es el objetivo, pero la consecuencia sí es que lo resaltas. Una persona con discapacidad, al no disponer de estilos no será capaz de darse cuenta de que ese texto está resaltado, sin embargo, si se lo incluyes dentro de etiquetas strong, ya podrá saber que ese texto esta resaltado.
Saludos
4. RetroFOX ~ Miércoles, 23 May 2007 | 20:09H:
Al fin y al cabo ... html es una extensión de xml donde se definen TAGs particulares al lenguaje que de alguna manera marcan el comportamiento natural de los mismos.
Los browsers tienen que implementar en forma nativa este comportamiento. No tiene sentido definir .negrita lo mires por donde lo mires: cantidad de código, rendimiento del browser, legibilidad, compatibilidad, etc ...
5. Luis ~ Miércoles, 23 May 2007 | 23:04H:
Yo entiendo a Carlos, el mismo pensamiento que él tiene ahora, lo tenía yo hace tiempo. Supongo que porque cuando empezaron a salir los CSS era un "haz lo que te de la gana", mientras que antes usabas H1..H6 porque era la única forma de poder resaltar texto.
Gracias por los comentarios
6. Albert ~ Jueves, 24 May 2007 | 07:17H:
Creo que a lo que se refiere Carlos es a que hay situaciones en las que quizás la negrita vaya a usarse exclusivamente como un recurso estético, y no funcional, para enfatizar cierto contenido. Ahí sí que tendría sentido usar un span con determinada clase, y no un strong. La idea en definitiva sería no alterar el carácter del contenido por una necesidad exclusivamente visual.
En cualquier caso, lo que sí que vería un error sería usar "negrita" como nombre de la clase. Lo suyo es evitar nombres que se correspondan con apariencias concretas: centered, left-aligned, blue, y ese tipo de cosas.
Un saludo!
7. Luis ~ Jueves, 24 May 2007 | 08:14H:
Albert, es que tú mismo lo has dicho: "enfatizar cierto contenido", eso no es estética, es funcionalidad. Cuando tu enfatizas un contenido lo que haces es que el visitante repare en ese trozo de texto antes que cualquier otra zona del texto.
Resaltar es funcionalidad, estético sería si dices que la etiqueta strong no es font-weight: bold, sino que es font-weight: normal y color: blue;. En este caso lo resaltarías del resto del texto, pero en vez de en negrita, lo harías con el color azul.
Saludos
8. Albert ~ Jueves, 24 May 2007 | 11:58H:
Claro, justo a eso me refería cuando decía "[...]y no funcional, para enfatizar cierto contenido[...]". Es decir, deberíamos usar sólo cuando realmente queramos enfatizar un texto, y no únicamente porque strong muestre el texto en negrita. Quizás no construí bien la frase. :)
Por poner un ejemplo chorra, imagina que escribo el titular de una web, en la cabecera. sentidoweb, por decir algo ;) , y quiero jugar con la apariencia de cierta parte de la palabra: quiero que "web" aparezca en negrita y "sentido" en grueso normal. -> sentidoweb . Para ese caso, usar un <strong> no sería correcto. Lo suyo sería usar un <span> con una clase específica.
Espero haberme explicado mejor esta vez. :)
Un saludo!
9. Albert Garcia ~ Jueves, 24 May 2007 | 12:00H:
En el primer párrafo:
[...]deberíamos usar <strong> sólo cuando realmente[...]
sorry, se coló la etiqueta... ¬¬

