Re: <subline> becomes <subhead> and other updates

Steve Faulkner, Sun, 9 Jun 2013 22:09:20 +0100:

> In regards to hgroup that is what happened, I emailed the list stating an
> editing plan [1] , and got no negative responses so got on with it. we have
> since then had a 5.1 working draft published without issue.

I interpret to "start with a levelish playing field", as you said in 
that email, to include hgroup as an option, too. Writing an extension 
spec for hgroup would also be possible.

> My view from observing reactions in articles, posts and tweets,and reaching
> out to developers, is that most authors don't give a fig about hgroup or
> any other formally defined method to mark up subheadings and a good
> proportion are glad to see the back of hgroup.

I’m sure some could have characterized their perception with regard to 
authors’ care for a certain link attribute extension for the img 
element the same way.

> E.g. until AT support is ready, what would
>> the trouble bet with do the following?
>> <hgroup role=heading aria-level=1>
>>    <h1 role=presentation>HTML</h1>
>>    <h2 role=presentation>Living Standard — Last Updated 8 June 2013</h2>
>> </hgroup>
> 
> no wanting to rehash the arguments i have made over and over, but
> 
> The mapping you suggest

Right. Its just a suggestion. May be there are better workarounds. And 
if you permit me to do what you permitted yourself - namely to play 
with new roles, then here are better workaroudns! (See below.) But if 
we exclude that option, would it be better to allow role="tab" (as 
WHATWG spec allows for h1-h6 when *not* child of hgroup).

> and required in the whatwg spec removes semantic
> information for AT users only, by turning multiple headings into a single
> heading, there are no semantics conveyed about the 'subheadingness' of part
> of the hgroup content, any distinction has been removed in the role
> information exposed.

Counter arguments:

1) WHATWG spec does not regulate what role child h1-h6 elements of 
hgroup should have.[2]

2) In connection with subline/subhead(ing), you have suggested to 
introduce some kind of "subheading role" for that element.[3] However, 
such a subheading role could come in handy for the children of hgroup 
as well: It could be applied to all element but the element of the 
highest rank. (The element of the highest rank, could then default to 
presentation role, since the highest rank would anyhow be set by 
hgroup.)

3) If subline/subhead needs a new role - a role which could just as 
well be applied to designated children of hgroup, then the only 
advantage subline/subhead has over hgroup would be that the subhead 
element can be placed more freely.

> Like browsers, other user agents must be able to
> choose how they represent the semantic structure of content to users, in
> order to do this the semantics must be exposed in the accessible tree as
> richly and as faithfully as is possible from the DOM. collapsing the
> semantics of multiple headings into a single heading level denies
> accessibility API clients this possibility.

Well, it *is* a single heading. But even so, in VoiceOver, if an 
element of heading role (such as hgroup or h1-h6) contains children 
(even a <span>), then it is considered so important that VoiceOver 
announces their presence.

But, yeah, the WHATWG spec does not suggest any ARIA defined roles for 
children of hgroup. However a comparison of <subhead role="subheading"> 
to <hgroup> in the WHATWG spec is unfair. A fair comparison would allow 
role="subheading" to be applied to the children of <hgroup> as well. In 
that case, there would not, from ARIA’s perspective (that is: if the 
issue has to have an ARIA-based solution), be any lack of a rich and 
faithful a11y tree and thus no justified claim about any denial of API 
clients possibilities.

And without subheading, a <subhead> as child of <h1> would be just as 
devoid of ARIA based A11Y possibilities as a h1 as child of hgroup 
currently is.

[1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

[2] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#table-aria-strong

[3] http://lists.w3.org/Archives/Public/public-html/2013May/0173
-- 
leif halvard silli

Received on Sunday, 9 June 2013 23:21:58 UTC