Re: ARIA and HTML document question about implicit headings

Hi all, have updated the spec text to clarify that HTML elements with
implied roles can have ARIA attributes which are allowed for use on the
(implied) ARIA role.

https://github.com/w3c/html-aria/commit/c3531bce503b3f598a33f04dfefb1c1d18487bd4

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>

On 16 August 2017 at 21:15, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> Hi all, am at somewhat of a disadvantage as currently on vacation, so
> doing everything via phone.
>
> If a HTML element has an implied role mapping it does not need to have an
> explicit role that matches the implicit role. In fact to do so is a HTML
> conformance error. In general any aria properties that can be used with an
> aria role can also be used with a native element that has an implicit aria
> role without explicitly declaring the role.
>
> There is an ambiguity with the conformance text around this in the ARIA in
> HTML specification which I will correct when I return.
>
>
> On Wednesday, 16 August 2017, Bryan Garaventa <
> bryan.garaventa@levelaccess.com> wrote:
>
>> I'm not sure where this is to go specifically, but it involves ARIA since
>> there are already native role mappings supported by the browsers, and this
>> is already changing the accessibility tree.
>>
>> So by your logic the following should not work either:
>>
>> <button aria-pressed="true">Test</button>
>>
>> So, if adding a role on a native element is disallowed, such as
>> role="button", how do you turn this into a toggle button?
>>
>> By the way this is already happening in the various browsers, so if you
>> disallow this then all of these implementations will have to be undone. E.G
>> I just verified that this maps to a PushButton with a "PRESSED" state in
>> the latest versions of Firefox, Chrome Canary, and Safari on Ios.
>>
>> So this functionality is either allowed globally, or disallowed globally.
>>
>> I don't personally see why there is any conflict with allowing this
>> because it fits with the implicit role mapping paradigm. If these elements
>> are not meant to act like the roles they represent, why are there any
>> implicit ARIA role mappings at all?
>>
>>
>> Bryan Garaventa
>> Accessibility Fellow
>> Level Access, Inc.
>> Bryan.Garaventa@LevelAccess.com
>> 415.624.2709 (o)
>> www.LevelAccess.com
>>
>> -----Original Message-----
>> From: Matt King [mailto:a11ythinker@gmail.com]
>> Sent: Wednesday, August 16, 2017 10:36 AM
>> To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; 'Rich
>> Schwerdtfeger' <richschwer@gmail.com>
>> Cc: 'ARIA Working Group' <public-aria@w3.org>
>> Subject: RE: ARIA and HTML document question about implicit headings
>>
>> Seems to me like this is not an ARIA issue, but an HTML issue.
>>
>> Per ARIA section 7.5 Conflicts with Host Language Semantics[1]
>>
>> > When WAI-ARIA states and properties correspond to host language
>> > features that have the same implicit WAI-ARIA semantic, it can be
>> > particularly problematic to use the WAI-ARIA feature.
>> > If the WAI-ARIA feature and the host language feature are both
>> > provided
>> but their values are not kept in sync,
>> > user agents and assistive technologies cannot know which value to use.
>> > Therefore, to prevent providing conflicting states and properties to
>> assistive technologies,
>> > host languages must explicitly declare where the use of WAI-ARIA
>> > attributes on each host language element conflicts
>> with native attributes for that element.
>>
>> HTML heading levels have an implied ARIA semantic that can conflict with
>> the aria-level property.
>> Therefore, per the above, HTML MUST explicitly declare where the use of
>> aria-level on heading elements conflicts with native heading level values.
>>
>> Personally, I think allowing authors to override the level of a heading,
>> e.g., <h1 aria-level="3">, creates inconsistency in the processing of ARIA.
>> If the author wants the level reported to AT to be 3, then use an H3 or
>> use a div with role heading and aria-level 3.
>>
>> But, regardless of what ends up being allowed, I don't see how this is an
>> issue for ARIA. It appears to be something that should be resolved in HTML.
>>
>> Matt
>>
>> [1] http://w3c.github.io/aria/aria/aria.html#host_general_conflict
>>
>> -----Original Message-----
>> From: Bryan Garaventa [mailto:bryan.garaventa@levelaccess.com]
>> Sent: Tuesday, August 15, 2017 4:20 PM
>> To: Rich Schwerdtfeger <richschwer@gmail.com>
>> Cc: ARIA Working Group <public-aria@w3.org>
>> Subject: RE: ARIA and HTML document question about implicit headings
>>
>> I'll be happy to submit something for 1.2. Before I do though, this is
>> the logic that makes sense to me.
>>
>> Since there are implicit ARIA roles applied to certain native markup,
>> making it possible to represent the same role in the accessibility tree
>> regardless if a native element is used or its equivalent role on a
>> differing element type, it makes sense that applying supported ARIA
>> attributes to either of these constructs would result in a subsequent
>> update to the accessibility tree accordingly.
>>
>> E.G
>>
>> <img aria-label="Test" > Would result in an image with an accessible name
>> of "Test".
>>
>> <h2 aria-level="3"> Test </h2> would result in a heading role with a
>> level of 3.
>>
>> <button aria-pressed="true"> Test </button> would result in a pressed
>> toggle button.
>>
>> And so on with supporting atributes for these role types.
>>
>> I'm not talking about substituting ARIA attributes for native host
>> semantics like the use of aria-checked instead of checked on a native
>> checkbox or radio button (input+type=checkbox|radio), but rather the
>> updating of native accessibility tree roles with supporting ARIA attributes
>> when there is no equivalent native host semantic available.
>>
>> This would be helpful in many cases, and already occurs for many roles in
>> browsers already.
>>
>> Bryan Garaventa
>> Accessibility Fellow
>> Level Access, Inc.
>> Bryan.Garaventa@LevelAccess.com
>> 415.624.2709 (o)
>> www.LevelAccess.com
>>
>> -----Original Message-----
>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]
>> Sent: Monday, August 14, 2017 6:46 PM
>> To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
>> Cc: ARIA Working Group <public-aria@w3.org>
>> Subject: Re: ARIA and HTML document question about implicit headings
>>
>> This was identified as an issue for ARIA 1.1 in part because we started
>> to move toward role parity with HTML 5. The others issues you now raise
>> were not.
>>
>> If you would like to other things addressed you should put them in ARIA
>> 1.2 issues on github.
>>
>> Rich
>>
>> Sent from my iPhone
>>
>> > On Aug 14, 2017, at 12:49 PM, Bryan Garaventa
>> <bryan.garaventa@levelaccess.com> wrote:
>> >
>> > Hi,
>> > I noticed recently that according to the ARIA and HTML mapping tables,
>> > the
>> use of aria-level is said to not be allowed on H1 through H6 elements,
>> even though these implicitly map to role="heading".
>> >
>> > Since supporting attributes like aria-pressed and aria-haspopup are
>> accepted on other implicit elements like role="button", amongst other
>> implicit role and attribute combinations, why is this one different?
>> >
>> > Bryan Garaventa
>> > Accessibility Fellow
>> > Level Access, Inc.
>> > Bryan.Garaventa@LevelAccess.com
>> > 415.624.2709 (o)
>> > www.LevelAccess.com
>> >
>> >
>>
>>
>>
>>
>
> --
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>
>
>