Ryosuke Niwa <rn...@webkit.org>, 2012-11-29 19:10 -0800:
> Furthermore, there is nothing that prevents authors from using main
> element today since the only difference will be whether it's recognized
> by AT and that prototype name will be HTMLMainElement once we support it.
It actually just uses the HTMLElement interface, so yeah, there is no
difference as far as how what this exposes to scripts. Well, none other
than the fact that script libraries and such would now be able to make use
of, e.g., getElementByTagName("main"), to select the main content of the
page (to the degree it's useful to scripts to have a way to do that).
> I would have been more supportive of the patch if it were adding some
> Web-content visible API but this is one feature authors can start using
> today without us explicitly supporting it.
True it does not add any new Web-content visible API -- which is also the
case for <section>, <article>, <nav> and <aside>. In that regard they're
all just markup sugar, and I personally wish we'd not added any of them to
begin with -- that is, if it weren't for the need that James describes:
That the patch includes a change that causes AccessibilityRenderObject to
expose the element to AT in a special way.
I'd personally go so far as to say that's the only compelling reason for
adding <main> or for having added <section>, <article>, <nav> and <aside>.
So yeah, while it's not adding any new Web-content-visible API (other than
what it brings for selectors) it is doing something at least as important
in that it provides a better standard way for Web content to identify the
main content of a page to AT users. I say "better" because yeah we already
have role=main. But I think James has articulated why this is potentially a
much bigger win as far as getting Web authors to actually take the time to
mark up their main content in way that makes it accessible to AT users.
And as far as how much of a win this is for AT users, all I can say is,
while as sighted users we mostly have a pretty easy time visually
identifying the part of a page that's the main content, and getting to it
quickly, if instead your eyes you use AT (even if it's just as a sighted
user using it for testing) one of the most frustrating obstacles to trying
to navigate Web content is the work that you have to do as a user to skip
past all the junk on that page that you have no interest in reading, and
get to the content that you came there to read and use. For every document
you try to navigate on the Web.
So having <main> be exposed by browsers to AT, and having Web authors start
to use in on scale, has the potential to materially effect the user
experience of non-sighted Web users in an extremely positive way.
That said, not everybody agrees that it's a win for accessibility. Hixie
doesn't believe it is, at least. If he did he would have already added it.
But it makes sense to try to weigh that against, say, the views of the
accessibility-development community -- that is, the core group of people
who spend the bulk of their standards work working on accessibility-related
standards. And as James pointed earlier, while within that group there are
other accessibility-related markup features -- like longdesc -- that some
of them are strongly opposed to, the support for <main> within the
accessibility-development community is near unanimous.
Anyway, I'll shut up on this thread now. I realize a lot of this is
mostly off-topic for this list, but I think it's worthwhile to say some of
it here to help the webkit-dev community make an evaluation.
--Mike
--
Michael[tm] Smith http://people.w3.org/mike
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
