Re: hgroup and ARIA outline in ISSUE-129 [Was: SSUE-129: replace or modify the ARIA section of the HTML5 spec - chnage proposal and replacement spec text]

Hi Benjamin,

looking at this futher I have come to the conclusion that the hgroup element
should not have any default role as its only purpose is in relation to
hiding sub headings from the outline algorithm. When a page is presented to
user a in the browsing context any heading elements the hgroup contains
should be presented with their semantics intact. The semantics of the hgroup
is not relevant in this context.

For the purposes of the outline algorithm the default role mapping to
accessibility APIs appears irrelevant.

thoughts?

regards
Stevef


On 22 November 2010 18:59, Benjamin Hawkes-Lewis <
bhawkeslewis@googlemail.com> wrote:

> On Sun, Nov 21, 2010 at 11:28 PM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
> > change proposal: ARIA in HTML5: replace current text of section 3.2.6
> > - http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5
> > associated specification text:
> > http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html
>
> Under "basis for defining h1 to h6 element that does have an hgroup
> ancestor", the Change Proposal states:
>
> "It is not logical or practical that the semantic information about
> both the heading elements contained within the hgroup and the hgroup
> itself is conveyed to assistive technology."
>
> Why?
>
> The Change Proposal continues:
>
> "In order to provide a heading structure to AT that is more sensible,
> it is proposed that headings inside a hgroup have a default role of
> presentation. This will result in only the one hgroup heading (instead
> of 3) being reported to AT."
>
> This introduces a significant difference between the outline algorithm
> specified by HTML5 and any outline generated using ARIA.
>
> I'm not a colossal fan of how HTML5 repurposes the old hX elements,
> but I think it should at least be consistent between HTML semantics
> and the accessibility tree.
>
> In HTML5 only the first highest ranked heading contributes to the
> "hgroup" text; in this proposal all headings do.
>
> So given:
>
> <hgroup>
>  <h2>Foo</h2>
>  <h1>Bar</h1>
>  <h2>Baz</h2>
>  <h1>Quux</h1>
> </hgroup>
>
> in HTML5 the heading is "Bar" but in the proposal in the accessibility
> tree the heading is "Foo Bar Baz Quux" which subverts author intent.
>
> Applying "role='presentation'" would also block UAs from exposing the
> actual semantics of "subtitle" that lesser-ranked headings possess,
> were any accessibility API to include that semantic, since "For any
> element with a role of presentation and which is not focusable, the
> user agent MUST NOT expose the implicit native semantics of the
> element (the role and its states and properties) to accessibility
> APIs".
>
> http://www.w3.org/WAI/PF/aria/roles#presentation
>
> I think this would be a more accurate reflection of intended semantics:
>
> <hgroup role="heading" aria-level="whatever"
> aria-labelledby="heading-text">
>  <h2>Foo</h2>
>  <h1 id="heading-text">Bar</h1>
>  <h2>Baz</h2>
>  <h1>Quux</h1>
> </hgroup>
>
> Spec text could be along the following lines:
>
> "hgroup element: heading role, with the aria-level set to the
> element's outline depth and the aria-label, and with the first
> highest-ranked heading element providing its accessible name."
>
> "hX element that does have a hgroup ancestor: No role."
>
> This would also "result in only the one hgroup heading … being
> reported to AT" when listing headings, and would allow UAs to
> represent subtitles to supporting accessibility APIs.
>
> --
> Benjamin Hawkes-Lewis
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html