Snipping somewhat for brevity…

On Nov 27, 2012, at 8:02 PM, Ian Hickson <i...@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.

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to