Archive for the 'ARIA' Category

Why does HTML footer take role=”contentinfo”?

Evangelia Dendramis asked me “why use role=contentinfo instead of role=footer for <footer>?”

role attributes are from the Accessible Rich Internet Applications (WAI-ARIA) spec, and not part of HTML(5), although they’re allowed in pages. They’re developed by different groups, and for different reasons. ARIA is a bridging technlogy for any markup language – HTML4, SVG or HTML5 to “plugin” accessibility information that isn’t part of the host language:

WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page…

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.

contentinfo is defined as an ARIA landmark on a page. It’s primarily there so assistive technology can allow a user to navigate around. The ARIA spec describes contentinfo as

A large perceivable region that contains information about the parent document. Examples of information included in this region of the page are copyrights and links to privacy statements. Within any document or application, the author SHOULD mark no more than one element with the contentinfo role.

This is a good description of a page footer, but HTML5 allows as many <footer> elements as you want:

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

The HTML5 <footer> does give “content info” but does so about its parent, which may be one of many <article>s or <section>s. Another element that gives information about the content it’s in is the <address> element, which may (but doesn’t have to) take an ARIA role of contentinfo.

So there’s not a 1-to-1 correspondence between <footer> and role="contentinfo". This is exactly the same as the correspondence as we see between <header> and role="banner". So it’s probably less confusing that the HTML5 element and the ARIA roles have different names.

It seems that the name <footer> was adopted as it was the most common class name found in a billion web pages analysed in 2005 by Ian Hickson, HTML5 editor. Arguably, contentinfo is a better “semantic” name (after all, information about content doesn’t have to be below the content it refers to, which is what “footer” implies), but “footer” is what people were already using. Anyway, the naming of the new HTML5 elements is done now. There’s no use in bikeshedding once the ship has sailed, as Captain MixedMetaphor says.

The HTML5 spec says that a “footer element that is not a descendant of an article or section element” (that is, the footer for the whole page) has a default implicit ARIA semantic of contentinfo. That is, assistive technologies are supposed to infer that role without the author specifying it. Good; that’s the way it should be.

However, until all do, you give a helping hand by explicitly adding that role on the page-wide footer.

Using the main element

I’ve just changed my site to use the new <main> element. It took about 1 minute to work out what was wrong with my CSS, until I realised that I hadn’t defined main {display:block;} (the CSS spec says that all elements are inline by default, unless over-ridden). I expect that the HTML5 shiv will add this in, but I don’t use the shiv (it was written after I converted the site). If you use the html5shiv on GitHub, the latest version includes support for <main>.

If you use something like <div id=”main”> (or similar, such as <div id=”content”> as I was), simply replace that with <main role=”main”>.

The <main> element is an exact analogue of ARIA’s role="main", and is designed to show screenreaders and assistive technologies exactly where main content begins, so it can be a target for a “skip links” keyboard command, for example. It could also be used for content syndication (Instapaper-ish things); mobile browsers could zoom in on <main> when encountering non-responsive websites.

It should therefore be used once per page. Therefore, the WHATWG spec is wrong when it says “The main element can be used as a container for the dominant contents of another element.” as this suggests that it may be used multiple times. Don’t. Otherwise, the benefits will be lost.

The W3C version of the spec is far more accurate and useful:

The main element represents the main content section of the body of a document or application. The main content section consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application…

Authors must not include more than one main element in a document.

Authors must not include the main element as a child of an article, aside, footer, header or nav element.

The new element is already in Firefox and Chrome nightlies. The beauty of <main> is that it is already supported in modern assistive tech. Most of these understand aria role=main, as browsers map this to an operating system thingummy (technical term). The thingummy is what the assistive technologies interface with. So in FF nightly and webkit, the new <main> element is mapped to the same thingummy – therefore screenreaders and the like can use it straight away.

Nevertheless, I’m still using ARIA role="main" on the new element as belt-and-braces because you’re almost certainly not using Firefox or Chrome nightlies, and there’s no support yet in Opera or Internet Explorer.

Although I was initially opposed to the new element, I’m firmly in favour of using it, once per page, to give extra built-in accessibility to those who need extra help accessing the Web.

And hearty congratulations to Steve Faulkner, The Paciello Group‘s Kylie Minogue of web accessiblity, for his research and perseverance in getting this in the spec and in some browsers.

Developer’s guide to WebAIM screenreader survey

For the last four years, those excellent people at WebAIM have surveyed screenreader users about the kit and setup they use. For some reason, I didn’t see this when it came out in May.

Here’s a brief summary of the results to help web developers who care about accessibility (that is, professional-standard web developers). I urge you to read the full report when you have 30 minutes to spare.

  • The vast majority of screenreader users are on Windows (87%). The runners up are Mac (8.5%) and iOS (3.4%).
  • The free, open-source screenreader NVDA “saw continued increase in usage, up to 13.7% from 2.9% in 2009 and 8.6% in 2010 (a nearly 500% increase in just 2.5 years)”. You can use NVDA to test your sites and maybe send them a donation; it literally is two blind guys in Australia who maintain it.
  • The vast majority of respondents (83%) updated their primary screen reader within the previous year. Users of free screenreaders were unsurprisingly more likely to upgrade than paid screenreader users.
  • Mobile screen reader usage increased 600% in just over 3 years (only 12% reported using a mobile screen reader in January 2009). 58% were on iOS devices, 20% on Nokia, 7.9% on Android.
  • 98.6% of users had JavaScript enabled.
  • Internet Explorer accounts for 67.5% of the browser share among respondents – IE8 was 34%, IE9+ was 29.5%. Firefox was the runner-up at 20%. “No-one uses IE” is the same as saying “We don’t care about disabled customers”.
  • ARIA landmarks (banner, contentinfo, main, navigation etc) were used “whenever they are present” by 24.6%, “often” by 15.8%, “never” by 15.6%. This is one reason for my changing my mind to support a proposed <main> element in HTML5.
  • 60.8% said navigating through page headings was their primary method find information on a lengthy web page. Heading structures are therefore very important. See this blind developer’s short video Importance of HTML Headings for Accessibility for more.
  • The most problematic areas for screenreader users (most frustrating first) are:
    1. The presence of inaccessible Flash content
    2. CAPTCHA – images presenting text used to verify that you are a human user
    3. Ambiguous links. Lose those “read more” and “click here” links, people! This isn’t a new revelation!
    4. Images with missing or improper descriptions (alt text)
    5. Screens or parts of screens that change unexpectedly. (Perhaps judicious use of ARIA Live Regions could alleviate this?)

I want to re-iterate my thanks to Jared Smith and the WebAIM people for collecting, collating and publishing this information.

Scooby Doo and the proposed HTML5 <content> element

Note: Since writing this, I’ve continued vacillating and now support a <main> element. Why I changed my mind about the <main> element.

Trigger warning: contains disagreement about accessibility.

I’ve been vacillating (ooh err, missus) for two weeks from one opinion to the other regarding a proposed (and rejected) <content> element. This weekend, The Mighty Steve Faulkner wrote an unofficial draft of a <maincontent> element.

Dude, where’s my content?

For a while, people have suggested that HTML add a <content> element that wraps main content, because many websites have something like <div id="content"> surrounding the area that authors identify as their main content, which they then use to position and style that central content area.

Fans of WAI-ARIA also like to hang role="main" on that area, to tell assistive technology where the main content of the page starts. I do this too.

The editor of HTML.next, Ian Hickson, rejected a new <content> element:

What would the element _mean_? If it’s just “the main content”, then that is what the element’s contents would mean even without the element, so really it means the element is meaningless. And in that case, <div> is perfect, since that’s what it is: a grouping element with no meaning.

The primary argument against a special element is that it isn’t necessary, because the beginning of “main content” can be identified by a process of elimination that I call the “Scooby Doo algorithm”: you always know that the person behind the ghost mask will be the sinister janitor of the disused theme park, simply because he’s the only person in the episode who isn’t Fred, Daphne, Velma, Shaggy, or Scooby. (Like most Scooby fans, I’m pretending Scrappy never existed.)

Similarly,the first piece of content that’s not in a <header>, <nav>, <aside>, or <footer> is the beginning of the main content, regardless of whether it’s contained in an <article>, or <div>, or whether it is a direct child of the <body> element.

Authors do need to be able to identify their main content, both for styling (in which case <div> seems to be the most appropriate element) and as a target for “skip links”, in which case, the current <a href=”#main”>Skip nav<a> … <div id=”main”> pattern still does the trick.

It’s worth noting that people often code “skip links” believing it’s required by WCAG 2, but if browsers implemented the Scooby Doo algorithm that is explicitly not the case: “It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent.”

Many assistive technology useragents understand the ARIA role=”main”, so skip links should be unnecessary; ATs can hone in on <div id=”main” role=main> by themselves, even without supporting the Scooby Doo algorithm.

This suggests to me that a new element isn’t required. But…

Paving cowpaths, ease for authors

Chaals (ex-Opera, now Yandex) wrote

To turn the question around, if it is more convenient for authors to identify the main content, and not think about the classification of other parts, should we offer that facility as part of the platform? Or does it make sense to say that only the exhaustive identification of all supplementary content is an appropriate way to mark up a page anyway?

Chaals argues that it makes authoring easier – suddenly you get extra accessibility by just adding one <content> element, rather than adding the other elements that the Scooby Doo algorithm can then exclude. People using CMSs, who only control the textarea that gets lumped in as “main content” and can’t touch the surrounding areas can now add an element, without having to ask others to tweak templates.

But then, they can do this already, by surrounding their content with <div role=”main”> and this already works in assistive technologies.

A flawed argument for a new element is that it paves a cowpath, so should be added to the language. It’s certainly the case that <div id=”main”> and <div id=”content”> are very frequently found in pages – they were #2 and #6 in the most-frequently used ID attributes in the 2008 MAMA: What is the Web made of? report.

But not every cowpath needs paving. If it did, we’d also have a <logo> and a <container> element (#4 and #5 respectively), and we’d be recommending tables for layout. If something can be done automatically, without requiring extra authorial work, shouldn’t that be favoured? In the same way that we like HTML5 form types as they’re baked into the browser, shouldn’t the Scooby Doo algorithm be preferable?

Of course, the Scooby Doo algorithm requires the author to use <header>, <footer> <nav> and <aside> — but if (s)he doesn’t want/ isn’t able to author HTML5, ARIA’s role="main" is there precisely as bridging technology.

There’s also the argument that authors expect there to be a <content> element, so its absence violates the Principle of Least Surprise. But I’m not sure that’s a valid argument. Implementing the Scooby Doo algorithm would mean that pages whose author does nothing for accessibility can be made so that their main content area may be programmatically determined. ARIA exists for pages that aren’t in HTML5, or until the Scooby Doo algorithm is widely supported, and analysis shows that most ARIA is correctly used by authors.

Why add an extra complexity, which is more to go wrong and thus potentially harms accessibility?

Also available:

Nesting ARIA roles

A couple of people have asked me recently if it’s possible to nest ARIA roles. The answer: yes.

Not all of them, of course. Think of HTML elements; you can nest <div>s inside <nav>s and <nav>s within <header>s, but you can’t put an <a> inside an <input> or put an <input> inside another <input> – they just wouldn’t make sense.

In ARIA, it’s perfectly fine to have role=article inside role=main (which is completely analogous to an HTML5 <article> inside a <div id=”main”>.

It’s also fine (as far as I know) to have roles like main inside a <table role=”presentation”>. Although the table is presentational only (it’s an old-fashioned layout table), it doesn’t mean that all the contents are presentational – one cell could contain the entire main content of a site and therefore quite legitimately have a role="main".

The rule of thumb I use is: if your nesting feels right, it probably is right.

Note also that the HTML5 validator also validates ARIA. Even if your content isn’t HTML5, it’s still worth running it through the validator.

Note, I’m not an ARIA expert. Please, if I’ve made a mistake, let me know!

JavaScript and screenreaders

For three years Jared Smith and his lovable chums at WebAIM have conducted a survey of screenreader users, analysed the result and posted them. This year’s results are out. Let’s take a moment to give them a round of applause.

There is much to digest, but one figure really caught my attention: only 1.6% of respondents had JavaScript disabled. Turning that round, 98.4% of screenreader users had JavaScript enabled.

Hopefully this will finally bury the WCAG1-era myth that JavaScript is automatically bad for accessibility or that pages that depend on scripting are inaccessible to assistive technologies.

This myth came about from the early days of screenreaders, which took a snapshot of the rendered page into a buffer and, when a user was navigating a page, he was really navigating that snapshot. If a page was changed with script the user wouldn’t know because another snapshot wasn’t triggered. (Even in this model, some JavaScript was fine. If, for example, your page contained lots of document.writes that executed immediately, and wrote HTML to the page, that would be available.)

As the Web made more use of “Ajax”, screenreaders became more sophisticated and now can handle most scripted interactions. This doesn’t mean that JavaScript is always fine to use; just as you can write inaccessible HTML and CSS, it’s possible to script away accessibility. An understanding of WAI ARIA is vital to professional JavaScripters.

(It’s also important to understand that not all accessibility needs are assistive technology needs. Christian Heilmann and Antonia Hyde showed that some scripting can be empowering for people with cognitive problems with their Easy YouTube and Easy Flickr.)

So we know that script doesn’t scare off assistive technologies, and we know from Yahoo! developer Nicholas C. Zakas’ report How many users have JavaScript disabled? that only 1% of visitors to Yahoo! have turned off JavaScript. Does this mean that we can safely forget about those who can’t use JavaScript.

Well, no. But JavaScript-required is not an accessibility problem, it’s a usability problem. As Zakas says

While the percentage of visitors with JavaScript disabled seems like a low number, keep in mind that small percentages of big numbers are also big numbers.

We spend a lot of time making our sites work with old browsers, using JavaScript shivs and polyfills but we don’t talk much about users without JavaScript. The Opera mini browser, for example, is the most-widespread mobile browser out there but, because it renders on a server, interactivity is limited (See Opera Mini: web content authoring guidelines for more information.)

How far can an application that requires Web Sockets, local storage, cross-domain messaging, canvas be expected to degrade gracefully?

HTML5: bolt-on or built-in accessibility?

Parallel with the discussion in the comments to my post HTML5 details element, built-in and bolt-on accessibility, some cleverer minds than mine (Edward O’Connor, John Foliot, Tab Atkins, Jonas Sicking) have been working on a proposal Retain several newly-introduced semantic elements, attributes, and controls to retain structures that some have proposed be scrapped, such as aside, details, figure, meter, progress and the hidden attribute.

It’s a short but must-read if you’re interested in the debates between bolt-on and built-in accessibility in HTML5.

I had no hand in its authoring, but fully support the proposal and arguments. (I tried to add my name to the end of the proposal to demonstrate immoral support, but am so crap I couldn’t even remember my W3C password.)

See also this interesting and impassioned email from John Foliot.

jQuery accessible HTML5 video captioning plugin

Last month, I wrote an article on Accessible HTML5 Video with JavaScripted captions and dreamed that some clever JavaScripters would take it up and improve it, making it more generic so that a developer could mark up a transcript with timestamps, call in a library and -hey presto!- there would be captions.

Those nice chaps at 360innovate have started work on a jQuery plugin called jCaps.

As it’s all open licensed, if anyone fancies participating, it would be jolly. Here’s a wishlist that I’d love to see, and would write if I were not so scripting-challenged:

  1. It would be useful to point to the transcriptions via the aria-describedby attribute on the video element, the values of which point to the id of an element containing the transcript (which could therefore be an article, a div or whatever). You can have multiple values on aria-describedby (like you can with class) so that allows you to point to different translations.

    This allows you to have transcripts anywhere in the source, so greater flexibility for laying out the page.

  2. If there are multiple transcripts for a single video, they need to have a lang attribute, and the script should construct a select element so the user can choose the language they wish to see transcripts in. (The first one offered should be the transcript that matches the lang attribute on the html element; if there isn’t one, the default should be the first in source order.

  3. I’d love to see a sexy (and stylable) skin around the video element that had a YouTube-stylee user interface that houses all the buttons for turning on captions, transcripts and the language picker.

Anyone up for the challenge, and generous enough to release it as a BSD-licensed library/plug-in?

Note that this technique will have a limited shelf-life. The HTML Accessibility Working Group have two specifications that will enable captioning etc to be done natively once the spec is agreed and (of course) implemented.

See my related post: Some accessibility today or full accessibility jam tomorrow?

Meffys, @media, standards.next

Corblimey what a week and no mistake guv. (Sorry, still getting the last Lahndahn molecules out of my system.)

The Meffys

Firstly, on Tuesday, I attended a formal event on behalf of Opera as our Opera Mini mobile web browser was up for Best Mobile Application at the Mobile Entertainment Forum‘s Meffys awards. I’m not really a suit-and-tie business dinner type person, but duty called so I went along in my wedding-and-funeral suit for the onerous task of drinking free mojitos while listening to the host Hardeep Singh Kohli. (Lots of people said they found him too abrasive, but I thought he was a good choice.)

Lo and behold – we won! Feeling very proud and, forgetting my acceptance speech that our PR types had prepared, I clambered onto the stage and made an impromptu thankyou speech which would have the PR team having palpitations were it recorded anywhere, did a quick video interview for a journalist and took the coveted award home back for a couple of relaxed tie-less beers with David Storey and Chris Mills in the hotel bar.

@media

At media was primarily a great gathering of the clans—I thought that the line up was playing it safe (entirely understandable in the current climate). I [particularly enjoyed persuading 30 people away from some poncey overpriced South Bank bistro in favour of a Waterloo greasy spoon where they stayed open especially to serve us snake and pygmy pie with beans and chips and a pint of lager for under a tenner.

The best speech for me was Robin Christopherson’s, in which he discussed ARIA and CAPTCHA as well as phone accessibility. I made an unscheduled appearance on stage as the HTML 5 cowboy during Molly’s presentation and donated the backless faux-leather chaps to Chris Wilson of Microsoft who’s the co-chair of the W3C‘s HTML 5 working group. He said that he would pass them onto Ian Hickson. I hope that they do the rounds of HTML 5 movers-and-shakers.

Standards.next

On Saturday the first standards.next informal emerging tech bootcamp took place. I was delighted how it went, having co-organised it with Henny Swan. We cajoled a stellar line-up of speakers to sit in a friendly (but very hot and sticky) atmosphere and really get under the skin of HTML 5. I humbly thank every one of them.

Me

I over-ran on time without finishing my slides, discussing some myths that are causing unnecessary FUD and doing a basic demo of markup for a blog.

Remy Sharp

Remy demoed the state of play with the new JavaScript APIs. You can check out his HTML 5 JavaScript APIs slides and try his HTML 5 JavaScript demoes, or watch the HTML JavaScript: video of his presentation.

Dean Edwards

For the first half of Dean Edwards’ HTML5.js talk, most people couldn’t grasp the magnitude of what they were seeing. Dean was showing his new JavaScript library that plugs the holes in browsers’ HTML 5 implementations. If a browser does do something natively, ther library does nothing; otherwise it fills that gap—so now you can have Web Forms with all browsers, canvas in IE. As a bonus, it’s all keyboard accessible, everything looks like native UI controls and it even inherits the native Windows themes. I’m looking forward to helping beta test this baby.

Martin Kliehm

Martin showed several demoes of the new canvas element that blew my mind. I’d rather assumed that it was just for wiggly graphics and maybe on-the-fly graphing but Martin showed some combinations of canvas interacting with video (because once everything is in the browser rather than plugins, they can all talk to each other).

There is real potential for new interaction models for people with learning disabilities, older people and kids.

Steve Faulkner

Steve discussed the accessibility issues of the HTML 5 spec and its relationship with ARIA. I came away from Steve and Martins’ talks convinced that the biggest barrier will be the lack of real support for canvas accessibility and commend Steve for fighting this in the Working Group. I shall be standing with him in future.

I want to thank all the speakers who volunteered to share their knowledge, passion and expertise with us, and thanks to all who attended, and interacted with all the speakers to help us firm up our knowledge.

Although there were some problems (heat, pillars in the way), the event went exactly as Henny and I hoped: a relaxed pub (£1.95 a pint of bitter and you can take your own sandwiches in!), short focussed speeches of 30 minutes so speakers don’t feel the need to pad and a genuinely interested crowd who participated rather than passively absorbed the information. This lady is an excellent example:

Stephanie (?) have a riveting time at standards.next

HTML 5 Doctor

I plugged it at @media and standards.next (and forgot to give out the moo cards), and we’ve launched the bare bones of it today – HTML 5 Doctor (named in homage to an early Zeldman feature called “Ask Dr. Web”).

High Standards t-shirts

If you got a freebie High Standards t-shirt from us at standards.next, please post a picture of you wearing it to Flickr and tag it highstandards, because I want to remember how lovely you are.

The accessibility of HTML 5 autofocus

Last week, I published an HTML 5 contact form WordPress plugin that used the HTML autofocus attribute to put the focus into the first form field.

Marc Aplet commented about the accessibility of doing that, for which I am very grateful as it made me think more deeply about it. Thanks to those on twitter who helped me further with my thinking.

Note that potential accessibility problems are not restricted to the HTML 5 use of autofocus; current JavaScript ways of doing it cause the same problems.

I believe that autofocussing into a form is a usability win for most people if the purpose of the page is that form—for example, the Google hompage. So, I wouldn’t autofocus into the search box or comment field on this page because the primary purpose of this page is discussing this article which requires prior reading. Most people are lurkers, not commenters, so it’s against usability to autofocus into the comment form. But a contact form is the primary purpose of a contact page, and it saves users a keystroke to put the caret into the first field—particularly usable for mobile phone users.

However, screenreader users find themselves dumped in the middle of a form, potentially without context (athough it’s always possible to tell the screenreader to repeat the title of the page, and we all give our pages useful titles, don’t we?).

Moreover, many forms have explanatory or introductory information preceeding them. My contact form does, although that’s somewhat flippant. A better example is Salford University’s Online Staff Directory Quick Search Page. The explanatory information is correctly outside the form element, as JAWS and (I think) Windows-Eye ignore any text that’s not inside legend and label elements when they’re in Forms mode.

What we need, then, is a way to associate some explanatory descriptive text that’s outside the form with the form itself (in a similar way that label and input are explicitly associated). Then a screenreader user could be alerted to the presence of this descriptive material by this programmatic association, and optionally choose to have it read out to them.

Enter aria-describedby. The ARIA spec says

An accessible description may be computed by concatenating the text equivalents for nodes pointed to by an aria-describedby attribute on the current node.

So, I recoded the plugin (download it; it’s at your own risk etc) so that the descriptive matter is enclosed in a div id="form-description". The form element has the attribute aria-describedby="form-description" (because the description is for the whole form).

I don’t know if any screenreaders offer a keystroke to query this information yet (it’s over a year since I’ve been near a screenreader), but as the vendors have worked closely with the WAI-ARIA authors I imagine it won’t be long.

I also amended the plugin so that it has a belt-and-braces approach to the form fields that are required. In addition to the HTML 5 required attribute, I’ve added aria-required="true" as this is probably closer to implementation by screenreader vendors.

Because there are already two programmatic methods of indicating that a field is required, I’ve removed the traditional method of including an asterisk in the markup, as it’s possible to style the form fields with CSS—I’ve used a thick black border. (I tried to use attribute selectors to generate the string “required” immediately after the form field, but that gets surrounded by the field border rather than living outside it. The result is minging, even by this site’s low design standards.)