November 15, 2011
My Thing About the Thing That Thing Wrote About Thing
There is no harm using div elements; you can continue using them instead of section and article. I think we should use the new elements to make your mark-up readable, not for any inherent semantic advantage.
One of the oft-touted gains of using HTML5 is that “accessibility just happens” – we’ve heard this from King Ian the All-knowing, and it’s been echoed numerous times by his many mouthpieces within the WHATWG, of which Mark “I’m checking out y’all” Pilgrim was an especially vocal member. Everyone proudly points to the new landmark elements of “proof” of this assertion (and frankly, it’s one of the few things they have pretty much gotten right). But now someone with the bully-pulpit of being a “web opener for Opera Software” comes along and say that it’s all a waste of time, don’t bother, a <div> is good enough.
This nonsense of course drew quite a bit of criticism. Our buddy CSSquirrel chimed in, which solicited a response from Divya herself. While I was significantly annoyed with her first article at Smashing Magazine, it was her response to Kyle/Squirrel that set me over the edge:
Accessibility is accomplished through the relationships that accessibility APIs create. They can occur with attributes or tags or heuristics. Assuming ‘semantic’ elements lead to accessibility is a pitfall. No screen reader makes the distinction between b or i and neither does it make sense to. An article or a section makes no difference to a sighted reader, so what purpose does it serve creating a ‘feature’ in screen readers to make that distinction?
There are a lot of issues that ARIA solves which has nothing to do with semantics of the elements you use but all to do with interaction of content with the reader. We need more awareness on ARIA and its interaction with HTML5 and not pedantic discussions on what kind of tone you are conveying using a tag to markup content.
I beg your pardon?
Divya is quite confused about web accessibility. I examine everything she says in a detailed, semi-sarcastic, no-holds barred manner. Conclusion: Semantics matter – a lot.
Full Blown Rant version
Let’s examine some of what Divya said here shall we?
Accessibility is accomplished through the relationships that accessibility APIs create. They can occur with attributes or tags or heuristics.
Really? The accessibility APIs don’t create anything, they simply provide a programmatic mapping to a number of key conceptual interactions, namely Roles, States and Properties (gasp! semantics), so that Assistive Technology can interact with those conceptual interactions via alternative methods. The APIs don’t create a thing – that is the responsability of the content author – the APIs simply serve as an abstraction layer so that the semantic of the “thing” can be conveyed to Assitive Technology.
The oldest AAPI out there was created by Microsoft in 1997. MSAA is/was designed to help Assistive Technology (AT) products interact with standard and custom user interface (UI) elements of an application (or the operating system), as well as to access, identify, and manipulate an application’s UI elements.  MSAA communicates information by sending small chunks of information about elements of a program to the assistive technology object (AT). The four critical pieces of information on which the AT relies to help users interact with applications are an element’s role, name, value, and state.  Other AAPIs include:
- User Interface Automation (UIA) (Microsoft – latest generation) 
- IAccessible2 (Linux Foundation) 
- Linux Accessibility Toolkit (ATK) and Assistive Technology – Service Provider Interface (AT-SPI) (gnome.org) 
- Mac OS X Accessibility Protocol (Apple) 
(I realize that it will likely take more than 40 minutes to read all that hard stuff that has nothing to do with more important stuff like CSS gradients and grid-layouts , so I forgive some for not doing so to date)
While it is indeed true that authors can convey accessible semantics (roles, states and properties) via attributes (ARIA), and tags (I will presume you mean elements here, you know, like <article>) I wait with excitement for you to show us an example of “heuristics” magically conveying the real meaning of a text string in markup. Yes, yes, we’ve all heard King Ian the All-knowing spout this poppycock before, especially on the clubhouse IRC channel, but please, can you show us an example? Maybe you can heuristically make something out of this: <div>#$%&^!!</div>
To be clear, Assitive Technology such as screen readers will attempt ‘repairs’ using rudimentary heuristic solutions such as the classic case of what happens when an <img> has no alt text. Tradtionally, the ‘heuristic’ would be to read the file name out loud, in the absence of any other useful information. Other ‘heuristic’ options might include setting a default of reading nothing aloud when @alt is missing, but this doesn’t convey any meaning to the end user, it simply stops bombarding the user with useless or meaningless data (unless you can magically tell us what rt674kp.jpg really means). Content added to a web document – whether a ‘page’ or an ‘app’ – is there for a reason, a reason known to the content creator, who needs to ensure that this meaning (the semantic) is conveyed to all users, not just sighted users. Until such time as machines can truly think, no manner of heuristics will be able to contextually convey semantic meaning – that is a cognitive function that machines cannot accomplish today.
Assuming ‘semantic’ elements lead to accessibility is a pitfall.
Can you actually provide us proof of this statement? Let’s examine those pesky <section> and <article> elements that seem to have you so confused.
<section> roughly maps to ARIA’s role=”group”, which maps to:
- ROLE_SYSTEM_GROUPING (MSAA + UIA Express role)
- ROLE_SYSTEM_GROUPING (MSAA + IAccessible2 role and other IAccessible2 features)
- Group (UIA Control Pattern Type)
- ROLE_PANEL (ATK/AT-SPI role)
- AXGroup – AXRole / AXSubrole / AXRoleDescription
‘group’ (Mac OS X)
<article> maps to ARIA’s (wait for it) role=”article”, which maps to:
- ROLE_SYSTEM_DOCUMENT + STATE_SYSTEM_READONLY (MSAA + UIA Express role)
- ROLE_SYSTEM_DOCUMENT + STATE_SYSTEM_READONLY (MSAA + IAccessible2 role and other IAccessible2 features)
- Expose as text string in AriaRole (UIA Control Pattern Type)
- ROLE_DOCUMENT_FRAME + do not expose STATE_EDITABLE (ATK/AT-SPI role)
- AXGroup – AXDocumentArticle ‘article’ (Mac OS X)
 (ya, I know, more boring, time-consuming reading, sorry)
Seems to me that creating those roles in all of those different Accessibility APIs was done for a reason, right? I mean, why else would companies and organizations like Microsoft and Apple and the Linux foundation even bother? Slow day at the office?
The real problem of course is that currently the browsers aren’t doing a very good job of conveying that mapping to the Accessibility APIs. Nobody is saying this isn’t a problem, but surely it is not an excuse to avoid using robust semantic mark-up?
An article or a section makes no difference to a sighted reader, so what purpose does it serve creating a ‘feature’ in screen readers to make that distinction?
“[ARIA] group (role) – A set of user interface objects which are not intended to be included in a page summary or table of contents by assistive technologies.” 
“[HTML5] section (element) – The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading. 
“[ARIA] article (role) – A section of a page that consists of a composition that forms an independent part of a document, page, or site. An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. “
“[HTML5] article (element) – The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content. “
That didn’t hurt too much did it?
No screen reader makes the distinction between b or i and neither does it make sense to.
You are absolutely correct, which is why many folks would be quite content to see b and i disappear from HTML5. King Ian the All-knowing however instead came up with (wait!) Semantic Meanings  to those presentational elements, in some instances breaking legacy content by conceptually applying meaning where no meaning exists or was intended. (But, like, ya-know, ships names are always italicized, so we need to use the i element there – or something….)
There are a lot of issues that ARIA solves which has nothing to do with semantics of the elements you use but all to do with interaction of content with the reader.
Huh? The way you interact with the content is by understanding what that content both is, and represents. One way we do that is with elements that have been mapped to a conceptual meaning, which is uh, another way of saying semantics.
We need more awareness on ARIA and its interaction with HTML5…
Finally, something sensible.
Yes, we do need more awareness about ARIA (what it does and why it was created), how the problems that ARIA set out to solve have now been partially addressed by some of those new HTML5 elements, and why using them instead of meaningless divs does matter and is important. It’s not a pointless pursuit, it’s a critical goal in moving the ball forward for those users who do not interact visually with what many see as primarily a visual medium of expression.
We also need to have more awareness on the role that the browsers have in exposing semantics to the Accessibility APIs, and as a community that claims that web accessibility is important, we need to continue to apply pressure on those browsers to actually do their part. Part of the point of HTML5 Accessibility is to apply that kind of pressure, by both reporting successes at the browser vendors, but also to report failures.
If we accept that [ARIA] role=”article” or [ARIA] role=”group” is meaningful and useful to non-sighted users (and if they weren’t, why are they mapped in all of the different APIs?), and we further accept that <article> maps to role=”article” and <section> roughly maps to role=”group”, then clearly both pursuing their continued and increased usage is not pointless. That the various browsers aren’t doing a great job handing off this semantic data/markup to the Accessibility APIs is a problem, a real problem, which we all need to work on. One thing that average web developers can do to help move that ball forward is to use those new elements: the more they are used, the more the browsers will get around to actually doing something useful with them. (And if they continue to drag their feet there, well, shame on them).
The last thing we need however is people who have a position of influence over a segment of the web population spreading falsehoods and outright confusion about topics that they’ve not spent time truly getting into. Divya has certainly spent many hours working on and with the latest advances with CSS3, and in that domain she probably knows her stuff. But half-guessing about web accessibility, and spreading mis-information about, and harmful advice with regard to that domain, is something that angers me to no end (ya think?) – this is simply too important to get wrong.
Semantics matter – a lot.
(I tip my hat to friend and fellow accessibility warrior Steve Faulkner for all of the work he has done documenting and explaing how ARIA, the Accessibility APIs, and browsers handle this information today. I have referenced his work in multiple locations in this posting, and if you really want to do the deep-dive on this subject, hang around Steve, ’cause he has it down cold. Props my friend!)
- http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table (Editors’ Draft 31 October 2011)
- http://www.w3.org/TR/wai-aria/roles#group (W3C Candidate Recommendation 18 January 2011)
- http://www.w3.org/TR/html5/sections.html#the-section-element (W3C Working Draft 25 May 2011)
- http://www.w3.org/TR/wai-aria/roles#article (W3C Candidate Recommendation 18 January 2011)
- http://www.w3.org/TR/html5/sections.html#the-article-element (W3C Working Draft 25 May 2011)
- http://www.w3.org/TR/html5/text-level-semantics.html#the-i-element (W3C Working Draft 25 May 2011)
- http://www.w3.org/TR/html5/text-level-semantics.html#the-b-element (W3C Working Draft 25 May 2011)