WEBS REALIZADAS

miércoles, 13 de noviembre de 2013

Herramientas de validación

Algunas herramientas online que permiten la validación de páginas web:
Y un par de herramientas de validación que se han quedado un poco antiguas, pero que ofrecen algunas características interesantes:

jueves, 7 de noviembre de 2013

Los captchas han muerto

Los captchas son esas imágenes con letras y números que debemos descifrar en muchos sitios web para que "nos dejen pasar".
En Así funcionan los bots que adivinan los «captchas» nos explican que los captchas ya no son tan efectivos como podríamos pensar. En realidad, viendo el vídeo que acompaña a este artículo, me parece que los bots que resuelven captchas "son más humanos" que los humanos.

miércoles, 6 de noviembre de 2013

Cómo funcionan los lectores de pantalla

Los lectores de pantalla (screen readers) son difíciles de usar por varias razones. Una de ellas es que los lectores de pantalla tienen diferentes modos de funcionamiento. En el artículo How Windows Screen Readers Work on the Web se explican las dos formas principales de funcionamiento:
 
  • Modo documento
También llamado modo "virtual" o "browse". En este modo, el usuario no interactúa directamente con la página, sino con una copia cacheada por el lector de pantallas.
La interacción con el teclado es capturada y no se pasa directamente a la página web.

Este modo puede plantear problemas cuando se programa una funcionalidad asociada al teclado.

También plantea problemas el contenido dinámico, ya que los cambios pueden pasar desapercibidos para el lector de pantallas.


  • Modo aplicación
También llamado modo "form" o "focus".
Es el utilizado para interactuar con un formulario. Las pulsaciones de teclado son pasadas directamente a la página web, lo que permite utilizar los controles de un formulario.

martes, 5 de noviembre de 2013

Secretos escondidos de la accesibilidad de HTML5

El artículo The hidden treasures of HTML5 accessibility realiza un repaso de algunas de las nuevas características de HTML5 que mejoran la accesibilidad y no son todavía muy conocidas, como por ejemplo:
  • Subtítulos simplificados, gracias al nuevo formato (uno más) llamado WebVTT (Web Video Text Tracks).
  • Eliminación definitiva de los marcos (frames).
  • El diseño adaptativo, que permite personalizar la presentación de un sitio web a las necesidades y limitaciones de diferentes usuarios.

lunes, 4 de noviembre de 2013

Mejorar la legibilidad

La legibilidad es un indicador de calidad que se refiere a la facilidad de lectura y comprensión de un texto. Que un texto sea legible ayuda a hacer el contenido de un sitio más fácil de leer para todos y en especial para las personas con discapacidades para la lectura y/o cognitivas.
Una buena legibilidad mejora la accesibilidad de una página web, en especial de cara a los usuarios con problemas cognitivos.

Existen herramientas que permiten evaluar la legibilidad de los textos. Hace unos días me topé con dos recursos que se pueden aplicar a la legibilidad.

Por un lado, style-check es una herramienta que ayuda a mejorar los textos científicos. Básicamente, detecta aquello que es redundante o aquello que en realidad no dice nada (si se usase esta herramienta con los discursos de los políticos, se quedarían mudos).

Por otro lado, el artículo Make your research papers easy to skim ofrece unos sencillos consejos para que los artículos científicos sean fáciles de ojear. Lo que se dice ahí se puede aplicar también a las páginas web.

domingo, 3 de noviembre de 2013

Código para crear un mega menú accesible

Los mega menús son menús de tipo desplegable o drop down con decenas o cientos de opciones. En la página 25 Examples of Mega Menus in Web Design.
Estos menús plantean un reto, tanto desde el punto de vista de la usabilidad y la accesibilidad.

Adobe liberó hace unos meses el código que utiliza en sus mega menús: Open-source accessible mega menus. En la página Accessible Mega Menu se describe cómo está hecho y se muestra una demostración.

¿Las páginas tienen que ser válidas para ser accesibles?

Validar o no validar, e ahí la cuestión...

En WCAG 1.0, la pauta 3 "Utilice marcadores y hojas de estilo y hágalo apropiadamente" decía:
3.2 Cree documentos que estén validados por las gramáticas formales publicadas. [Prioridad 2]
Está claro que para cumplir WCAG 1.0, las páginas web tenían que ser válidas.

Sin embargo, en WCAG 2.0 hay un poco de confusión. La pauta 4 "Robusto" dice en su único punto 4.1 Maximizar la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas:
4.1.1 Procesamiento: En los contenidos implementados mediante el uso de lenguajes de marcas, los elementos tienen las etiquetas de apertura y cierre completas; los elementos están anidados de acuerdo a sus especificaciones; los elementos no contienen atributos duplicados y los ID son únicos, excepto cuando las especificaciones permitan estas características. (Nivel A) 
Nota: Las etiquetas de apertura y cierre a las que les falte un carácter crítico para su formación, como un signo de "mayor qué", o en las que falten las comillas de apertura o cierre en el valor de un atributo, no se consideran completas.
Y si se consulta Cómo cumplir 4.1.1, la técnica G134 Validating Web pages hace referencia explícita a la validación de HTML y CSS.

Por tanto, sí que las páginas tienen que seguir siendo válidas para poder cumplir con WCAG 2.0. Y hay varios expertos que confirman la importancia de validar el código:
Sin embargo, hay algunos autores que no piensan los mismo. Por ejemplo, en el artículo WCAG Next pone:
Remove Parsing Requirement
While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA.