Re: ARIA and HTML document question about implicit headings

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 <javascript:;>]
> Sent: Wednesday, August 16, 2017 10:36 AM
> To: Bryan Garaventa <bryan.garaventa@levelaccess.com <javascript:;>>;
> 'Rich Schwerdtfeger' <richschwer@gmail.com <javascript:;>>
> Cc: 'ARIA Working Group' <public-aria@w3.org <javascript:;>>
> 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
> <javascript:;>]
> Sent: Tuesday, August 15, 2017 4:20 PM
> To: Rich Schwerdtfeger <richschwer@gmail.com <javascript:;>>
> Cc: ARIA Working Group <public-aria@w3.org <javascript:;>>
> 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 <javascript:;>]
> Sent: Monday, August 14, 2017 6:46 PM
> To: Bryan Garaventa <bryan.garaventa@levelaccess.com <javascript:;>>
> Cc: ARIA Working Group <public-aria@w3.org <javascript:;>>
> 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 <javascript:;>> 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/>