Semantics in practice and mapping semantic value to its consumers
Divya Manian kicked off a good bout of discussion of HTML semantics with her post Our pointless pursuit of semantic value. It called into question the amount of time we spend on identifying the Right and Best ways of marking up our content while highlighting details of some of the consumers of semantics like assistive technology (AT). Jeremy Keith responded in Pursing Semantic Value. I wanted to chime in on Jeremy's post so, I've published below my comment from the original post:
Thanks Jeremy for raising a practical example. This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer), but then parts have underdeveloped semantic meaning or add confusion to authors.
Jeremy’s gist is a great example, in fact, of a poor time investment in semantics. It ascribes value to the new method of document outlining, which recently sees different styling for h1’s depending on section nesting. Recent browsers do indeed style the h1’s different; but if you actually structure your document as such, you do it to the detriment of your screenreader users: they will either get these h1’s all as top level headlines or a mishmash of heading nesting levels that don’t match any expected behavior (As an aside, this is completely unrelated but if anyone’s curious what CSS it takes to make that new h1 styling work across browsers… feast your eyes on this beauty)
Additionally, <hgroup> is on the chopping block and is not supported by JAWS. Suffice it to say, Now is not a smart time to invest your time understanding the unwieldy document outlining algorithm. Luke’s comment digs in deeper to the messy semantic state of the outlining algorithm.
The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn’t complete unless you’re listening to the results in a screenreader.)
My recommendation: follow the work of Steve Faulkner and Jason Kiss. These two guys are publishing the only data that illuminates what’s actually happening at the AT level in response to our work. Steve’s comment on this post does a solid job of unraveling this complex topic by showing all the many layers involved: specs, editors, authoring experience, aria, browser impl, screenreader compliance.
Also if you’d like to investigate what’s happening under the covers, I recommend:
- HTML to Platform Accessibility APIs Implementation Guide – Understand how HTML elements and attributes map to accessibility APIs
- HTML5, ARIA Roles, and Screen Readers in March 2011 – Implementation of HTML5 elements in screenreaders isn’t perfect yet.
- HTML5 and the myth of WAI-ARIA redundance – Will HTML5 make the use of WAI-ARIA in HTML redundant? Definitely not.
- JAWS Support for ARIA – Originally published by Freedom Scientific as a MS Word document. *facepalm*
- html5accessibility.com – Also from Steve Faulkner; this research is hugely comprehensive and backs up the examples Divya provided
- delicious.com/paul.irish/aria – My own bookmarks on semantics, aria and accessibility.
In summary, I think it’s best to ground our efforts in pursuing semantic value by identifying precisely what the results will be. A fair rule of thumb: when it comes to semantics, if it’s confusing enough for you to ask a question about it, chances are the answer won’t make a realistic difference. Let’s build incredible stuff on this impressive platform and avoid getting mired in semantic inconsequentialities. There’s also room for more author engagement and screen-reader involvement in the standards process regarding these issues; but that’s a large topic I’ll have to save for another day.
I agree with most of this post, but I do think one has to be cautious about "if you have to ask a question about it, the answer probably doesn't make a difference." A good example of where that can go wrong is in how many people don't know that there's a semantic difference between having an empty alt attribute for your image, and not having an alt attribute at all, which does affect how screenreader users will read your page. Or how many people don't know how to label their forms correctly. So, in general, it might still be worth investigating that question, even if in some cases the answer turns out to be "that doesn't matter".
Truth,
I think most of this stuff should be taught along the lines of not what is "semantically correct" but rather how it makes a screenreader behave. That's not the only important thing, but it really makes things like the alt attribute really gel in developers heads.
How about fixing screenreaders instead?
While trying to be semantic about your code isn't always the funnest thing to do there is a need to have a solid understanding of what it takes to make your site work for all users. This obviously is less of a necessity when you are dealing with say a personal site, ie. a portfolio site. I work for an agency that deals with healthcare clients and for these types of sites you not only need to know what it takes but also make sure you test your sites. It'a nice to know that I'm not the only one out there that thinks/worries about semantic web.
Today is certain that the education is shared among people by means of our ideas, culture and knowledge always respecting to the other ones
@Rimantas
It's not about 'fixing screen readers'. For interoperable robust accessibility support browsers and developers must play their part as well. Accessibility is a shared responsibility.
While ARIA roles are great, One thing I think should be expanded on is microdata. While I find there are still something that could be improved about it, it's great for adding meaning to contact info, product info, events, or creative works.
Unfortunately all this accessibility and semantic elements are meaningless when you still have 'wysiwyg editors' that spit out 4 to 5 times the code with inline styles, tables, blank images and so on. Mark up like that should be a crime. When I see garbage like that, I truly feel sorry for people using a screen reader.
Thanks for the link to the CSS example of styling headings in the new HTML5 outline. Ye gods, that's horrible. I was just recently wondering how one would go about styling headings if you can no longer create a simple "h2" tag selector, for instance. Seems like if this HTML5 outline algorithm sticks, CSS needs to have some new selectors added to make selecting faux-sub-heads (aka, nested h1 elements) much easier.
BTW, I've got an updated post on videos of screen readers reading ARIA at http://zomigi.com/blog/videos-of-screen-readers-using-aria-updated/. The original post had a bunch of broken links in it, and there was a lot of new stuff I wanted to add, and while I tried to update the original, it soon got messy, and it was easier to just start afresh in a new post.
Thanks Zoe. those videos are excellent.
I've been hearing about semantics for a long time. But, I realized that it's mostly a pile of arbitrariness. On a recent project, I decided to make reusable icons inside of my anchors with an [i] element instead of a span.
According to everything I've read, what should have happened when I horribly violated the intended use of the [i] element is that Jean Claude Van-Damme appeared magically via a portal from the W3C and threw me off a building. Or that developers moaned and wailed and their brains exploded from not being able to understand my redefined semantics of an icon being represented by an [i].
Instead, strangely, none of those things happened and everything is still awesome to this day. …Leading me to believe that we've probably gotten a little too crazy over these elements. I realized that elements could be treated more like variables. Sure, there's conventions, but once you understand the conventions, you should feel okay to throw those out the window if you like.
The discussions about where it's okay to use an HTML5 element are largely dumb if the tag's usage is largely semantic. That is, if [article] has no behavioural difference from [section].
My $0.02.