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 17:37:00 UTC