gistfile1.txt

<nav>
  <ul role="tablist" class="tab-type"> <!-- we can use the role tablist rather than data-tabs -->
     <li><!-- see note 1 -->
        <a href="#panel1" role="tab" aria-controls="panel1" aria-selected="true">Tab 1< /a><!--see notes 2, 3 and 4 -->
     </li>
     <li><a href="#panel2" role="tab" aria-controls="panel2" aria-selected="false">Tab 2< /a></li><!-- see note 5 -->
   </ul>
</nav>
...
<section id="panel1" role="tabpanel">
   ...
</section>
<section id="panel2" role="tabpanel"><!-- see note 6 -->
  ...
</section>

Note 1: 
role=presentation is not appropriate here. It is defined as "presentation (role): An element whose implicit native role semantics will not be mapped to the accessibility API.

The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, or may be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA." (http://john.foliot.ca/aria-hidden/#pr)

In the example case, they used a broken link with an empty href and an inline onclick event, because they wanted to make pandas said. In our case, it is still a functional anchor link.

Brett makes an alternate case: it's applied to the LI because we do not want the LI to be percieved as a LIST item. For me, jury is out. I'd like to see some more references. 

Note 2:
We can and should use aria-selected instead of .active

Note 3:
role=tab is needed to note the tab within tablist. The question then is whether we feel it would be better on the link or LI. I think link.
http://www.w3.org/TR/wai-aria/roles#tab

Note 4:
We need aria controls (http://www.w3.org/TR/wai-aria/states_and_properties#aria-controls) but it's redundant given the href. Would we want JS to assign these (as well as role=tab), making the markup the dev has to do easier, and less likely to get wrong.

Note 5:
We have to set aria-selected-=false, as if it is not present (undefined) it is interpreted as "not selectable". I definitley think we may want to do this programmatically.
http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected

Note 6: 
For non-active panels, set aria-hidden=True via JS rather than hide. Make sure the attribute is set to display: none (and we'll need to test that.)

There are extra spaces in the closing anchor tags. Also, can you update the second list item formatting to match the first?

Note 1: Of the examples I seen: example 1, example 2, example 3. All use role="presentation" on the list item. I think we should have a good reason not to follow this if we are planning to not use it.

Note 2: Yes, use aria-selected.

Note 3: role="tab" should be on the link. All there examples I've referenced place it on the link element.

Note 4: Agree with add via JS, but if consumers want to add themselves, I think we could allow that. For the JS part, check if the attribute exists before adding. I also think we could have a template helper that builders out the tablist and list items.

Note 5: Agreed.

Note 6: Agreed. Again, I think if consumers want to add themselves, we could allow that.

+1 Overall on the markup.

I think we should test this markup/solution with screen readers to determine if its functioning as we think it should

May also be good to test against the markup of the examples linked to see how it differs.

Brett, I somewhat agree with you on role=presentation (note 1). What I'm looking for at this point is a clearer spec-based explanation of when and why it should be used. The example I found above is clearly ambiguous, and I don't trust examples alone, as I've seen too many bad code examples. I'd like to see us do a smidge more research on the attribute and be sure we're using it correctly.

Sounds like we're in agreement on note 3, so I can consider that resolved unless someone has any argument otherwise.

Initially I was thinking start with very minimal markup, because nearly all attributes can be easily inserted programatically. But on further reflection, I'm leaning towards not doing that work onload and instead simply showing the final markup we want. Consumers can cut and paste it, or build a helper to output. I'm open to additional ideas on this, but one way or another, we need to enforce a lot of this markup or it will not actually be accessible. For example, if aria-selected is not present, it does not default to "false" it defaults "not selectable"

Tim,

The presentation role should be used when the element in question does not need to be accessible. The usage examples w3 gives are spacer images, decorative graphics, or clearing elements. If we don't use presentation, then its possible a screen reader might read "list item" or something akin to it when touching the

tag. This is because

tags have an implicit role of listitem which could be spoken by some screen readers.

I agree that the final markup should be inserted directly instead of being added with JS via onload. In the future, helpers will replace the need to copy/paste markup.

Thanks Henry for looking into the presentation role. This was my gist of why someone would use it.