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

RE: ARIA and HTML document question about implicit headings

From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Date: Wed, 16 Aug 2017 19:44:53 +0000
To: Matt King <a11ythinker@gmail.com>, 'Rich Schwerdtfeger' <richschwer@gmail.com>
CC: 'ARIA Working Group' <public-aria@w3.org>
Message-ID: <BN6PR03MB27852C21694998986F56E79BF2820@BN6PR03MB2785.namprd03.prod.outlook.com>
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
> 
> 
Received on Wednesday, 16 August 2017 19:45:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 August 2017 19:45:23 UTC