W3C home > Mailing lists > Public > public-html-a11y@w3.org > November 2012

RE: main spec updated - changes to parsing and rendering

From: David MacDonald <david100@sympatico.ca>
Date: Sun, 18 Nov 2012 11:54:52 -0500
Message-ID: <BLU0-SMTP74393171129C8CB3D7E080FE570@phx.gbl>
To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>, "'Steve Faulkner'" <faulkner.steve@gmail.com>
CC: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
I don't think we should be heavy handed about it.


I think authors will be happy not to have to do <div id="main"> which is
what I see a lot of. I believe that a slideshare from Patrick Lauke had id=
"main" as the 12th most popular class on the web...


We have <nav><article> etc... let's recommend it as a missing element in
HTML5 in the same category as..



David MacDonald


CanAdapt Solutions Inc.

  Adapting the web to all users

            Including those with disabilities

 <http://www.can-adapt.com/> www.Can-Adapt.com


From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: November-18-12 5:20 AM
To: Steve Faulkner
Cc: HTML Accessibility Task Force
Subject: Re: main spec updated - changes to parsing and rendering


On Sun, Nov 18, 2012 at 7:39 PM, Steve Faulkner <faulkner.steve@gmail.com>

Hi Silvia,


>this should be something that every Web page/application provides for.


It should be something that authors/developers add when the content of the
document contains a sub content area that can be logically identified as the
main content, distinct from other sub content areas.



As specified main is not a required element nor is it expected that browsers
will add an implied main semantic to every document, which is why there is
no requirement to parse every web page as per your example.

Thanks for the clarification. Let me then put forward the suggestion to
change this, because I think if we leave the use of <main> on a voluntary
basis, we will likely fail with this element.

I think we should be bold and actually ask to make <main> a required element
on Web pages - whether author provided or not. This means that in the cases
where the author does not provide a <main> element, the browsers have to
create one. They can use a good heuristic to position it - such as "before
the first <article> element on the page" or "before the first <h1> element
on the page" or "after any <menu>, <header> or <aside> element" or all of
the above and a bit more. Something we can codify for HTML.

I'm saying this because if browser are forced to create a <main> element,
every author will see in their inspector where the browser place the <main>
element and they can validate and correct it by explicitly creating the
<main> element.

If instead we make it a voluntary element as proposed, authors will see no
consequence when they don't have a <main> element. Only accessibility
developers will notice the lack of a <main> element and will create one, so
the situation will not be any better than with @role=main today: we won't
get more sites using it and we won't get better accessible main content on
Web pages.

If we want to get the general Web authors to become used to writing <main>,
it should have a consequence when they don't do it.

Received on Sunday, 18 November 2012 16:55:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:32 UTC