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

[Silvia Pfeiffer]

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.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121128/eb276be2/attachment.html>