- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Sun, 9 Jun 2013 22:09:20 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: "Jukka K. Korpela" <jukka.k.korpela@kolumbus.fi>, porneL <pornel@pornel.net>, HTMLWG WG <public-html@w3.org>
- Message-ID: <CA+ri+VmMOOG_gNvww1Y2D2bc6+im0BY16tzjAwtK-syojojPxg@mail.gmail.com>
Hi leif, >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. in regards to html 5.1 my understanding is that it is the editors that make decisions about what goes in and out, after consulting the group if the issue is contentious, then the working group reviews and provides feedback , files bugs etc. 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. 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. 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 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. 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. [1] http://lists.w3.org/Archives/Public/public-html/2013Apr/0005.html -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 9 June 2013 17:42, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>wrote: > Jukka K. Korpela, Sun, 09 Jun 2013 17:34:36 +0300: > > >> Definitely authors want some markup for subheadings, which is why > >> h1+h2 markup pattern emerged that hgroup t[ri]ed to fix. > > > > It was similarly a wrong move. > > Just a note: Unlike some other participants in this debate, I am not > fundamentally opposed to hgroup. Frankly, I have trouble explaining > what the problem with it is. 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> > > 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. > > > Just because some patterns emerge > > doesn't mean that markup rules need to be changed. On the contrary, > > if authors can do what they want to do by combining HTML elements in > > a certain why, why tell them to do things otherwise (like group > > headings in some containers)? > > The answer (AFAICT) is that such combinations have the effect of being > interpreted by the outline algorithm as representing two sections > rather than one section. 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. > > > If some authors wish to use headings > > with some inner markup instead, why tell them they should switch to > > using some very different pattern? > > For the record: To use <subheading> for that inner markup instead of > the current usage, would not be to switch to "some very different > pattern". Rather it would be to switch to a similar pattern. > -- > leif halvard silli
Received on Sunday, 9 June 2013 21:10:34 UTC