New accessibility support for HTML5 elements and attributes

In the nightly builds starting November 9th, 2010, there are some HTML5 elements and attributes newly supported by the accessibility APIs. This will be in Firefox 4.0.

Landmark elements mapped to WAI-ARIA landmark roles

We are mapping the following HTML5 landmark elements to accessibles with WAI-ARIA landmark role semantics:

HTML5 element WAI-ARIA role
article main
footer contentinfo
header banner
nav navigation

In a second small patch landing the next few days, we will also map the html:aside element to the “complementary” role. This was a small oversight on our part in the first patch.

Both NVDA and Orca will pick these changes up without any additional action required on their parts. Other screen readers will hopefully implement or pick up the support ASAP so web authors can use these new elements without having to worry about support or lack thereof.

The placeholder attribute

This attribute can be used on form elements to predefine text that disappears as soon as the field gets focus. It#s a visual indication of what is expected in the field. If, and only if, the field has no label otherwise, this placeholder text will be used to generate the AccessibleName, the name the screen reader speaks for the field when it gains focus. If the field has a label provided by the label element or an ARIA construct, the placeholder text will be ignored.

Proper events being generated when required/invalid/disabled states change

For a few weeks now, we have had support for the disabled, required attributes and the invalid state evaluation of patterns. Now, if any of these conditions change, we now generate the proper StateChange events to notify screen readers and other assistive technologies.


23 thoughts on “New accessibility support for HTML5 elements and attributes

  1. Thanks for the article and update Marco.

    You write:

    “in the field. If, and only if, the field has no label otherwise, this placeholder text will be used to generate the AccessibleName, the name the screen reader speaks for the field when it gains focus. If the field has a label provided by the label element or an ARIA construct, the placeholder text will be ignored.”

    I am curious about the decision to ignore the placeholder text. I am wondering if it * might * be more useful to append the placeholder text to the accessiblename in this situation?

  2. Hi Marco, are you taking into account for the footer and header elements do not have default ARIA roles as there use as specified in HTML5 is different from the banner and contentinfo landmarks?

  3. Hi Everett, we discussed this at length. In the end, we decided to go with the spec. The spec says that placeholder should only be used if for some reason another label cannot be provided. If another label is provided, the placeholder text should not be given. This is for web designers, and we simply followed that paradigm.

  4. Hi Steve, yes, we expose them as header and footer accessibles while article and nav are exposed as if they were divs. For simplicity, however, currently the header and footer accessibles get a “banner” and “contentinfo” XML role so screen readers can still find them.

  5. Agreed. Often the placeholder text is poorly thought out (looking at the Javascripted ones out there now) and many times, when there’s a label, super-annoying-redundant. Now with HTML5, I can’t block these things anymore like I can the Javascripted ones.

  6. We followed what was said in the bug originally, and that said article should map to main, document or application. We decided to stick with the most commonly used landmark role, if the author wants to use some of the other two, they have to explicitly override with ARIA. HTML5 does not provide elements for document or application.

  7. It seems a bit odd and not a particularly good precedent that you have decided to implement contrary to the WAI-ARIA and HTML5 specifications. When the use of these roles and elements have been openly discussed and debated for quite a length of time.

  8. This is probably not the right place, but here goes anyway:

    After Steve posted his question in the comment above, I looked up the “article” ARIA role, which was new to me that this now existed, and found it under a heading called “5.3.3. Document Structure” in the current version of the WAI-ARIA spec:

    Looking at this list of Document structure roles, it looks to me like a complete mashup of “we don’t know where these should fit” roles. Let me go through these one by one:

    – Article: Have never heard of it until today, and have not seen any screen reader support it yet. If nothing else, since a page can have more than one articles, this should be a true landmark role.

    – columnheader: What does htis do here? It should belong right there with other table-related roles.

    – definition: Questionable, too, would put it right with equivalents of bulleted or ordered lists. But no strong opinion.

    – directory: Never seen that one used yet.

    – document: Not seen it used myself, but I know we have tests for this, so this probably actually belongs here.

    – group: Also questionable. What kind of group are we talking about? A group equating to a fieldset/legend construct? Or some different kind of group that does not have an HTML equivalent yet?

    – heading: Yeah, probably OK.

    – img: No good idea about it, so OK.

    – list: Same.

    – listitem: Same.

    – math: Yep OK.

    – note: Agreed.

    – presentation: Structure? Hmm looks to me more like a special case that is made to hide some structural things from assistive technologies.

    – region: Whoever’s ever going to use it. 😉 Sounds to me like this could be more of a landmark than a document structure element, but since I haven’t seen a good use case for this one, either, have no strong opinion right now.

    – row: Again, this is strictly something for tables.

    – rowheader: The same.

    – separator: Yeah OK.

    – toolbar: A toolbar is a container for toolbar buttons and possibly other elements, so similarly interactive like radiogroups or groupboxes. Should not be in this particular section, IMO.

    The way I currently understand it, there is no 1:1 mapping to at least some of the very useful WAI-ARIA landmark roles in HTML5. If I go with your opinion, Steve, for example, something as important as “main” is missing. Suggestions/filed bugs welcome. We were just trying to do the best for our users, and I can see it happen very well that the article element will be used to denote “main” sections of a page, if nothing else because there is nothing else to do it with in HTML5.

  9. Hi marco, I agree that what should be done is to do the best for users, but I consider implementing language features as you see fit, without recourse to the objective of standardisation of implementations across browsers and AT, runs counter to what is best for users.

  10. David filed the original bug after a ping on IRC, but I don not know who pinged him. In the bug’s first comment, he posted the current spec map:

    Esp the “article” one looks to me like it can be mapped to several different things. I suggested to go with the most useful in that case, which is, IMHO, “main” more than any of the others. That’s what we went with, assuming that this was a map the groups had agreed upon.

    And if our implementation was what was needed to shake up people to rethink this to come to a better mapping that benefits users more, I’m all for it. 😉

  11. Hi Marco, what your implementation appears to do is to reduce the utility and semantics of landmarks as large content chunk identifiers and maps them in such a way that is already well served by headings (h1-h6).

  12. @Steve,we tried to do the right thing here but I now see where I misread an older spec. My bad. I will fix on the bug report and reach out to the ATVs.

    Glad Marco blogged this and you caught it.

  13. Hi there,
    I love it, finally there is some on who is not only complained about the new CSS3 and HTML5 Stuff which I love by the way, but also focusing on the usability.
    This blog really builds a bridge between technology and accessability.

  14. I’ve a feeling that web dev’s are treating the highest level article differently then nested ones: Meaning root article should likely map to “main, document or application” but sub articles map to article. (I think this follows for header and footer also: top level should relate to document) Also, I’m assuming that the mapped roles will be overridden by explicit declarations?

  15. hello there and thanks for the info — I’ve surely discovered new stuff from your posts. I however ran into some on site difficulties browsing this site. I was curious about if your web hosting service is fine? Not that I am filing a complaint, but poor loading instances times might probably impact your position bing and might hurt your high quality articles on this blog. Anyway I am putting your Feed to my personal feed reader and will look forward to more of your interesting articles..

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.