Consider aligning WHATWG main element definition with W3C definition #100
Comments
|
@Hixie, do you have a summary handy for why the definition is as it is? I remember lots of emails on the topic, so perhaps there's something in the archives. |
|
From my perspective, the implementors added support for parsing a "main" tag. I came up with something that it could make sense for. Ideally it wouldn't exist at all, but since it was already implemented, it was cheap to add the semantics for it. The element as specced over in W3C land makes little sense when you think about it. I doubt the 97% number, as I suspect it categorises a bunch of cases that are "WHATWG-like" as "W3C-like". For example, if a blog uses <main> around the body of each blog post <article>, and has 200 posts (one <main> each) plus six months of archives (one <main> per post in the month), then you'd have 200 pages that appear to be "W3C-like" and 6 pages that appear to be "WHATWG-like", which would give you the 97%, despite the reality of that site being that it uses it in a "WHATWG-like" fashion uniformly. |
|
I think the more important deviation is how authoring affects accessibility. @stevefaulkner, my understanding is that accessibility tech relies on one main per document, is that right? Can you give some more details on:
I guess we really should be testing these sorts of things ourselves too instead of just relying on @stevefaulkner... Is there a good document for how to do such tests, preferably without buying any commercial software? |
@Hixie You don't back this statement up, so I'm not sure what you mean? @domenic I recommend installing the free screen reader NVDA and testing with Firefox. NVDA provides interfaces for navigating by landmark, including main. A list of landmarks in the page are accessible by pressing INSERT+F7 (where heading and links are also listed). In addition, you can navigate by landmark by using "D" for the next landmark (including main) and SHIFT + D for the previous landmark. JAWS and VoiceOver have similar interfaces. |
|
OK. I will try to find free time to do that and experiment with the accessibility consequences of WHATWG-main vs. W3C-main usage. In the meantime, I welcome others to give their report on such things based on their own testing, as I (and the other editors) can more easily find time to respond to such reports than we can install software and do testing :) |
|
As a screen reader user, the w3c definition aligns with my expectations pretty nicely. There should be one main per page. For moving between other pieces of content, there's headings, article, etc. This also seems to be the interpretation that jaws has taken as well, given that their keystroke modification to list all elements of type "x", where "x" is main, defaults to block quote instead of main. The reason for this is that they repurposed 'q' in the virtual cursor to move to the main element, and with their model, whenever you modify a shortcut key, such as 'q' or 'a' for radio buttons or 'h' for headings, with JawsKey+ctrl, you get the list of elements of that type. So for example, JawsKey+ctrl+a lists all radio buttons. However, JawsKey+ctrl+q lists all block quotes instead of all main elements, which is what would be mapped if they expected there to ever be more than one. I don't wish to imply that an AT's interpretation should receive all that much import over figuring out the "right semantics", but it is contributory to at least figuring out where other folks' heads are at with this element. Also, anecdotally, I've found better success jumping to main, whenever it is available, than jumping to an h1, which so often is abused and used incorrectly. |
|
From a quick partial grep of the latest webdevdata files (jan 2015) |
On the contrary, I think this is probably the most important indicator of the right semantics. I am just one editor, and this perspective might not be shared by the others, but it's the one I try to argue for. Thanks very much for this info. Since JAWS is expensive, your report is especially valuable, since fewer of us can test it. Much appreciated. |
|
As a screen reader user I also don't expect more than one main element on a page. If it is used on a web page I find it a very useful landmark to navigate to. As @sinabahram said as well, ithink that there are enough methods available to properly mark up multiple blocks of content on a page (article etc). The blog archive example that has been named earlier in this thread would actually cause me to think I landed on a single article page after jumping to the first main element and landing at the start of a blog post. |
|
@sinabahram @bramd it's not really clear from your comments how screen readers deal with multiple |
|
I’m a bit confused by this. are we wanting to determine if multiple mains breaks something or whether or not it makes sense? There are three possibilities to be enumerated based on first principles. (1), multiple mains doesn’t make sense We’ve covered this one, I feel. (2): Multiple mains does make sense and screen readers do not handle it correctly (there’s an entire rabbit hole with browser accessibility APIs, AT expectations, etc., but the results can easily be paper prototyped as follows) A. Multiple mains exist on a page B. The screen reader key to navigate to main navigates between them, just like it does with radio buttons, form fields, regular buttons, edit fields, headings, links, paragraphs, etc. C. We end up discussing/debating things with AT folks like “list all mains on the page”, etc. etc. (3): Multiple mains does make sense and screen readers handle it correctly. Then there’s probably less to discuss, although even if this were to be true, we could still debate the points A through C from (2) a bit. So before we even begin discussing those issues like how the AT handles it, etc., can you help clear up my confusion on whether we are even interested in those mechanics before establishing whether multiple mains does make sense? I’m simply trying to apply short circuit evaluation to the logic of this discussion so as not to waste time going through specifics of (2) and (3) if we don’t need to, or to ask why the specifics of (2) and (3) would affect their leading point, which is to state that multiple mains does make sense. I hope that makes sense. |
|
My perspective is that multiple mains do make sense. I've used them in a few large apps before (internal mostly, for finance firms), and the spec documents how to do so. As such, I like the current spec. However, if such usage of mains is causing problems for users of accessibility technology, then we need to reconsider. So basically: (1) is false (I know some people love to debate this, but from the perspective of the current spec and at least a couple of its editors, that's the case). (2) would mean we should change the spec. (3) would mean we probably shouldn't change the spec, depending on what "correctly" means. Although even if it's (3), there have been some comments about screen reader user expectations on this thread that might change things. |
What would be helpful is for the spec editors to provide some data and detailed reasoning to back up their perspective, otherwise it sounds like argument from authority. |
|
I am a screen reader user and I really do not want more than one Main landmark on any webpage. I tested to make sure my screen readers didn't malfunction in any way when I put 2 mains on a page, but it just isn't user-friendly. In all the cases I can imagine, it would be better to stick with one main and have multiple article tags. Besides screen reader usage, consider a definition of the word. Main: "Of chief or principal importance." Having more than one main landmark on a webpage makes no more sense than having more than one main street in a city. |
|
Multiple instances of main do not break current screen reader support. Those that provide a mechanism for cycling between all landmarks include multiple instances of main in the cycle. Those that provide a shortcut specifically for the main landmark treat it as cyclical if there are multiple main elements on the page. The model for landmark navigation is based on the same model that screen readers have been using for all element types since the early 00s. In other words, the fact it works with multiple main landmarks is not by specific design, but by dint of the fact that's how element based navigation has always worked in screen readers. The issue isn't one of AT support though, it's the usability of the thing that's important. The definition of "main" is generally accepted as something that is predominant. Dictionary.com defines "main" as "chief in size, extent or importance; principal; leading". Linguistically we tend to use "main" and its synonyms in the singular - the main road, the principal designer, the chief problem, the main force etc. If we agree to meet "by the main entrance to the building", that's pretty clear. It's probably those big doors at the front of the building, possibly leading out onto a/the main street. It's the same with the main element. When we say/hear the "main content" or "main region" of a page, the expectation is that it'll be that predominant chunk of content. So the user expectation is that there will only be a single main area on a page. From the stats @stevefaulkner has shared, it seems that developers are working on the same expectation too. Speaking as both screen reader user and developer, a single main element seems like the sensible thing to me. |
|
If I tell my friend to meet me at the main entrance of the hotel, we both know where to meet. There is only one. It is a clear distinguishable important landmark. I teach web developers to use only one Main element on page. |
|
There's only one main entrance to a hotel, which is fine, if the page is a single-article (single-hotel) page. but what if the page is a multi-article page (a street of hotels?). Then there's many main entrances. |
|
@Hixie difference bewteen the 2 is that whatwg definition is at odds with user needs and is without any data to back up its definition. |
|
@Hixie says "a street of hotels?" You answered the question yourself, then. It would be a |
|
@Hixie think of it this way: An archive page is a collection of articles, but there is still only one main area of focus. There may be side bars, other navigation mechanisms etc., but there is one main area of a page that, coincidentally, might host more than one article, or just one article. To bring up an analog analogy: A printed book has one main section, it may have one table of contents, it may have a glossary or something other. But it will have one main section that consists of one or more chapters. These might again be divided into sub sections etc. But what you will not find is a book that has more than one table of contents strewn about throughout the book, or more than one glossary or even more than one cover page. There may be several complementary items in a book, like said glossary, like an author index, and others, but you will only find one main element in a book, not several. If there were several, these should be separate volumes. The same is true for any web page, be it a single article on a blog, or a collection of articles because we might be dealing with an archive page. There is only one main area that contains such archive articles, not several. This is my expectation of web pages. This is how I navigate as a screen reader user. This is what makes sense to me when I deal with the wilderness the web is. I support aligning the WHATWG spec with the W3C one because of exactly this reason. |
|
Having multiple main regions on a page seems illogical. It can also cause real confusion for people who can't see the screen. Screen readers often start to read the page as soon as it has loaded and if the site is visited frequently, some of them can also bypass content at the top of the page that is recognised as being repeated on other pages. To help users understand where they are on the page, as @sinabahram said in a previous comment, JAWS provides a single key shortcut "Q" to take users to the main content region. If the screen reader has already reached or passed the start of the first of multiple main regions, pressing the "q" key will take the user to the second one. If there is only one main region then the same keystroke will take users back to where the main content starts. So multiple main elements could mean that screen reader users can't be really sure where they are on the page and may miss the most recent article (at the beginning of main content) without knowing that they've done so. As a screen reader user, My vote is for just one main element to enclose the content that is unique to the page. It can contain many article elements, but in these days where websites frequently use multiple h1 headings, there really needs to be one reliable way for blind people to find out where the good stuff actually starts. |
|
Just a warning that re-treading old arguments is not likely to change anything. The new information about screen readers is useful but telling us how you feel about the English definition of the word main, or similar things, is not useful. So far the only actually new content gained in this thread can be boiled down to two sentences:
Everything else so far in this thread has been a rehash or a statement of personal preference, and is in danger of obscuring the issue. |
|
@domenic I thought the utility of a features use to people who consume the semantics (i.e. actual screen reader users) and how developers use the element would be useful data points?
appears to be the only reasoning offered by the editors currently and historically. |
|
Those data points have been amply made in previous discussions that led us to where we are today. Repeating them is not helpful. |
|
@domenic OK, are we to expect some reasoning and data from the editors on why their personal preference is better for users? |
|
Again, I would really encourage you to read previous threads on this matter. I would appreciate if nobody replied to this thread unless they have new information, not questions about old information. If you want to continue old debates, those are best done on old threads. |
That is my point, there was never any reasons or data provided in the first place despite it being asked for, I was involved in all the orginal discussions. |
Thank you for this information. Can you please cite the thread where the data that @stevefaulkner is asking about has been provided? |
|
@karlgroves
https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0172.html |
You are redefining what @domenic Given the intended purpose of |
|
Am I the only screenreader user on this thread? Can anyone hear me? Allowing more than one <main> tag per page will totally devalue it’s currently unique and incredibly useful status. There are so many other ways to jump between articles. Why why why reintroduce all of the pre-HTML5 confusion for people who may already find navigating webpages very difficult, just for the sake of what tbh seems like pedantism? Please trust your users and put our needs high on your agenda. Thank you.
… On 7 Jan 2018, at 08:52, Heydon Pickering ***@***.***> wrote:
The issue is that there is no clear one main part of the document on a blog front page. There are multiple articles, each with a main part, which users may want to cycle between.
You are redefining what <main> is in order to make your case. It was not specced for the use case you describe, there is no evidence that it is a use case users want, and it is a use case covered by other HTML/AT behavior as I described elsewhere in the thread.
@domenic Given the intended purpose of <main> and the overwhelming support that this purpose is only fulfilled in its singular form, can you agree that the WHATWG spec' needs to reflect this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@frex65 I hear you, big time! |
|
I already added all I had to add to this discussion, and my opinion has not changed. One main element per page, everything else is not what a clear vast majority of users, including myself, want, and nothing else makes sense for this element.
|
|
The WHATWG position now appears to be: "You have to provide more data and evidence for the formulation of the element you specced, but we don't have to provide anything." EDIT: At least in so far as what @domenic has written. Even without the evidence of AT usage, a singular "We are following what users and designer seems to — and have told us they — want and building a bus." |
|
I don't think there's a WHATWG position as I disagree with Domenic. I've pressed him on the same point, in private, and will continue to do so. I should probably not have tuned out of this discussion back when it started as much as I did and pushed Ian too. I remember finding the revised definition of I'm sorry it took so long, but I'm hopeful we can get this much closer to something satisfactory for everyone soonish. |
Your question may be rhetorical, but either way I think it is worth reminding everyone that lots of screen reader users have commented on this thread over two years and all both understand and prefer a single |
|
About @domenic's #100 (comment):
If we were to make I found the code for this in Chromium. The elements within which Doing this for As for what advice to give to web developers on something like MDN or https://html.spec.whatwg.org/dev/, recommending a single But we still have to decide what markup is valid, and per #100 (comment) it seems like a bad idea to simply make multiple
@annevk, do you already have some changes in mind here? |
|
My thinking is as @stevefaulkner said elsewhere: that we make a single Having said that, I'd be comfortable with making that "should" a "must" and seeing if we get feedback that is prohibitive somehow. I'm rather doubtful we'd get any since I haven't really seen any advocacy for multiple |
|
did a new HTML data crawl from top 100,000 sites - will be publicly available soon |
|
@annevk, @sideshowbarker, would "should" vs. "must" make a difference to what a validator says? |
|
@foolip warning versus error, as I understand it. |
|
For people who, like me, were confused by where all the old discussion has gone, search for "items not shown" to expand ~60 comments. That's where @stevefaulkner and I look at a lot of pages in detail, and what I'm referring to in #100 (comment). I expect that if we took a new look today, we'd still find "Cases where merging them would require marking up other parts of the page as aside or similar." |
|
@foolip wrote:
As previous and current data indicates these cases are very few and far between, why would we want to encourage or accommodate such cases where there is no evidence that they improve user experience? It's not as if developers don't have other markup choices in these instances. |
|
10 pages with the most instances of main elements: from today's html dump |
|
Taking a look at the source of the pages Steve displayed, it seems like the web developers are treating main as synonymous with article (thoughtcatalog.com and baltana.com), or just some kind of silly putty inserted for grins and giggles (worldofwarships.com and umr.com). Point of fact, some of these look like they're based on the same template, or by the same developers (the ones that directly nest main elements in article). We don't want to encourage this type of markup, do we? Forget the mess it would create for a screen reader—the use of the main element in these pages make no sense. There's no logic to the use. Ugh. |
|
Here's a look at one of those pages using VoiceOver's landmarks menu. It's odd -- they use a single
|
|
@stevefaulkner wrote:
I don't think the spec (or MDN) should encourage multiple main elements, it's a rare case that need not be emphasized even if left conforming. Seeing "98.9%", I am tempted to repeat #100 (comment) and onward, to look for the sensible cases instead of the worst, but let's not go another round. Apart from the I'm in favor of the "should" option in #100 (comment), perhaps with |
|
It's funny, when I asked for DANE validation of TLS certificates to be added to browsers, and I asked loud enough to actually get responses from Google and FireFox developers, the answer was always that the merits of DNSSEC and DANE didn't really matter because most sites were not using DNSSEC so there was no point in adding DANE validation to the browsers. But with the main element, even though the vast majority of statistics show that the use of more than one main element is very rare, the WhatWG wants to hang on to it. A group made up of the same coalition of browsers that didn't want DANE because it wasn't being used. More than one region landmark on a page is desirable and heavily used, but how many web pages legitimately have more than one main section? It doesn't seem logical to continue supporting what definitely causes confusion and is seldom used. What problem is solved with more than one main that can't be solved by using appropriate region landmarks that aren't main? |
This changes examples involving the main element as they do not lead to a good experience with assistive technology. It also adjusts the definition of the main element a bit and suggests it's best to be used at most once. See #100 for context.
Multiple main elements are still allowed if all but one have the hidden attribute set. This also slightly alters the definition of the body element as it effectively encompasses all content of a document, except for some metadata. Fixes #100.
|
#3354 contains what I believe is the correct fix for this issue. Review welcome. I have one minor quibble though with the semantics argument. Context is important for semantics. I think it would have been fine if the If the |
Multiple main elements are still allowed if all or all but one have the hidden attribute specified. The main element is also restricted in terms of where it can appear in a document. It can only have html, body, form without accessible name, div, and autonomous custom elements as ancestors. This also slightly alters the definition of the body element as it effectively encompasses all content of a document, except for some metadata. Fixes #100.
This changes examples involving the main element as they do not lead to a good experience with assistive technology. It also adjusts the definition of the main element a bit and suggests it's best to be used at most once. See whatwg#100 for context.
Multiple main elements are still allowed if all or all but one have the hidden attribute specified. The main element is also restricted in terms of where it can appear in a document. It can only have html, body, form without accessible name, div, and autonomous custom elements as ancestors. This also slightly alters the definition of the body element as it effectively encompasses all content of a document, except for some metadata. Fixes whatwg#100.
and others
The main element was designed and implemented based on the concept of there being a single instance within a document, the markup pattern was based on data of id value usage in the wild. The whatwg definition differs markedly from the orginal definition. This leads to confusion for developers.
The W3C nu html checker, which is used by many, throws an error when main is used as per whatwg. Data derived from webdevdata.org shows that >97% of usage of the <main> element is as per the W3C definition and anecdata from users that consume the semantics suggests that one main element per page is the expected and most useful pattern. In general consumers landmark semantics report that the utility of landmarks is reduced as the number/instances of landmark elements in a document increases.
The alignment would involve changes to the main and body element definitions.
current W3C definitions:
The text was updated successfully, but these errors were encountered: