Re: aria-level defined on headings (not globally); is it expected that we'd allow it to override implicit level on h1-h6 headings w/o explicit role defined?

I'm leaning toward it being a bug, and I was about to quote the same section as Joseph. 
http://www.w3.org/WAI/PF/aria/complete#host_general_conflict

Because there is no native attribute for level in the HTML, I think the expectation is to allow @aria-level to override here.

  <h1 aria-level="2">Foo</h1> <!-- implicit 1, explicit 2 -->

This also seems to be more useful in the context of section-nested heading levels.

  <section>
    <h1 aria-level="2">Foo</h1> <!-- implicit 1, explicit 2 -->
      <section>
        <h1 aria-level="3">Bar</h1> <!-- implicit 2, explicit 3 -->
      </section>
  </section>

Arguably, the explicitly attribute declaration of role="heading" is merely informative on an element that already has that as its implicit native role semantic.

IOW, these two are identical:

  <h1>Foo</h1>
  <h1 role="heading">Foo</h1>

So why shouldn't these be identical?

  <h1 aria-level="2">Foo</h1>
  <h1 aria-level="2" role="heading">Foo</h1>

James


On Jan 11, 2013, at 12:41 PM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:

> FF overrides.  It exposes a level of three for your example, (and a role of HEADING):
>> 	<h1 aria-level="3">Foo</h1>
> 
> The same info is given for an h3 -- it's a HEADING with a level of three, e.g.,
> 
>    <h3>Foo</h3>
> 
> Specifics:  in both IA2 and AT-SPI, the level information is exposed via the object attribute "level".  The above results are consistent with the UAIG states and properties table (http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property_table) -- see the aria-level row.  There is nothing specific about interactions between the heading role and aria-level in the UAIG; in particular, the role mapping table entry for heading says nothing about levels.
> 
> This issue may be covered by the "Conflicts with Host Languages Semantics" section ( http://www.w3.org/WAI/PF/aria/host_languages#host_general_conflict):
> 
>> When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic, it can be problematic if the values become out of sync. For example, the HTML |checked| attribute and the |aria-checked| attribute could have conflicting values. Therefore to prevent providing conflicting states and properties to assistive technologies, host languages will explicitly declare where the use of WAI-ARIA attributes on a host language element conflict with native attributes for that element. When a host language declares a WAI-ARIA attribute <http://www.w3.org/WAI/PF/aria-implementation/#def_attribute> to be in direct semantic conflict with a native attribute for a given element, user agents *MUST* ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic. 
> 
> But I'm not sure this applies to the situation at hand, since the heading level of native <hn> elements is not an attribute.. Also, there is no *role* mapping for each value of n in AAPIs -- there are no roles HEADING1, HEADING2, and so on in AAPIs.  There is only a HEADING role.   Thus, there is no direct conflict between a WAI-ARIA attribute and a native attribute.  Then again, an <h1> with an aria-level="3" is an implicit conflict on the face of it.
> 
> Perhaps this is a factor:  aria-level has no upper bound, whereas, <h6> is as high as the <hn> elements go.  If authors wanted a heading level greater than six, they couldn't use <hn> without an aria-level to modify it.  Of course, they could also use <div role="heading" aria-level="10">.
> 
> *wishing that html headings had been of the form <heading level="x"> from the start*
> 
> -- 
> ;;;;joseph.
> 
> 
> 'A: After all, it isn't rocket science.'
> 'K: Right. It's merely computer science.'
>             - J. D. Klaun -
>

Received on Friday, 11 January 2013 21:19:43 UTC