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. > 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. 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>. It might sometimes co-incide, but oftentimes it won't. > > so I don't see why they would make sense to be supported while <main> > > doesn't. > > The use case for e.g. <header> is mainly one of maintenance and styling: > lots of people style their headers very specifically. In general it > doesn't matter if one author marks his navigation as being part of his > header and another marks his navigation using <nav>; the result is the > same: they are clearly marked in the source, they can be styled, and they > can be skipped. If one author doesn't use it, or even if most authors use > it incorrectly, it doesn't mean that other authors can't use it. > > 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? Because then Web developers have a means to find out that they've made the wrong markup. 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? > 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. If that is not possible (because we need to leave keyboard shortcuts to apps), it could at least become part of developer tools. In Chrome we have a developer tools plugin to run accessibility audits - it would be simple to add it there. I'm sure we can come up with a sensible way to make testing <main> part of Web development. 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. 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. Regards, Silvia. [1] http://www.youtube.com/watch?v=tua3DdacgOo#t=117s
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
