Re: 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?)

Just as a follow-up FYI for the thread completeness, this was resolved in the ARIA meeting on Monday, and the group decided the change was important enough for the 1.0 spec, so I've updated the relevant section in the editor's draft. Here's the updated text.

"""
Global states and properties are supported on any element in the host language. However, authors MUST only use non-global states and properties on elements with a role supporting the state or property; either defined as an explicit WAI-ARIA role, or as defined by the host language semantic matching an appropriate WAI-ARIA role. 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 role supporting the state or property; either defined as an explicit WAI-ARIA role, or as defined by the host language semantic matching an appropriate WAI-ARIA role. For example, the aria-valuetext attribute may be used on a progress element in HTML, without requiring the author to explicitly and redundantly specify the role as progressbar.
"""

http://www.w3.org/WAI/PF/aria/complete#state_property_processing


On Jan 11, 2013, at 2:49 PM, James Craig <jcraig@apple.com> wrote:

> 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 Wednesday, 17 April 2013 08:06:20 UTC