Category Archives: Accesibilidad web

Como crear páginas accesibles, formularios de contacto, validación accesible con PHP, Javascript, Mootools y ARIA, videos sobre ARIA y lectores de pantalla.

Cómo leen los lectores de pantalla una página con HTML5 y ARIA

Despues de ver cómo AT lee un contenido generado con pseudo-elementos CSS estaba pensando en pasar a HTML5. Y como hay muchas personas diciendo que deberíamos mezclar HTML5 con ARIA para incrementar la accesibilidad de un sitio web, entonces, ¿por qué no probar y ver lo que pasa?

Un poco de código…

...
 
<header id="header" role="banner">  
    <div id="logo">Logo</div>
    <nav role="navigation">
        <ul id="mainnav">........</ul>
    </nav>
</header>
 
<section id="content" role="main">  
 
    <h1>A level one heading here please</h1>
 
    <div role="application"><p>Here is where an application will be coded. </p></div> 
 
    <article role="article">             
            <h2 class="index-headings">Blog entry no 1</h2>
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit...</p>
    </article>
 
    <article role="article">
            <h2 class="index-headings">Blog entry no 2</h2>
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit...</p>
    </article>
 
</section> 
 
<aside role="complementary">  
    <h2>Sidebar</h2>
    <ul>......................</ul>
</aside>
 
<footer id="footer"  role="contentinfo">This is where the footer will stay.</footer>     
...

Esta es la página con ambos elementos HTML5:

  • header
  • nav
  • section
  • article
  • aside
  • footer

y los roles ARIA (aprende más sobre ARIA):

  • role=”banner” – para el elemento header
  • role=”navigation” – para el elemento nav
  • role=”main” – anexo a section
  • role=”application” – en caso de que necesite añadir un widget
  • role=”article” – para el elemento article
  • role=”complementary” – para aside
  • role=”contentinfo” – para footer

Cómo NVDA, JAWS y Windoes Eyes leyeron la versión con sólo HTML5

Para hacer la historia corta, ningún lector de pantalla notó los elementos HTML5 – como se esperaba. Todos se comportaron como si esos elementos fuesen simples DIVs y leyeron la página web de acuerdo a esto.

Cómo NVDA, JAWS y Windoes Eyes leyeron la versión HTML5 + ARIA

Mucho mejor esta vez, ARIA está haciendo maravillas aunque no entiendo por qué Windows Eyes ni siquiera pronuncia la existencia de estos encabezados… Soy un novato en este campo así que, ¿tal vez hice algo malo? No quiero cometer una injusticia con WE así que digamos que los resultados fueron inconclusos en relación con este software.

La Diferencia

Así que cuál era la diferencia entre las dos versiones? Qué aportó ARIA desde este punto de vista?

El área del banner: role=”banner”

NVDA – “banner landmark logo here navigation landmark list with 4 items visited link home……. ”
JAWS – “banner landmark logo here navigation landmark list with 4 items visited link home……. ” Al principio también dijo que habían 8 marcas, muy bien!!!

El área principal: role=”main”

NVDA – “main landmark heading level one …”
JAWS – “main landmark heading level one …”

El área de aplicación: role=”application”

NVDA – no se leyó el rol de aplicación.
JAWS – “application landmark here is where….”

Los Artículos: role =”article”

NVDA – el artículo no fue mencionado en lo absoluto.
JAWS – “article landmark heading level….”

La Barra lateral: role=”complementary”

NVDA la barra lateral fue leída de esta manera: “complementary landmark heading level 2…..”
JAWS – “complementary landmark heading level 2…..”

El pié: role=”contentinfo”

– y el pie de pagina: “content info landmark this is where the….”
JAWS – “content info landmark this is where the….”

Hasta ahora JAWS fue el único capaz de leer todas las marcas mientras que NVDA falló en el artículo y la aplicación. Como mencioné antes, Windows Eyes no leyó los elementos ARIA pero tal vez soy sólo yo siendo un novato… Aprecio mucho tu opinión, quizás juntos podamos hacer que funcione. 🙂

Probando la accesibilidad del contenido generado por CSS

Este artículo es acerca de cómo los lectores de pantalla leen el contenido añadido con pseudo elementos CSS :before y :after (en CSS3 son ::before y ::after).

Estoy tratando de aprender a usar tecnología asistiva cuando desarrollo sitios web y recientemente vi como no importa cuanto W3C quiera que usemos ciertos elementos CSS, siempre habrá desarrolladores/diseñadores quienes intentarán probar los límites de las especificaciones.

Mientras que te aconsejo que NO uses pseudo elementos para generar contenido útil (limitate a generar citas o elementos de diseño), sólo en caso de que alguien piense que lo estupendo resida en generar contenido con CSS porque todo lo demás ya es viejo, veamos cómo las personas que usan los lectores de pantalla se “beneficiarán” de la idea.
Continue reading

Bien por usted, está codificando sitios web accesibles, pero en realidad conoce algún usuario ciego?

Que le responde a su cliente cuando intenta explicarle que su código es W3c, semántico, multiexplorador y… accesible y su cliente le pregunta: “Bien por usted que codifica sitios web accesibles, pero en realidad conoce algún usuario ciego?”, quiero decir, por qué debe alguien preocuparse por cómo codificar un sitio si aún los sitios basados en tablas están bien baratos?

Bueno… usted puede permanecer sin palabras. Porque realmente no conozco ninguna persona ciega y menos usando tecnología asistiva, aunque conozco a personas que necesitan incrementar el tamaño de la fuente o bajar la resolución de la pantalla para poder leer mejor. Pero aún si no “ve” uno no significa que no existan – pero cómo puede ser esto probado?

Dado que las tecnologías asistivas no dejen rastros, tal vez una solución es ver quién está presionando los botones a+ a++. Esto debería dejar algún rastro verdad?.

Así que comenzamos un experimento: escribimos un script contando el número de veces que era presionado el botón a+ a++ (ya sé que no es muy científico – cualquiera podría darle click – pero estamos contando con el hecho de que nuestros usuarios no saben del experimento y al menos un pequeño porcentaje de clicks serán genuinos). Cada click es contado y escrito en un archivo. Lo comparamos con las estadísticas de Google Analytics y esperamos obtener información similar al respecto en otros sitios.

Luego de un mes de comparar ambos métodos vimos que la navegación a+ /a++ fue presionada a diario (aún y cuando un sitio estaba vendiendo decoraciones navideñas!!!) y la mayor parte del tiempo a++ fue la estrella, entre 5% y 8% de los visitantes hicieron click en estos enlaces y fueron más clicks que los hechos en los enlaces “Acerca de” y “Contacto”.

Ahora, la pregunta que comenzó este artículo permanece – Cuál es la mejor manera de responderle a un cliente que pregunte “Bien por usted que escribe código para sitios web accesibles, pero conoce usted realmente a un usuario ciego?”