ARIA Tabs

Last week I spent my Friday afternoon trying to get my head around how to apply ARIA properly to a tabbed interface. I even got so far as to map it out on my whiteboard and snap a photo so I could mull it over during the weekend.

And then the very next day Marco Zehe, responsible for accessibility quality assurance at Firefox, posted Advanced ARIA tip #1: Tabs in web apps and suddenly my weekend of snow shoveling turned into fiddling.

Marco's post included sample HTML for tabs and an outline of how the script to control it should function, but did not include the necessary styles or script to make it behave as tabs. Since I was marking up a tab list anyway to incorporate ARIA, I'm sharing my code here for others to try, enhance, and so on. It's also on CodePen, so you can fork it and fiddle there.

The HTML

My code has minor differences from the example. For instance, I add a return false; at the end of the event handler. I also call the function that activates the first tab at the bottom of the page, so all tabs start as un-selected and no tab panels are visible until that function fires. You can just as easily put the logic into your HTML and CSS to have one pre-selected and skip that function call altogether.

<ul class="tabList" id="tabs" role="tablist">
  <li role="presentation"><a id="tab1" href="#panel1" onclick="showTab(1);return false;" role="tab" aria-controls="panel1" aria-selected="false">Tab 1</a></li>
  <li role="presentation"><a id="tab2" href="#panel2" onclick="showTab(2);return false;" role="tab" aria-controls="panel2" aria-selected="false">Tab 2</a></li>
  <li role="presentation"><a id="tab3" href="#panel3" onclick="showTab(3);return false;" role="tab" aria-controls="panel3" aria-selected="false">Tab 3</a></li>
</ul>

<div class="tabPanels">
  <div id="panel1" role="tabpanel" aria-labelledby="tab1">
  <p>
    Nulla tincidunt pharetra tortor. In dapibus ultricies arcu. Suspendisse at purus eu est tincidunt feugiat. Praesent et sapien. Vivamus fermentum, diam vel ornare vestibulum, nibh massa imperdiet lectus, eget tincidunt urna urna nec erat. Curabitur interdum. Nam lorem nunc, posuere quis, suscipit eu, hendrerit vitae, nisi. Etiam hendrerit tincidunt felis.
  </p>
  </div>

  <div id="panel2" role="tabpanel" aria-labelledby="tab2">
  <p>
    Vestibulum id eros eu lorem tincidunt sollicitudin. Suspendisse ligula. Sed nisi magna, elementum at, ultricies in, tincidunt imperdiet, quam. Nulla semper. Suspendisse potenti. Sed sollicitudin dolor aliquet purus. Aliquam dui. Proin arcu metus, porttitor eget, pulvinar nec, molestie dapibus, ligula.
  </p>
  </div>

  <div id="panel3" role="tabpanel" aria-labelledby="tab3">
    <p>
      Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Aliquam vel erat. Vestibulum egestas purus ut felis. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
    </p>
  </div>
</div>

<script>
  showTab(1);
</script>

The CSS

This CSS presumes you've already set your typefaces, your page background, and everything works as you want. I have put the minimum styles to make it visually look like tabs. You may notice that I use two different selectors for both a selected tab and for a hidden tab panel. One is by a class name, the other is by the value of the appropriate aria- attribute. Use the first for broader (older) browser support and the latter if you don't care. If you do target just current browsers, then you may adjust the script below to skip writing classes.

.tabList {
  list-style-type: none;
  padding: 0;
  margin: 0 auto;
}

.tabList a {
  display: block;
  float: left;
  border: .1em solid #000;
  padding: .25em 2em;
  margin: 0 0 -1px .25em;
  border-radius: .5em .5em 0 0;
  background-color: #aaa;
}

.tabList a:link, .tabList a:visited, .tabList a:hover, .tabList a:focus, .tabList a:active {
  text-decoration: none;
  color: #000;
}

.tabList a:hover, .tabList a:focus {
  background-color: #ccc;
}

.tabList a.selected {
  background-color: #fff;
  border-bottom: 1px solid #fff;
}

.tabPanels div {
  clear: left;
  margin: 0 auto;
  padding: 1em 2em;
  border: 1px solid #000;
  border-radius: .25em;
  background-color: #fff;
  display: none;
}

.tabPanels div.selected, div[aria-hidden=false] {
  display: block;
}

.hide, div[aria-hidden=true] {
  display: none;
}

The Script

The following script toggles classes for the tabs and the tab panels, as well as adjusting the aria-selected and aria-hidden attributes. There is no keyboard functionality in it at all, but I am always willing to take some from a kind donor. As I noted above, if you use solely the aria- attribute as a CSS selector, you can drop the part that changes the class for each element.

var OpenTab;

function showTab(num) {
  try{
      if(OpenTab!=undefined){
        var OldTabID = document.getElementById('tab'+OpenTab);
        var OldPanelID = document.getElementById('panel'+OpenTab);
        OldTabID.className = '';
        OldPanelID.className = 'hide';
        OldTabID.setAttribute('aria-selected', false);
        OldPanelID.setAttribute('aria-hidden', true);
      }
      var TabID = document.getElementById('tab'+num);
      var PanelID = document.getElementById('panel'+num);
      TabID.className = 'selected';
      PanelID.className = 'selected';
      TabID.setAttribute('aria-selected', true);
      PanelID.setAttribute('aria-hidden', false);
      OpenTab = num;
  }catch(e){}
}

An Example

The following is an embedded version of the tabs on CodePen. Because of how CodePen works, you'll see a few minor differences in styles, but this is at least a functional example which you can fork and tweak.

For example, on CodePen, the function to enable the first tab must be called in the block of script itself, but I prefer to call it at the bottom of the page.

For reasons I cannot figure out, the tabs on the embedded version of this Pen do not work. Visit the tabs directly on CodePen to see them in action.

Check out this Pen!

Wrap-up

That's it, pretty simple. If you have suggestions, corrections, or are a regular AT user and can offer further insight, please feel free to share in the comments or tweet me on the Twitters.

Update, August 6, 2012

Marco Zehe, the guy who wrote the article Advanced ARIA tip #1: Tabs in web apps (which I link above) offered some adjustments to make to my sample code. In essence, dump the aria-hidden from the HTML and use the CSS style visibility: hidden; in its place. His explanation:

@aardrian That would definitely be preferred over aria-hidden, since aria-hidden is not supported by all screen readers.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian Especially older versions of JAWS, which you'll still find a lot, will ignore it.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

@aardrian So use visibility: hidden; in addition to display: none;, and you should be good. Leave aria-hidden out completely.

— Marco Zehe (@MarcoInEnglish) August 2, 2013

Read More

Page-Level Container Discussion for HTML5

As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.

Are We Talking about a Content Element?

Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an article, a section, or even just a div.

Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:

The element that contains "a website or a blog entry's main content" is
body, as far as I can tell.

It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.

But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.

Why Should We Get a Content Element?

One argument is that developers are already coding a solution to this, often by specifying a div with an ID of "main" or "content." In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it's already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put role="main" into the div or other element that wraps their page.

The argument in favor of a content / main / maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.

Why Shouldn't We Get a Content Element?

The flip side of this argument is that we're just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.

Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn't restricted to one instance per page.

What Might This Content Element Look Like?

Steve Faulkner proposed a new element, maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of "main" and "content" that already exist in the wild when naming this element.

Where it goes from here is anybody's guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn't expect to see a new element by then.

Related

• Scooby Doo and the proposed HTML5 content element by Bruce Lawson.


• The discussion on the W3C HTML WG mailing list, September 2012.


• The discussion on the WHATWG mailing list, September 2012.


• HTML5 Accessibility Chops: ‘real world’ ARIA landmark use from The Paciello Group.


• New structural elements in HTML5 at Opera


• maincontent element, Unofficial Draft 9 September 2012 (not a W3C draft).

Update, November 28, 2012

The main element was approved by the W3C as a First Public Working Draft, but within the first 48 hours of life has run into significant blocks. Read my write up: New main Element Approved then Blocked.

Read More

Alt Text on the Picture Element?

This is one of those posts that might interest only a few people and even then only if you are interested in a very specific aspect of this ongoing standard development.

Yesterday I got into a conversation (just one of the messages) on the W3C Responsive Image Community Group mailing list about the alt attribute on the new picture element (see the W3C Editor's Draft). For those who don't know, this community group has been working on producing a method in HTML to allow web developers to specify multiple sources for an image in the same way that we use media queries to specify a particular set of CSS styles to apply to a page.

The discussion was focused on accessibility for the picture element. One suggestion was to use an ARIA role on the picture element to point back to the fallback img. The other suggestion was to just replicate the fallback img's alt text in an alt attribute on the picture itself.

In the end, Mathew Marquis, who is the group chair, proposed these two options:

1. Duplicating the alt attribute on both the picture element and its fallback img;


2. Only specify alt on the fallback img, using aria-labelledby on its parent picture to reference the ID of the fallback img.

Here's the problem—only three people from the community group have responded so far, me being one of them. More responses are needed on issues like this. The broad strokes are in place, but the details are what can kill a specification (or a project, or a patient, or a credit rating). If you are a part of the W3C Responsive Image Community Group (and are reading this and care about these issues) then now would be a good time to pop your head up so others can hear.

In case you are curious, here is my take (which a year from now I may find was an awful idea)…

I think alt on the fallback img should be required and explicitly spelled out as such.

To build on that, I feel that it will be easier for authors and toolmakers to just require the alt on the fallback img, but not on picture. Let picture rely on the fallback img's alt as a single place for fallback content (essentially dump alt from picture altogether).

Then there is no need to worry about duplicating alt to picture and we can lean on existing alt rules, expectations, and even tool implementations even as this new element gets traction.

The two other respondents have far more practical experience with the specifications and accessibility in general, so you should read what Laura Carlson and Bruce Lawson have to say on this. Steve Faulkner has also weighed in, indirectly, on the HTML Working Group mailing list.

And then you can weigh in with your own thoughts. I'd like to see a responsive image solution, whether this one that is proposed or another. Only pushing for something, either way, will make that happen.

Bear in mind, even if this spec doesn't make it and another solution comes forward (server-side or even image-format-based), these conversations help inform other options. This ultimately helps end users, so it's a good idea to get involved. Bruce Lawson helps put a little context around this whole discussion in a post from yesterday, On the publication of Editor’s draft of the picture element.

Almost Related

• Image alt Attributes Not Always Required in HTML5, April 19, 2011.


• More on Image alt Requirement in HTML5, May 2, 2011.


• Image alt Exception Change Re-Re-Requested, June 11, 2012.

Read More

Struggling with Semantics

Now that HTML5 is starting to crack the mainstream, misunderstood and misrepresented though it may be , it makes sense that more and more developers and contributors should start to struggle with the shifting assignment of semantic meaning to the HTML5 elements. I wrote about this on Halloween in my post HTML5 kills [time], Resurrects [u], where I struggle with the changes elements have gone through from HTML4 to HTML5, and even during the course of the development of HTML5.

It makes sense, then, that given all this flux people might start to grapple with each others' definitions of semantics in the context of HTML5 elements. This week has seen a lot of activity around that topic, kicked off by the article Our Pointless Pursuit Of Semantic Value by Divya Manian. Regardless of the title, it's an interesting opinion piece about the process of choosing an element when coding a page. She hits on four main points in the post:

1. The web no longer consists of structured content;


2. Is it really accessible?


3. Is it really searchable?


4. Is it really portable?

The article itself is a good read, but the comments after the article include a lot of well-thought responses, some of which were reformulated and written up as separate responses of their own. Many felt the article itself was too aggressive and made over-generalizations, even to the point that the Smashing Magazine editor-in-chief wrote that the article should have been edited better. I disagree. The tone of the post is what kicked off the maelstrom of debate that has been lacking for some time now on the value of struggling with semantics in HTML5.

Jeremy Keith wrote a response on the same site, Pursuing Semantic Value, where he points out that there truly is a semantic difference between elements:

[...] a div conveys no meaning about the contained content whereas a section element is specifically for enclosing thematically-related content [...]

I disagree with his example of how you can see the difference in some browsers, since it is based on an arbitrary style decision made by a browser vendor and inserted into the default browser stylesheets:

You'll notice that the same element (h1) will have different styling depending on whether it is within a div or within a section element [...] So that's one illustration of the practical difference between div and section.

Regardless, his points clear and a good read for anyone who is struggling with choosing the right element and who might find him/herself giving up too easily and falling into the dark trap of div-itis.

Steve Faulkner weighs in with a comment on the original article that he then converted to a post on his own site, HTML5 semantics and accessibility. He opens up by, as he says, stating the obvious:

Semantics are not just about accessibility, accessibility is not just about assistive technology. But semantic information (name, role, states and properties) carried by HTML elements and attributes is integral to making content on the web accessible, especially for those who rely upon assistive technology to access and interact with web content.

He goes on to cover hgroup, header, hgroup, figure, figcaption, longdesc (the attribute) and even the HTML5 outlining algorithm and reminds us that the browsers have the burden of making these all function as accessible elements, driven by the developer community.

Paul Irish responded to Jeremy Keith's response in his post Semantics in practice and mapping semantic value to its consumers. He distills the struggle between and with accessibility and semantics pretty well, in my opinion, with this statement:

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 youre listening to the results in a screenreader.)

John Foliot jumped onto the response bandwagon with his aptly titled post, My Thing About the Thing That Thing Wrote About Thing. His response is much more aggressive on the accessibility side and is far too difficult for me to distill with one takeaway quote. You need to really read through his post to understand everything. He was, however, nice enough to provide a tl;dr version:

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.

In case you are wondering what that opening image is from, I stole it from CSSquirrel and its post The Value of Meaning. Consider that snippet from the comic to be my selection of a quote from the article.

Recap

Recent changes and chaos in HTML5 are frustrating developers who already struggle with the proper application of these new elements. One article exclaiming this frustration has started a much needed (even if it seems like common sense to many of us) discussion of how we as web developers need to approach choosing the right element for the job. If you are working in HTML5, it behooves you to read these articles and posts, and especially to read through the comments — here are gems of ideas and a treasure trove of links to help educate yourself. Take advantage of them.

Update: November 18, 2011

On some level I think Smashing Magazine has become ground zero for this debate. Bruce Lawson has a new article today on the site, HTML5 Semantics. This article goes into a good deal of depth on semantics and is worth a read.

Read More