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

Related posts:

1. Useful 10 minutes of WAI ARIA
2. 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

Related posts:

1. How screen readers speak a page with HTML5 and ARIA
2. Useful 10 minutes of WAI ARIA

I would like to post here a selection of resources that might help you start using ARIA in your web applications or websites – although ARIA is still a draft. you can start using it and some AT will know how to read it.

Introduction to WAI ARIA

Written by Gez Lemon for Opera Developer, this article is the best post you can start with. You will understand why ARIA was created in the first place and you will understand some basic terms like: roles, states, properties, and my favorite, ARIA regions.

ARIA Roles 101

Now that you know the basics of ARIA, you can start implementing ARIA roles in your applications. A full list of the roles definitions can be seen here, at the W3C WAI ARIA 1.0 specs website.

Supported states and properties

Learning about ARIA properties is the next logical step, and the W3C WAI ARIA specifications are really helpful even if the first impression is that you read the Constitution or something

Try some demos: ARIA Live Regions Screen Reader Demo

A very useful video by Aaron Cannon (from cannonaccess.com) about using ARIA live regions in a correct way, the difference between aria-live=”polite” and aria-live=”rude” and how this whole thing works. You need to know that now aria-live=”rude” is not part of the specs anymore (it was really too rude) and we are left with “off”, “polite” and “assertive”.

You might wanna read ARIA and Progressive Enhancement written by Derek Featherstone for A List Apart because the small examples that you will find there will help you understand better the roles and the properties of ARIA.

If you wanna go back to reading the Constitution, WAI-ARIA 1.0 Authoring Practices – An author’s guide to understanding and implementing Accessible Rich Internet Applications is the next step, a page full of examples for you to learn from and best practices when it comes to implementing ARIA – pay special attention to Section 3: Keyboard and Structural Navigation, Section 4: Relationships and Section 5: Managing Dynamic Changes which is really really important.

Learn from examples

• JQuery Widget Samples – a collection of common JQuery widgets made accessible with ARIA: sliders, progress bars, accordions, trees, carousels, tabs, etc….
• jQuery-Accessible-RIA – adds some more ARIA examples: a form, a lightbox, tables, etc.

Update with more minutes of WAI ARIA

Aaron Gustafson also has a video with NVDA reading his now famous TabInterface.

TabInterface in Firefox using NVDA screenreader from Aaron Gustafson on Vimeo.

Check the Spanish version of this post:
10 minutos útiles de WAI ARIA

Related posts:

1. How screen readers speak a page with HTML5 and ARIA

What can you answer to your client when you try to explain that your code is W3c, semantic, crossbrowser and…accessible and your client asks you “Good for you you’re coding accessible websites, but do you actually know any blind user?” Meaning, why should someone care about how you code a site as long as table-based code is still ok and cheap?

Well…you may remain speechless. Cause I really don’t know any blind person nor a person using assistive technology altough I do know people that need to increase the font-size or lower the screen resolution to be able to read better. But even if I did not “see” one that should not mean they don’t exist – but how can this be proved?

Since assistive technologies do not leave traces, maybe a solution is to see who’s clicking the a+ a++ buttons. This surely will leave some trace, right?

So we started an experiment: we wrote a script counting the number of clicks performed on the a+ a++ buttons (I know it’s not very scientific – anyone can click – but we’re counting on the fact that our users do not know about the experiment and that at least a small percentage of the clicks will be genuine). Every click is counted and written in a file. We compare it to the Google Analytics stats and hope to obtain some information about this aspect of the sites.

After a month of comparing both methods we saw that the a+/ a++ navigation was clicked on a daily basis (even though one site was selling Christmas decorations !!! ) and most of the time a++ was the star ! Between 5% and 8% of the visitors were clicking these links and that is more than the number of clicks on “about” or “contact” links.

Now, the question that started this article remains – what is the best answer for the client asking  “Good for you you’re coding accessible websites, but do you actually know any blind user?”

No related posts.

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

Related posts:

1. Useful 10 minutes of WAI ARIA

As we discussed in a previous article about forms -Basic copy-paste accessible contact form -  we made the form validation accessible using a class that will highlight and point to the elements that need to be filled or corrected in case the validation failed.

Now, the only weak point form the user’s point of view is the fact that we need to refresh the page every time he hits submit, this being somehow annoying. Nowadays most browsers offer a client-side processing capabilities ( javascript ) that can be used for local validation – avoiding the refresh of the page.

Don’t get me wrong. The server side part needs to remain intact for accessibility purposes. 

The last MooTools version offers a validation plugin in the mootools-more package, that will help us to solve our task. Basicaly we need to add some classes to out inputs, to reflect the type of validation we want. For our form, we need only name – mandatory, and email –  mandatory + correct email formating.

So we’ll use required and validate-email from the list of the validators already included, like this:

<label for="name"> Name <span> (required) </span></label>
<input  tabindex="1" type="text" name="name" id="name" class="required" />
<label for="mail"> Email <span> (required)</span></label>
<input  tabindex="2" type="text" name="mail" id="mail" class="validate-email required" />

The next step is to create the code that does the validation:

On the domready event of the window (we need to allow the html to load and therefore to be able to access it)  we attach the validator to our form with the methods needed to show the user what he did wrong (in case he did it). To keep the presentation and the accessibility intact – as in the back-end validation – we  will add the next code:

window.addEvent('domready', function(){
	var myFormValidator = new FormValidator($('contact'), {
		onFormValidate: function(ok) {
			$('error_wrapper').getElements('a').dispose();
			if (!ok) {
				$('contact').getElements('.validation-failed').each( function(el) {
					var a = new Element( "a",{'href' : "#add"})
                            .addEvent('click', function(){ el.focus(); return false; })
                            .set('text', el.get('id').capitalize() )
                            .inject($('error_wrapper'));
				})
 
				$('error_wrapper').setStyle('display','block');
			}
			else {
				$('error_wrapper').setStyle('display','none');
			}
		},
		stopOnFailure:true,
		evaluateFieldsOnBlur:false
	});
})

Ok, it’s a little long but basically it’s validating each field it needs to, as specified in the class, and attach in the error_wrapper the labels to the erroneous inputs.  It’s better to study the code and see exactly how it’s done.

Now, what is happening?

The MooTools library is validating each field we specified on the submit event of the form and adds by default a class validation-failed or validation-passed to each field that was submitted to the validation routine.

We can use these two classes to visually improve the form – here I just made the faulty ones red. If the validation failed the submit event of the form is stopped  and the incomplete data is not reaching the server.

Next step: to complete the correct data, and resubmit.

Here is the DEMO

The form validator class is more powerful than this so take a look at the documentation on the MooTools site.
Anyway, no matter what you do, do not forget to make the server side validation too. It is mandatory for your (server’s ) security.

Related posts:

1. How to make a glowing menu with MooTools in 3 easy steps

A good way to learn about accessibility is through examples and discussions. In this post I will try to translate the WCAG sometimes-hard-to-get rules into a copy-paste real contact form example.  You can check the test link, download the code and/or keep reading a bit more.

As I mentioned before, contact forms are in great need of special markup in order to be accessible. And it seems that there’s always room for improvements – in case you have suggestions or your approach is different,  I’d love to hear from you.

My suggestion is a simple 4 fields contact form with PHP server side validation. After the user submits the required information the page is reloaded and new messages are displayed depending on the user actions.  Of course you all know that the form needs

<label for="name">

tag and some sort of validation – everybody is writing about the need to display in an accesible way which fields are required and also the error messages (usually indicating the missing fields)  – but few actually offer a simple straightforward code to copy-paste in our sites.

The stylesheet is very light – we have to style the form – but the novelty is a class for the fields that are required and not yet filled. This way after we validate we return the error message with links to the missing fields but we also hightlight them for a more usable and intuitive experience. The PHP part is reading the inputs, checks them and sees if the required ones were filled.  A thank you message is displayed in case the user filled all the required fields.

The number of fields can easily be increased but don’t forget to validate them -when someone understands how the form works and which were the accessibility elements that were included then buiding more complex forms becomes just a matter of typing.

Check the Spanish version of this post:
Un básico copia y pega de un formulario de contacto accesible

No related posts.

When it comes to accessibility, every coder is a small guru. On the websites where I bid for projects everybody is an accessibility and usability expert (including myself, I admit).

Altough these rules exist for quite a while there are coders who find it difficult to implement them – so I am trying to find here what are the tricks that you use in writing your code to make it accessible.  For example, altough writing semantic code helps (a lot !) it is not always enough.  Some try to view their pages with CSS and images disabled, some don’t.  Some of us have tricks that we do not want to share to other coders.  Some of us share. We’re not all gurus, right? Someone has to start from somewhere.

So if you have something interesting to say, add your own rules here.

Let’s start with basic common sense:

1. write semantic and valid code – use correct tags while trying to satisfy Google’s needs – adapt the tags to the context
2. use lists for navigation and for consecutive link blocks
3. write accessible forms : use labels, server-side validation, even fieldset where necessary. Should I use type=”image” with alt text instead of submit? I don’t know….I like submit. Camino does not (
4. use the skip to content or skip navigation links. Everybody say you should….
5. using a .wai class to hide text that might help screen readers – some people use display:none (not so good), some use negative indent.
6. provide transcriptions for video files (does Google do that for YouTube?), alt tags, longdesc tags, explanation for graphics (the coders who built Forex sites did that?), audio CAPCHA (do you do that???)
7. other common-sense ideas – use em or percent instead of px (altough Mozilla is a very good fellow and knows how to increase em, px, % and also images), use big text on buttons, appropriate contrast colours,  no animated gifs/blinking/flickering elements, align text on the left side,  don’t use “click here” links cause they ALL are click here…
8. write accessible tables : use th scope=”row” and “column”, id and header atributes to associate data cells with header cells,  use summary and caption to give extra clues about the content of the table (altough usually tables are preceded by headings and short paragraphs of text). Use tables to display data only.
9. provide a search function  – altough I build small brochure sites and I don’t embed search in them.  Do you? For small sites?
10. provide buttons to increase font size.  Sometimes  I do, sometimes I don’t, depending on what clients ask. I believe that people who have special needs know the CTRL + combination and use it, the A-, A+ buttons seem to me like a bit redundant.  Maybe I’m wrong… Also I do not provide a button to increase the line-height and other white spaces, I set the line-height in CSS to be bigger that the default. Is it good, is it bad? You tell me, I’m keen to know.

Beside these rules there are lots more, some that make sense and are used, some that I don’t remember here. I’m having a short list of elements that I don’t use mainly because I do not have contact with them and I forget (or want to forget that)  they exist.  I’m still learning about more sensible elements for the  people in need so maybe I’m ignoring some details.

So, the next accessibility rules are not my favourites:

1. use altkeys for navigation – a lot of people still argue about it, I’m waiting to see who wins
2. use title for frames – it shoud say “avoid frames”, but for who’s using them….use titles
3. target=”_blank” issue – there is still a lot of arguing about forcing the user to an action that he/she does not want. It’s common-sense too, but for the coders not respecting the above rules this is too …. in-depth. For me, it’s like somebody adding sugar in my coffee when I mentioned that I like it black. What if I have diabetes?
4. use the focus indicator – I recognize I don’t bother too much to style it, altough I do tab sometimes through navigation links or form elements.

That’s it for now, these are some basic rules I have in mind when I code.  I do try to visualize the site with the CSS/images disabled but I am aware that this is not enough. The simple fact that I’m trying to improve my knowledge is my excuse. But I know it’s not enough and if you have similar sets of rules that guide you please share them here – to guide everyone who is trying to learn something useful.

Ohhh, I forgot: use image replacement techniques, it’s a great invention

Check the Spanish version of this post:
Accesibilidad con sentido común 2.0

No related posts.