Re: change proposal for <main>: possible validation warning heuristic for misuse

I think both suggestions sound good. 

On Dec 1, 2012, at 2:19 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> <chair hat off>
> 
> Hello Steve & James,
> 
> One concern raised by WebKit contributors was that <main> could end up getting frequently misused, and as a result, could harm accessibility. James's conformance rules will slightly reduce misuse, but probably not eliminate it. However, if these plus the current conformance rules capture the scenarios of misuse, how about making <main> not have an implied role=main in these cases? In other words, make it affect implementation behavior as well as conformance. This would significantly reduce the potential downsides of <main>, I think. And in the case where you truly need to violate these rules to mark the main content, you can always use an explicit role=main.

One think to consider is is that it would be hard for most authors to determine when the role semantics are invalidated by an author error. For implementations that revoke the default role of main based on this authoring error, could we require the implementation to also send a warning to the console.log?

> Another related thought: if the rule for finding the main content becomes a little more involved based on the above rules, then perhaps the spec could document how to find the main content when no <main> element or role=main is present. This would end up documenting the semi-mythical "Scooby Doo algorithm" for cases when the <main> element is absent. I think a unified "find the main content algorithm" applying these sets of rules would be really helpful to accessibility, it would help make clear why an explicit element is helpful even with a fallback approach, and it would clarify that the two need not conflict.
> 
> I just wanted to share these two suggestions.

Received on Sunday, 2 December 2012 01:21:04 UTC