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

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sun, 9 Jun 2013 22:34:45 +0200
To: "Jukka K. Korpela" <jukka.k.korpela@kolumbus.fi>
Cc: HTMLWG WG <public-html@w3.org>
Message-ID: <20130609223445744848.91135baa@xn--mlform-iua.no>
Jukka K. Korpela, Sun, 09 Jun 2013 20:16:41 +0300:
> 2013-06-09 19:42, Leif Halvard Silli wrote:

>>   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>
> 
> If you use a heading element after a heading element of higher level 
> in order to provide a ‘subheading’, then you are in a trouble with 
> some software.

If it does’t support <hn>-in-<hgroup>, then yes.

> But I would say that then you just need to stop doing 
> so. The hgroup element is supposed to solve a problem that need not 
> be created.

Well, the hgroup approach has its advantages.

> And if the problem is created, then you can just as well 
> use a div element and the role attributes as above to deal with some 
> specific problems.

You mean:

<div role=heading aria-level=1>
    <h1 role=presentation>HTML</h1>
    <h2 role=presentation>Living Standard — Last Updated 8 June 
2013</h2>
</div>

But this would not solve the outline problem - it only introduces a 
discrepancy between the outline and the actual markup.

> Most people don’t really care much about accessibility, […]

Not sure of the relevance of this comment. But not needing to use ARIA 
should thus be an advantage. Thus <hgroup> has an advantage over <div 
role=heading>

>> Also, while the working group has a formal decision to remove hgroup
>> from HTML5.0, there is no such formal decision w.r.t. HTML5.1. But this
>> is also why I think that we eventually need to come up with something
>> better, or else authors will just go for the WHATWg spec in this case.
> 
> I don’t think most authors care about such issues at all. If they 
> decide to use hgroup, they can do it of course. They can even use 
> <magicSemanticElement> if they like, with identical results: modern 
> browsers let you style such elements, and old versions of IE can be 
> handled using the createElement trick.

Slightly off: For IE8, there is an xmlns trick that achieves the same, 
without JS.

> The only difference is that 
> magicSemanticElement has no default ARIA role, but so what? You 
> shouldn’t count on any default role for hgroup either.

As noted above regarding <div role="heading">, the default role isn’t 
the only difference.

> […] I would say that the outline 
> algorithm is then among the irrelevant and theoretical problems 
> rather than a real concern.

Implementing the outline algorithm should be quite useful.

>> Also, for users, a hgroup is supposed to be
>> perceived as a single header, rather than as several. Visually, one
>> ‘naturally’ groups adjacent headings into a single, subdivided heading.
>> But e.g. a screenreader will probably precent them as different
>> headings.
> Again, this is a consequence of using two heading elements. It’s 
> illogical, but it has no catastrophic impact in most browsing 
> situations. If you wish to avoid all the negative consequences, just 
> use heading elements consistently. There is no problem in having a 
> heading element treated as one heading even though it contains inner 
> markup e.g. to make some parts appear in smaller font, or to be 
> styled otherwise in a special way.

Some tools, consumers and authors rely on default HTML styling - for 
example WYSIWYG HTML editors and screen readers. Or, sometimes an 
author wants to remove all styling and start from scratch. In that 
case, unless there is dedicated markup for subheadings, one is a little 
bit lost.
-- 
leif halvard silli
Received on Sunday, 9 June 2013 20:35:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:38 UTC