resending in plain text as previous email was cutoff On Wed, 28 Nov 2012, ian hickson wrote:
> 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. The claim that developers that use ARIA are much more competent than average is unsubstantiated. a quick check (html conformance) of some data [1] does not indicate any difference in the competency of developers that use ARIA and those who do not. ARIA like HTML contains simple well understood features (such as role=main) and more complex features more prone to errors of use (such as aria-posinset) Where features are well understood, map on to common authoring concepts and easy to author they are often used correctly. > > 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). The data does not support the claim that "id="main" and id="content" often include things like some navigation, some headers, some sidebars, some footers)." It indicates that in approximately 80% of cases headers, footers, navigation etc are not included. > > 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. > 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. >From analysing the data [2] the wrapping of main content area of a web page in a div with an id value that indicates it is the 'main content' is a common occurrence, this indicates that developers do this for reasons other than accessibility as the majority do not include role=main or use the div as a target for a skip link. What the main element does is piggyback accessibility onto a common authoring practise. > Also, since few authors ever test how their > page works in ATs, they won't know that there's a problem. this is a problem, and it has begun to reveal itself due the misuse of new elements such as <section> and <article>. the difference between <main> and some of the other new elements is it is a simpler concept and is unambiguously defined. It builds on the singular instance of use per page (id value) rather than class names. > This is like the difference between <a href=""> and <img longdesc="">. If > many authors don't use <a href=""> right, big deal; their pages don't work > well, but it doesn't stop other authors from using it. If many authors use > longdesc="" incorrectly, however, it means users who try to use the > feature quickly stop expecting it to work and they give up and even pages > that use it correctly lose out. drawing a comparison between longdesc and main here is fallacious: longdesc is known to be used incorrectly much of the time while role=main is known to be used correctly much of the time. <div id=main> is known to be used correctly much of the time. longdesc is bolt on accessibility requiring not only the correct use of the attribute, but also the provision of extra authored content that the attribute points to (i.e a lot of extra effort) <main> is built in accessibility that sneaks accessibility in on the back of a common authoring practise,i.e reduction of effort, much like the <nav> element > And, since few authors ever test how their > page works in ATs, they don't know that there's a problem, and so the > feature is _more_ likely to be broken than <a href="">. that's why building accessibility into features that are based on common authoring practises is a good thing. [1] http://www.html5accessibility.com/tests/HTML5-main-content/ [2] http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html -- with regards Steve Faulkner _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
