W3C home > Mailing lists > Public > public-html@w3.org > February 2013

Re: Context of the main element

From: Jeremy Keith <jeremy@adactio.com>
Date: Fri, 1 Feb 2013 10:03:10 +0000
Cc: "HTML WG (public-html@w3.org)" <public-html@w3.org>
Message-Id: <17B35B1E-D583-44D6-8668-BF405949FA4E@adactio.com>
To: Gez Lemon <g.lemon@webprofession.com>
Gez wrote:
> An unambiguous main content area might be visually evident, but not so
> easy to find for screen reader users. When a screen reader user
> navigates through the page and hears "Main" as a landmark, it's
> important that they understand this is the start of *the* main
> section, rather than the main section of a sub-section, as the
> sub-sections are not announced at the same time due to verbosity
> reasons.

Right. And I'm not suggesting that every main element should be announced as a landmark: only the main element that is scoped to the document body.

I'd like to hear from implementers about whether this is what they're going to do anyway when they add support for the main element.

In other words, given a document like this (which is currently invalid, but browsers have to parse a lot of invalid documents), how would the browser figure out the bounds of the main landmark:

 Some unimportant stuff
  This is where the real stuff starts
   <main>Some more real stuff</main>
 The real stuff wraps up
Some unimportant stuff

My guess is that browsers will just look at the first main element to figure where the main landmark starts (and ends). That second main element would, for the purposes of skip links, just be ignored.

Am I right in that guess? Browser makers, let me know please.

Anyway, if that's the case (i.e. parsers will have to figure out how to handle the situation of having more than main element in a document, even if the spec forbids it), then altering the spec to allow authors to use the main element within sectioning content wouldn't add any more overhead.


Jeremy Keith

a d a c t i o

Received on Friday, 1 February 2013 10:03:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:31 UTC