PFWG-ISSUE-549 (Was: 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?)

Thanks. That seems pretty cut-and-dry that WebKit's behavior is correct then, according to the 1.0 spec. 

However, I think this may need clarification in ARIA 1.1. 

Suggesting changing this:
> User agents MUST ignore non-global states and properties used on an element without a WAI-ARIA role. 

To this:
> User agents MUST ignore non-global states and properties used on an element without an explicit WAI-ARIA role or equivalent implicit host-language role. 


Created PFWG-ISSUE-549.


On Jan 11, 2013, at 1:29 PM, James Nurthen <james.nurthen@oracle.com> wrote:

> Hang on. Doesn't 7.6. State and Property Attribute Processing state
> 
> "Global states and properties are supported on any element in the host language. However, authors MUST use a WAI-ARIA role on an element in order to use non-global states and properties on that element. When a role attribute is added to an element, the semantics and behavior of the element, including support for WAI-ARIA states and properties, are augmented or overridden by the role behavior. User agents MUST ignore non-global states and properties used on an element without a WAI-ARIA role. "
> 
> regards,
> James
> 
> On 1/11/2013 1:19 PM, James Craig wrote:
>> 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*
>>>

Received on Friday, 11 January 2013 22:49:39 UTC