Tag Archives: html5

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. 🙂

Usando CSS3 para dar estilo a formularios escritos en HTML5

Dar estilo a un formulario nunca es algo fácil de hacer, pero añadir CSS3 a un formulario HTML5 es una tarea que muestra una larga variedad de resultados en lo que se refiere a probar diferentes navegadores. Mire el link de prueba.

En lo que se refiere a CSS3 no es mucho lo que se puede hacer: pero añadir esquinas redondeadas, gradientes y sombras es mas que nada y el aspecto general del formulario es muuuuuuuuucho mejor. Pero HTML5 es soportado por pocos navegadores (éste formulario HTML sólo por OPERA) y CSS3 también por algunos navegadores – pero diferentes del que soporta HTML5.

El resultado

imposible ver el resultado en sólo un navegador: las esquinas redondeadas pueden ser vistas en Mozilla/Chrome/Safari y los elementos HTML5 en Opera.

Internet Explorer? Mejor ni pregunte. No hay soporte aún.

Así que los resultados:

  1. Mozilla 3: esquinas redondeadas + / elementos HTML5 –
    capture-2
  2. Chrome: esquinas redondeadas + (se ven extrañas) / elementos HTML5 –
    chrome-screenshot
  3. Safari: esquinas redondeadas + / elementos HTML5 –
    capture-3
  4. Opera 9: esquinas redondeadas – / elementos HTML5 +
    capture-1
  5. IE (sin importar cual): esquinas redondeadas – / elementos HTML –
    ie8-screenshot

Parece que tendremos que esperar un poco más hasta que podamos lanzar Javascript desde dar estilos a las formas.

ACTUALIZACIÓN

Ric Ferrer envió una captura de pantalla con el comportamiento del safari móvil desde su Ipod. Gracias 🙂

37555934