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

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
> h1–h6 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 *isn’t* 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

Received on Wednesday, 6 March 2013 22:07:24 UTC