RE: main spec updated - changes to parsing and rendering

From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: 19 November 2012 18:59
“I have only thought about this for a couple of minutes, but I don't think it would make a lot of difference.

 

If browsers actually decide to do this, it would suggest that there is real value and that there are no real compatibility issues. But I'm not convinced that browsers do a good enough job at picking this to enforce the creation of a dummy DOM element (the TBODY case is much much easier...), and I am with Steve that success doesn't have to be getting it perfect, just getting net improvement.”

 

Good point. Was thinking around the problem of some AT vendors needing a bit more encouragement than others, but what you say makes sense.

 

Wholeheartedly agree that a net improvement would be a success.

 

Léonie.

 

From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: 19 November 2012 18:59
To: 'Steve Faulkner'; 'Silvia Pfeiffer'; Léonie Watson
Cc: 'David MacDonald'; 'HTML Accessibility Task Force'
Subject: Re: main spec updated - changes to parsing and rendering

 

On Mon, 19 Nov 2012 19:42:04 +0100, Léonie Watson <tink@tink.co.uk> wrote:

Steve Faulkner wrote:

“>I'd like to see <main> being more useful than just to replace "<div id=”main”>", but if this is agreeable as a use case by browsers, then I guess we can just >get the experience for now and make corrections later as we see what authors do with it.

So would I, which is why I have included text to encourage browsers to provide built in keyboard navigation to the main element. Your suggestions would be another step. I think we are more likely to get additional usefulness via incremental additions/modifications.”

 

I wonder whether making main a required element would encourage AT vendors to build functionality around it? I’m thinking of integrated skip link replacement, rather than functionality that includes main as one of the set of navigable landmarks.

 

I have only thought about this for a couple of minutes, but I don't think it would make a lot of difference.

 

If browsers actually decide to do this, it would suggest that there is real value and that there are no real compatibility issues. But I'm not convinced that browsers do a good enough job at picking this to enforce the creation of a dummy DOM element (the TBODY case is much much easier...), and I am with Steve that success doesn't have to be getting it perfect, just getting net improvement.

 

cheers

 

Chaals

 

Léonie.

From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 
Sent: 19 November 2012 10:32
To: Silvia Pfeiffer
Cc: David MacDonald; HTML Accessibility Task Force
Subject: Re: main spec updated - changes to parsing and rendering

 

Hi Silvia, 

>'d like to see <main> being more useful than just to replace "<div id=”main”>", but if this is agreeable as a use case by browsers, then I guess we can just >get the experience for now and make corrections later as we see what authors do with it.

So would I, which is why I have included text to encourage browsers to provide built in keyboard navigation to the main element. Your suggestions would be another step. I think we are more likely to get additonal usefulness via incremental additions/modifications.


>I fear, however, that with this as the sole purpose it will go the same way that <article> or <aside> has been going, namely not much uptake since >existing markup patterns satisfy the use case and there is no perceivable win by using <article> or <aside>.

I think it is too early to say whether most of the other elements have been successful or not, implementations are not complete and uptake is an ongoing process.
I also think that the main element has more chance of being successful as its utility does not rely upon the presence of the other elements and getting authors to add one element for accessibility reasons is easier than asking them to add a many. Furthermore the meaning of and use of the main element is easier to grasp than some of the other elements, which do confound authors in regards to when and how to use them.

data points:
of the 1440 (HTML5) page sample of the top 10, 000 web sites[1]

approx 
28% use nav
16% use article
31% use header
28% use footer
13% use aside
24% use section



[1] http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/

best regards
Steve

On 19 November 2012 07:54, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

I'd like to see <main> being more useful than just to replace "<div id=”main”>", but if this is agreeable as a use case by browsers, then I guess we can just get the experience for now and make corrections later as we see what authors do with it.

I fear, however, that with this as the sole purpose it will go the same way that <article> or <aside> has been going, namely not much uptake since existing markup patterns satisfy the use case and there is no perceivable win by using <article> or <aside>.

Regards,
Silvia.

 

On Mon, Nov 19, 2012 at 3:54 AM, David MacDonald <david100@sympatico.ca> wrote:

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

 

Cheers

David MacDonald

 

CanAdapt Solutions Inc.

  Adapting the web to all users

            Including those with disabilities

www.Can-Adapt.com <http://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> wrote:

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.

Regards,
Silvia.

 

 





-- 

Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com