How screen readers speak a page with HTML5 and ARIA

After seeing how AT reads a content generated with CSS pseudo-elements I was thinking to move on to HTML5. And since there are a lot of people saying we should mix HTML5 with ARIA in order to increase the accessibility of a website, then why not test and see what happens?

A piece of code…

...
 
<header id="header" role="banner">  
    <div id="logo">Logo here</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>     
...

This is the page containing both HTML5 elements:

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

and ARIA roles (learn about ARIA):

  • role=”banner” – for the header element
  • role=”navigation” – for the nav element
  • role=”main” – attached to the section
  • role=”application” – in case I need to add a widget
  • role=”article” – for the article element
  • role=”complementary” – for the aside
  • role=”contentinfo” – for the footer

How NVDA, JAWS and Window Eyes read the HTML5-only version

Long story short, no screen reader noticed the HTML5 elements – as expected. They all behaved like those elements were simple DIVs and read the webpage accordingly.

How NVDA, JAWS and Window Eyes read the HTML5 + ARIA version

Much better this time, ARIA is doing wonders although I don’t understand why Window Eyes doesn’t even pronounce the existence of the headers…I am a newbie in this field so maybe I did something wrong? I do not want to do WE any injustice so let’s say the results are inconclusive regarding this software.

The difference

So what was the difference between the two versions? What ARIA brought from this point of view?

The banner area: 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……. ” At the beginning it also says that there are 8 landmarks, hurray!!!

The main area: role=”main”

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

The application area: role=”application”

NVDA – the application role was not read at all.
JAWS – “application landmark here is where….”

The articles: role=”article”

NVDA – the article was not mentioned in any way.
JAWS – “article landmark heading level….”

The sidebar: role=”complementary”

NVDA the sidebar was read like this: “complementary landmark heading level 2…..”
JAWS – “complementary landmark heading level 2…..”

The footer: role=”contentinfo”

– and the footer: “content info landmark this is where the….”
JAWS – “content info landmark this is where the….”

So far JAWS was the only one able to speak all the landmarks while NVDA missed the article and the application. Like I mentioned before, Window Eyes din not read ARIA elements but maybe it’s just me being a newbie…Your opinion is much appreciated, maybe together we can make it work 🙂

Check the Spanish version of this post:
Cómo leen los lectores de pantalla una página con HTML5 y ARIA

Testing the accessibility of the CSS generated content

This article is about how screen readers speak the content added with CSS pseudo-elements :before and :after (in CSS3 they are ::before and ::after).

I am trying to learn to use AT when developing websites and recently I saw that no matter how W3C wants us to use a certain CSS element, there will always be developers/designers who will try to push the limits of the specification.

While I do advise you to NOT use pseudo-elements to generate useful content (limit yourself to generating quotes or design elements), just in case somebody thinks that the cool resides in generating content with CSS because everything else is already old, let’s see how people using screen readers will “benefit” from the idea.

A piece of code…OK, maybe two…

The HTML is really simple, an innocent paragraph of text:

<h1>Example of content added with CSS pseudo-elements</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit..and so on.</p>

and the CSS is also quite simple:

#content p:before {
content:"This is before the text, you can style it";
}
 
#content p:after{
content:"This is after the text";
}

Let’s hear voices

The video will show how NVDA, Jaws and Window Eyes read the page – I set NVDA to read at a lower rate in order for you to follow, but the other 2 are a bit faster.

The conclusion

There’s no need for me to tell you how bad the idea is, DON’T use these pseudo-elements for generating useful content, limit its use to generating quotes, breadcrumb icons, fluffy snowflakes or whatever. But keep it presentational in order for other people to have access to the useful stuff.

Check the Spanish version of this post:
Probando la accesibilidad del contenido generado por CSS

Reasons to be cheerful – Chris Heilmann talking at Fronteers 2010

For those of you webdevelopers who have 1 hour to spare I am offering this Chris Heilmann talk at Fronteers 2010 in Amsterdam. I promise you it’s funny, engaging, motivating and it will make you feel good to be a part of the web world 🙂

You can find information on the Fronteers Conference website and all the 14 sessions (about HTML5, CSS3, Accessibility, Javascript, Design and more) are now on their Vimeo channel.