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

[James Craig]

Snipping somewhat for brevity…

On Nov 27, 2012, at 8:02 PM, Ian Hickson <ian at hixie.ch> wrote:

> Sites have been quite happily working with a "skip past navigation" 
> link

Happily? Begrudgingly? For what it's worth, landmark navigation should not be confused with "skip nav" links. Think of it more like a hierarchical navigation, similar to jumping by heading, but with more semantics and at a higher level.

> , 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

Landmark navigation is now one of these tools, why prevent authors from explicitly using it for main content?

> (which isn't necessarily the "main" 
> content; e.g. on youtube.com you probably want the search box, not the 
> stream, in many cases).

That seems very subjective, and possibly off-topic.

> 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 if they do, that's fine, and we're still left with the main content via the "scooby doo" method.

<main>
  <nav> … </nav>
  <p> first bit of main content </p>
  <footer> … </footer>
</main>

…but if they get it right, heuristics get even better.

<nav> … </nav>
<main>
  <p> first bit of main content </p>
</main>
<footer> … </footer>

In either case, explicit landmark navigation to "main" could move the screen reader cursor to the "first bit of main content"…

Without a <main> element, this is ambiguous:

<nav> … </nav>
<p> first bit of main content </p>
<p> not main content </p>
<footer> … </footer>

Correct use clarifies the structure:

<nav> … </nav>
<main><p> first bit of main content </p></main>
<p> not of main content </p>
<footer> … </footer>

And incorrect use frequently turns out fine anyway, and does not negatively affect use on other pages:

<main>
  <nav> … </nav>
  <p> first bit of main content </p>
  <p> not main content </p> <!-- it might not be the "main" main content, but it doesn't make the feature useless as you've stated -->
  <footer> … </footer></main>
</main>

As you've pointed out, incorrect use of @alt on one page does not prevent other pages from using @alt correctly. Likewise incorrect use of <main> would not prevent a user from using other navigation mechanisms on this page, and does not deter a user from using it on other pages, and in many case, incorrect use of <main> would still work as a reasonable landmark.

> 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.

No argument here. <main> is pretty intuitive, and the penalty for misunderstanding its use is next to nothing.

> 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.

Again, I don't follow your logic. Even misused, it's still just as good as the "scooby doo" method, and misuse does not make it useless.

>> 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.

That's how *some* authors *may* use it, but that's okay, even if they do.

>> 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=""?

Irrelevant. @longdesc isn't implemented well due to other significant design problems.

> Heck, how well did it work for alt=""?

Pretty well actually. When a screen reader user hears an unlabeled "button" or "image", they know exactly what is wrong, and what to report.

> Accessibility users complaining doesn't lead to sites getting fixed.

We fix user-reported accessibility complaints all the time. So does your company, and many others. There are scores of blog posts and podcasts from indie iOS app developers talking about how they'd never heard of accessibility until a few vocal users of their apps spoke up, and these developers were able to fix their bugs with minimal effort, thanks to the fact that they were made aware of the problem by their loyal customers.

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

Agreed, but they don't (and shouldn't) have to.

> B. Authors won't understand this feature.

Disagree, but the cost of misunderstanding is negligible.

> 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.

Disagree strongly, and I'd argue that you're making a lot of incorrect assumptions about users of assistive technology.

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

Agree partially.

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

Disagree strongly.

> We shouldn't implement pointless features.

Agreed, but <main> isn't one of those.