[webkit-dev] Fwd: Adding <main> element to WebCore

[Ian Hickson]

On Wed, 28 Nov 2012, Silvia Pfeiffer wrote:
> On Wed, Nov 28, 2012 at 11:22 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 28 Nov 2012, Silvia Pfeiffer wrote:
> > >
> > > I've not seen any place where @role=main was misused and I think the 
> > > same would be the case for <main>.
> >
> > ARIA is used by very few authors, and those authors are, by and large, 
> > much more competent than average. ARIA therefore tends to be used to a 
> > much higher level of quality than most elements.
> 
> Agreed. I think that having this as an explicit element would make it 
> easier for the Web Developer community at large to become aware of this 
> problem and to provide this very valuable feature to users in need.

Well first of all, what problem? How big of an issue is the accessibility 
problem here anyway? It's not at all clear to me that it's a big issue at 
all. Sites have been quite happily working with a "skip past navigation" 
link, and HTML has an explicit <nav> element that makes this more likely 
to happen even for sites that don't provide a link, and ATs have all kinds 
of page navigation tools for users that let them jump around looking for 
whatever it is they want to read (which isn't necessarily the "main" 
content; e.g. on youtube.com you probably want the search box, not the 
stream, in many cases).

But secondly, how do you think <main> will do anything to make authors 
aware of anything? To authors who hear about the element, it's just going 
to be met with "ah, a way to replace my id="main" element ID with an 
element instead, just like <header> and <nav>".

And thirdly, since when are awareness campaigns appropriate ways to do 
language design? We design to solve real problems, we try to make the 
platform intuitive. We don't design the language to teach people. That's 
the job of tutorials, advocacy, etc.


> > > At least I don't see why it would be misused any more than the other 
> > > semantic elements that were introduced such as <article>, <header> 
> > > and <aside>
> >
> > It would probably be used about as well, maybe a little less well than 
> > them because the idea of what is "main" varies from author to author 
> > (e.g. in the sites you analysed on the WHATWG list, as well as in many 
> > that others have mentioned before, id="main" and id="content" often 
> > include things like some navigation, some headers, some sidebars, some 
> > footers).
> 
> Agreed. The analysis in my article came to the same conclusion.

This is the opposite conclusion than you drew in your earlier e-mail, so 
I'm confused now. (You said "I don't see why it would be misused any more 
than the other semantic elements".)

Note that if it's misused even as much as the other semantic elements, 
that's enough to make it useless, unlike with those other elements. That's 
an important distinction.

It's like labels on foods. If many stores misuse a label that says where 
the food is stored in their warehouse, well, those stores have trouble 
using their warehouse, but it doesn't really affect other stores, and the 
stores that use it correctly have no trouble. On the other hand, a label 
that says "Only Organic Ingredients!", if use incorrectly by many stores, 
stops being useful at all, because even in stores that use it correctly, 
shoppers won't know if it's right, and so won't trust it. The label loses 
all its value. It actually doesn't even take a big fraction of stores to 
misuse the label for consumer trust in the label to be fatally undermined.


> I think we need to let go of the idea that <main> will replace id="main" 
> and id="content", because it's not the point of <main>.

That's how authors will use it. That it's not the point of <main> is 
*exactly* the reason <main> is a bad design.


> > The use case for <main> is accessibility navigation. If authors use it 
> > incorrectly, the feature *doesn't work*. The element becomes 
> > pointless.
> 
> That's a good thing, right?

No, it's a terrible thing. It essentially means we shouldn't add the 
element.


> Because then Web developers have a means to find out that they've made 
> the wrong markup.

Uh, no? It doesn't teach authors anything at all. Authors have basically 
no way to find out if they've used it correctly (given that they're not 
going to use -- or in most cases, even know about -- ATs).


> > Combined with the way that the concept of "main" varies from author to 
> > author, you dramatically increase the likelihood that the element 
> > won't satisfy its stated purpose.
> 
> If it is clearly specified, why would there be a difference in 
> understanding what "main" means?

You seem to be under the assumption that authors read the spec. The number 
of authors who read the spec is absolutely insignificant compared to the 
number of authors who will use the element.


> > Also, since few authors ever test how their page works in ATs, they 
> > won't know that there's a problem.
> 
> Right, that's why introducing a keyboard shortcut for <main> would be 
> useful: it would enable every user to test their page.

Very few authors are going to do that. (Barely anyone tests how their page 
prints out, but that's easy to do with "print to PDF". Barely anyone 
checks how their site works without JS, but that's easy to do. Barely 
anyone tests their page in a keyboard-only mode, but that's easy too. 
Barely anyone validates their pages, even though that's trivial. Barely 
anyone checks the JS console for errors, even that's been available in 
browsers for years.)


> Ultimately, we always have the accessibility users as the testers for 
> this feature and they can register bugs where the <main> element is 
> leading to the wrong place.

How well did that work for longdesc=""? Heck, how well did it work for 
alt=""? Accessibility users complaining doesn't lead to sites getting 
fixed.


> After all, there are more deaf and hard-of-hearing users in the US than 
> there are Web users in Spain or Canada [1], so that should provide a 
> large enough audience to make this work.

It worries me that you would say that, since deaf and hard-of-hearing 
users aren't even remotely helped by this feature. Those it would 
theoretically help are users of screen readers (eg. the blind).


In conclusion:

A. Authors don't test their pages in a way that would detect this feature.

B. Authors won't understand this feature.

C. If this feature is misused to any significant extent by a subset of 
authors, then the purpose of the feature is lost for all users on all 
sites.

D: A+B => authors will therefore misuse this feature.

E: C+D => this feature is pointless.

We shouldn't implement pointless features.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'