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

On 1 December 2012 22:19, Maciej Stachowiak <mjs@apple.com> wrote:

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

Webkit does something similar for <header> and <footer> [1]:

"The current behavior for the `header` element is slightly more complex: if
> the `header` element is not contained within an `article` or `section`
> element, it has a description of "banner". If it is contained in one of
> those elements, it falls back to "group"."
>


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

While I think this is interesting, I am unclear about how the 'main
content' area would be conveyed to assistive technology users.
My thinking is that an element with a role will be required, what if there
is no container element present in the DOM? what if the container element
already has a strong role exposed?
Is it suggested that an element be added to the DOM by the browser in the
case where no main element container is present?

FYI
this article provides details about landmark support in AT (as of  July
last year)
http://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-aria-landmark-support/

 This article contains other stuff about landmarks and how  I see the
relationship between HTML5 elements and landmark roles
http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/


regards
SteveF

[1] https://bugs.webkit.org/show_bug.cgi?id=78992



On 1 December 2012 22:19, 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.
>
> 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.
>
> Thanks,
> Maciej
>
> On Dec 1, 2012, at 5:13 AM, Steve Faulkner <faulkner.steve@gmail.com>
> wrote:
>
> Hi James,
>
> The current author conformance errors as per the spec [1] are:
> multiple <main> = an error
> <main> inside any of the following article, aside, footer, header or nav.
> plus any conformace errors related to the elements content model.
>
>
> On a first pass I consider your suggested additions sensible and will work
> with you and others to work out the best way to incorporate them into the
> spec.
>
> I also think it is sensible to discuss with mike smith and henri sivonen
> about the practicalities of expressing these conformance errors via
> conformance checking tools.
>
> regards
> Steve
>
> [1]
> https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
>
> On 30 November 2012 22:41, James Craig <jcraig@apple.com> wrote:
>
>> Despite the <main> element extension specification being approved "with
>> no objections and ample support" by the HTML Working Group [1], some
>> arguments have been resurrected on a few lists recently, including
>> webkit-dev [2].
>>
>> While I don't share Ian's concern that misuse or misunderstanding of the
>> element will make <main> "pointless", he has a valid concern that there is
>> some potential for incorrect use. I personally feel that the penalty for
>> such misuse is negligible [3], but we should do everything we can to avoid
>> misunderstanding and warn authors about misuse, so I'm proposing a
>> heuristic to trigger author validation warning upon detection of probable
>> misuse, thereby making the spec for <main> a little bit stronger, and
>> address the primary case that I believe is the cause of Ian's concern.
>>
>> I'll begin by defining what I consider "misuse" of the <main> element.
>>
>> I'd consider it misuse of <main> to be used as a direct replacement for a
>> wrapper element (like <div id="body">) that contains all standard page
>> contents, including the navigation and footer, in addition to the actual
>> primary content or 'main' content.
>>
>> Misuse Example:
>> <body>
>>     <main>
>>         <header></header>
>>         <nav> … </nav>
>>         <div id="primarycontent"> this is the real 'main' content </div>
>>         <footer> … </footer>
>>     </main>
>>     <!-- with possibly some appended dialogs or panels out here -->
>> </body>
>>
>>
>> However, there are some times when it would be valid to use <main> as the
>> wrapper element with no other programmatically discernible landmarks.
>>
>> Valid uses of <main> Example 1, with no other discernible landmarks:
>> <body> <!-- example: this may be iframe contents -->
>>     <main> this is the real 'main' content </main>
>> </body>
>> <body>
>>     <main> this is the real 'main' content </main> <!-- not a misuse of
>> main, despite the follow misuse of footer -->
>>     <div id="footer"> … </div> <!-- this should be a footer element, but
>> that info is not programmatically determinable -->
>> </body>
>>
>>
>> Likewise, there are times when it's valid to nest landmarks, so we should
>> not trigger a warning for something as simple as a <nav> element inside
>> <main>:
>>
>> Valid use of <main> Example 2, with nested landmarks:
>> <body>
>>     <header></header>
>>     <nav> … </nav>
>>     <main>
>>         <div id="primarycontent"> this is the real 'main' content </div>
>>         <nav> secondary navigation inside main </nav>
>>     </main>
>>     <footer> … </footer>
>> </body>
>>
>>
>> I think, however, we can safely trigger a warning for the error case
>> mentioned above, because there are no discernible landmarks outside main
>> element, but there are one or more discernible landmarks inside main.
>>
>> Misuse Example:
>> <body>
>>     <!-- no discernible landmarks outside main -->
>>     <main>
>>         <!-- but multiple discernible landmarks inside main -->
>>         <header></header>
>>         <nav> … </nav>
>>         <div id="primarycontent"> this is the real 'main' content </div>
>>         <footer> … </footer>
>>     </main>
>> </body>
>>
>>
>> Explicit ARIA landmarks outside the main element should probably also
>> prevent the heuristic from triggering a warning:
>>
>> Valid use example for main (misuse of header/footer though):
>> <body>
>>     <div id="header" role="banner"> … </div> <!-- bypasses the warning
>> because of the explicit aria landmark role outside main -->
>>     <main>
>>         <nav> … </nav>
>>         <div id="primarycontent"> this is the real 'main' content </div>
>>     </main>
>>     <div id="footer" role="contentinfo"> … </div> <!-- bypasses the
>> warning because of the explicit aria landmark role outside main -->
>> </body>
>>
>>
>> I have not yet proposed any specific wording for what will probably end
>> up as an RFC-2119 author "SHOULD NOT" requirement, because it deserves more
>> discussion first.
>>
>> Thoughts?
>> James
>>
>>
>> 1. HTML WG Approval of <main> extension spec:
>> http://lists.w3.org/Archives/Public/public-html/2012Nov/0232.html
>>
>> 2. Webkit dev thread:
>> http://lists.webkit.org/pipermail/webkit-dev/2012-November/023013.html
>>
>> 3. The penalty for misuse of <main>, with regards to landmark navigation,
>> is about the same penalty that users pay when authors hierarchically
>> structure headings incorrectly. (e.g. h1, then h3, without an h2 in
>> between). Multiple non-linear navigation mechanisms still work, but there
>> is a minor loss of clarity in a screen reader user's ability to grok the
>> page structure at a high level. In my opinion, this cost is relatively
>> trivial compared to the potential wins we get by adding the accessible
>> landmark role to the default semantics of the <main> element when used
>> correctly.
>>
>>
>
>
>