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

>
> 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.


indeed and anybody is free to do so.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 10 June 2013 00:21, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no>wrote:

> 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