Category Archives: HTML5

This is our HTML5 lab: testing new features, combining them with CSS3 and checking their accessibility.

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

Using CSS3 to style forms written in HTML5

Styling a form is never an easy thing to do, but adding CSS3 on a HTML5 form is a task that shows a large variety of results when it comes to testing on different browsers. Check the test link.

When it comes to CSS3 not much can be done: but adding rounded corners, gradients and dropshadows is still more than nothing anf the overall aspect of the form is waaaaaaaaay better. But HTML5 is supported by few browsers (this HTML form only by Opera) and CSS3 also by few broswers – but different from the one supporting HTML5.

The result: impossible to see the result on one browser only: the rounded corners can be seen on Mozilla/Chrome/Safari and the HTML5 elements on Opera.

Internet Explorer? Better don’t ask. No support whatsoever.

So the results:

  1. Mozilla 3: rounded corners + / HTML 5 elements
    capture-2
  2. Chrome: rounded corners + (they look weird) / HTML 5 elements –
    chrome-screenshot
  3. Safari: rounded corners + / HTML 5 elements –
    capture-3
  4. Opera 9: rounded corners – / HTML 5 elements +
    capture-1
  5. IE (doesn’t matter which one): rounded corners – / HTML 5 elements –
    ie8-screenshot

It seems we have to wait a little longer till we can drop Javascript from styling the forms  :(

UPDATE

Ric Ferrer sent us a screenshot with the behavior of Mobile Safari from his Ipod. Thank you :)

37555934

Check the Spanish version of this post:
Usando CSS3 para dar estilo a formularios escritos en HTML5

A third way to write and validate forms – HTML5

After writing an accessible form in XHTML and validating it with a PHP server side script & after that with a Mootools client-side script, I write today about a third way of approaching the subject – using future-to-come HTML5 (by saying that, I really hope to be able to use it waaaay before 2011).

The beauty consists in having all the above mentioned validation inside HTML code:  we’ll have

  • input type=”email” for email addresses
  • type=”url” for urls
  • type=”date” and “datetime” for date fields (usually done with JS calendars until now), or “month”, “week”, “time”
  • type=”number”  for number only inputs
  • accessible sliders, with type=”range”
  • datalists
  • ability to add extra validation conditions after writing the tag, like: required, read-only,disabled, autofocus, a minimum value, a maximum accepted value/length

The code for our simple contact form will be much lighter:

<form action="index.php" method="post" name="contactform" id="contact">
 
<label for="name">Name <span>(required)</span></label>
<input  tabindex="1" type="text" name="name" id="name" required />
 
<label for="mail">Email <span>(required)</span></label>
<input  tabindex="2" type="email" name="mail" id="mail" required />
 
<label for="phone">Telephone</label>
<input tabindex="3" type="text" name="phone" id="phone" />
 
<label for="message">Message</label>
<textarea tabindex="4" cols="30" rows="10" name="message" id="message"></textarea>
 
<button tabindex="5" type="submit" name="submit" id="send">Submit</button>
 
</form>

The result will be a much easier way of writing and validating forms in an accessible manner, without adding extra load/code with PHP/JS scripts. All you have to do is place “required” to all the required fields and use the above mentioned minimum value, maximum accepted value, etc to control the user’s input.

The entire list of types and useful tables with the methods that apply to each state can be found on W3C site

The problem right now is the inabilityof the browsers to work with lots of HTML5 features. And the future does not look good either. So far the only browser that supports the new forms is Opera 9.5+.  Internet Explorer 8 and below is not compatible and IE9 probably won’t be either (we’re talking about 2010).  Chrome 2+, Safari 4+ will partially support some features while Mozilla won’t do it even in its 4.0 version (due to launch in 2010).

Now, the same contact form we used to play with, but written in HTML5, will look the same but behave much more nicely (the code is lighter too). It’s saving us a lot of time and headaches and it’s much more user friendly.  Play with the new example – in Opera 9.5+ – and drop us a feedback if you consider that the subject is interesting enough to come back with more code-examples.

Check the Spanish version of this post:
Una tercera manera de escribir y validar formularios – HTML5