W3C home > Mailing lists > Public > public-html@w3.org > March 2013

Re: Use cases for <hgroup> ? [WAS] revisiting <hgroup> in HTML

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Wed, 6 Mar 2013 23:17:08 +0000
Message-ID: <CA+ri+Vk7Ur7BMyqCtDRXu9DP9Ta7biSrkN9Vv0yEkEw2wBoWVA@mail.gmail.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Cc: HTMLWG WG <public-html@w3.org>
Hi Leif,

On 6 March 2013 22:06, Leif Halvard Silli

> Steve Faulkner, Wed, 6 Mar 2013 21:16:35 +0000:
> >> And one could
> >> ask, if not the spec allows the above hgroup statement to be presented
> >> as follows, in a screen reader:
> >>    Heading: The reality dysfunction
> >> Subheading: Space is not the only void
> >> Which seems darn close to the effect of your own <subline> proposal,
> >> IMO.
> >
> > no it does not the spec requires that browsers convey hgroup content as i
> > have previously indicated in accessibility APIs
> >
> > "The rank  an hgroup element is the rank of the highest-ranked
> > h1h6 element descendant of the hgroup element,
> > if there are any such elements, or otherwise the same as for an
> > h1 element (the highest rank)."
> >
> > translates into accessibility mapping:
> >
> > "hgroup element heading role, with the aria-level property set to the
> > element's outline depth"
> >
> > The hgroup becomes the heading.
> Agree. And the advantage of the collapse is that the user gets less
> semantic overload. Whereas the problem with that is that the hgroup
> heading could become very long. I assume that you consider that a long
> hgroup heading means that little is gained for the A11Y user, right?
> And that *could* be. But it would depend, perhaps, on how the hgroup
> heading is set up - if all the hn elements of <hgroup> have much
> content, then the hgroup heading becomes very long. Perhaps that can be
> fixed by defining that the user agent can 'jump over' the subheadings
> in some situations?
> Of course, a <subline> would not have that problem. <subline> could
> instead have the problem that heading could become too short. For
> instance, the heading of the WHATwg spec would then be 'HTML', as
> opposed to (note the colon ) currently: 'HTML: Living Standard  Last
> Updated 6 March 2013'.
> >> So what are the use cases for <hgroup>?
> >
> >> To allow a allow a heading to consist of multiple levels without a)
> >> *having* to resort to CSS and/or b) without *having* to say (e.g by
> >> using <p> instead of <h2>) that e.g. the subheading *isnt* part of the
> >> heading.
> >
> > but it doesn't do that it collapses heading semantics
> The example of the spec was, basically, that <h1>Foo</h1><h2>Bar</h2>
> becomes "Foo: Bar". And a screen reader would read that colon aloud. So
> it is not so that it completely collapses things.
> I agree that sometimes there really is only one, logical way to do it -
> one technical solution. But in this case, could it not be possible to
> redefine or 'shape up' the hgroup element so that the user experience
> for e.g. a11y users becomes better and easier to understand? For
> instance simply add that subheadings, when possible, should be
> presented as subheadings rather than as colons or parenthesis? Or,
> advice against hgroups that are too long. And under which situations it
> is logical to not present the subheadings. Etc etc.
> --
> leif halvard silli

But in this case, could it not be possible to
> redefine or 'shape up' the hgroup element so that the user experience
> for e.g. a11y users becomes better and easier to understand?

Yes it would, question being why are we trying to polish a turd?

The suggestions in the spec about adding characters to delineate headings
and sub headings are just that.

there is nothing defined for user agents its not even a should and in
practice why would authors give over the styling/formatting of a heading to

If an author wants a heading/subtitle combo to look like this:

heading: subheading

she can do this

<h1>heading: subheading</h1>

why do this in the hope that it gets outputted as the author desires?


There is no requirement or even suggestion for any user agent to display
the resulting heading is the same way.

What about the meaning or appropriateness of the suggested characters : or
() in differing languages, deo they all mean the same thing in Russian or
Kenji or Mandarin as they do in English, how is the user agent going to
handle differences?

If an author wants heading to be included in the as yet implemented
document outline with a subtitle separated by a : or in () they can do this:

<h1>heading: sub heading</h1>

<h1>heading (sub heading)</h1>

if they don't they can do this:


or this


or this


or any other combination.

with regards

Steve Faulkner
Received on Wednesday, 6 March 2013 23:18:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:32 UTC