On Wed, 28 Nov 2012, Silvia Pfeiffer wrote: > On Wed, Nov 28, 2012 at 11:22 AM, Ian Hickson <i...@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. `._.-(,_..'--(,_..'`-.;.' _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev