W3C home > Mailing lists > Public > public-aria@w3.org > August 2017

Re: ARIA and HTML document question about implicit headings

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Sat, 19 Aug 2017 09:14:46 +0100
Message-ID: <CA+ri+VmCbW+4D_HHXFBLJ8oUwbSyU4mW3Nw3aE0H3=k306B2MA@mail.gmail.com>
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: Matt King <a11ythinker@gmail.com>, Rich Schwerdtfeger <richschwer@gmail.com>, ARIA Working Group <public-aria@w3.org>
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/>
>
>
Received on Saturday, 19 August 2017 08:15:50 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 19 August 2017 08:15:51 UTC