Re: Technical concerns about the addition of <main> to HTML

Hi David,

Apologies for dragging you into it, but thank you for your input. You were
cited by Brendan Eich on a public list[1] as having an opinion on <main>
and also cited as a person to ask for feedback from [2] and you also asked
where to comment [2]. Please feel free to redirect the request for feedback
to more appropriate Mozilla folk.


We ought to avoid leaving
> students of HTML to puzzle over questions of the form "When do I use
> element A vs. B?" unless we have a good reason to do so.  (For
> example, when do I use <main> vs. use the other approaches in
> http://dev.w3.org/html5/spec/links.html#the-main-part-of-the-content ,
> or both, or neither?)
>

I agree, which is why I think a specific container element with specific
semantics is preferred to re purposing other elements which already have
strong semantics (i.e assigned roles in the accessibility layer). The
suggestions cited in the HTML spec do not provide a reliable method of
ascertaining what the main content area of a web page is, as the idealised
examples are not representative of real world web content.


So what would demonstrate the value of <main> to me?  Probably the
> biggest thing would be examples of real pages where the use of
> role=main improves accessibility, or where it would have improved
> accessibility had it been used.  (This may well have been presented
> somewhere; I just haven't seen it.)
>


data and analysis of ARIA landmark use in the wild:
http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/

A short video on use of ARIA landmarks by screen reader users by Leonie
Watson an accessibility specialist, HTML accessibility taskforce member and
screen reader user: http://www.youtube.com/watch?v=IhWMou12_Vk

Summary of rationale for addition of main to HTML [3]:


   - HTML has a pattern of providing an explicit declarative method for the
   identification and marking up of significant semantic structures via
   elements and attributes. Additional semantics can also be applied by an
   author to elements in HTML using ARIA attributes.
   - There is an existing pattern in
browsers<http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#api-role>of
mapping these elements to roles, states and properties in
accessibility
   APIs
   - There is an emerging pattern in browsers of mapping ARIA semantics to
   HTML features <http://www.html5accessibility.com/> when roles, states
   and properties are not already present in an accessibility API.
   - There is an existing pattern of authors defining a distinct
container<http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html>for
the main content area of a web page using semantic id values.
      - It has a high correlation with the use of the ARIA role=main which
      is a semantic marker for the main content area of a web page
      - It has a high correlation with the use of the the id value as a
      document fragment identifier used as target for 'skip links' to the main
      content area of a web page.
   - Existing authoring practises for the identification of content
   structures has previously been used as a reason to add
   header/footer/article/aside and other elements.
   - Assistive technology have a pattern of using the *explicit semantic
   information exposed by HTML elements* via accessibility APIs and/or the
   DOM to make users aware of the structures and represent their relationship
   with other structures:


regards
SteveF


[1] http://lists.webkit.org/pipermail/webkit-dev/2012-November/022997.html
[2] https://twitter.com/stevefaulkner/status/275135958339448833
[3] Use cases and rationale:
http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction

On 6 December 2012 09:15, L. David Baron <dbaron@dbaron.org> wrote:

> On Wednesday 2012-12-05 09:51 +0000, Steve Faulkner wrote:
> > It has been suggested that there are significant technical concerns from
> at
> > least one set of implementers about the <main> feature [1], and therefore
> > [2]
> >
> > "<main> does not meet the high bar required to add a new element to HTML"
> >
> > It would be super useful  if any implementers with technical concerns
> > provided them publicly on this list as while feedback has been sought in
> a
> > number of other fora [3] and while the feature has been officially
> rejected
> > as per the  WHATWG process [4], the feature is being standardised through
> > the W3C, not the WHATWG and has recently passed a CFC for FPWD at the W3C
> > with no objections and ample support [5].
>
> Since I seem to keep getting dragged into this despite it being
> outside of my area of expertise (I think as a result of being on the
> cc list of a private thread, despite not expressing an opinion there
> either), I suppose it's best that I at least say what I think.
>
> I'm quite sympathetic to the argument (which I thought I heard, but
> I now can't find a citation for) that it's the only ARIA landmark
> role that doesn't have a corresponding HTML5 element.  After all,
> ARIA was originally sold to folks at Mozilla (in private
> conversations at the 2007 technical plenary, if my memory is
> correct) as a temporary stopgap to provide additional semantics
> needed for accessibility until HTML5 was able to provide those
> semantics.  I think it's a worthwhile goal for HTML to have enough
> semantics to express what's in aria (or at the very least to express
> the parts of aria that have proven to be useful based on
> experience), so that aria can eventually become just a description
> of the underlying model that doesn't need to appear in markup.
>
> I also think there ought to be a high bar to adding new semantic
> elements to HTML.  This is not because of the cost of
> implementation; that's low.  It's because it increases the cost of
> teaching good HTML authoring practices.  We ought to avoid leaving
> students of HTML to puzzle over questions of the form "When do I use
> element A vs. B?" unless we have a good reason to do so.  (For
> example, when do I use <main> vs. use the other approaches in
> http://dev.w3.org/html5/spec/links.html#the-main-part-of-the-content ,
> or both, or neither?)
>
> So what would demonstrate the value of <main> to me?  Probably the
> biggest thing would be examples of real pages where the use of
> role=main improves accessibility, or where it would have improved
> accessibility had it been used.  (This may well have been presented
> somewhere; I just haven't seen it.)
>
> I'm not at all close enough to the issue to draw a conclusion from
> any of these things; I trust others to do that.  If I were being
> asked to review a patch to add it to Mozilla (despite that I'd be
> the wrong reviewer, since it's not my area of expertise), I'd
> probably be asking for more information rather than accepting or
> rejecting the patch.  So I'm neither a supporter nor an opponent of
> <main> at this point:  probably not convinced enough to accept a
> patch, but certainly nowhere near opposed enough to make a formal
> objection at W3C.
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂
>