On HTML5 and the proposed main element
As many of you probably already know, the HTML5 specification has a number of new structural elements whose intention is to add more semantic meaning to the content of a HTML document. One of the elements that some claim to be missing is a main element that would indicate the main content of a document. This might be about to change.
Steve Faulkner of accessibility consultants The Paciello Group has written a HTML5 extension specification proposing a main element to be added to HTML5.
Scooby Doo, where are you?
When repeatedly asked in the past about the need for an element that would identify a document’s main content, the former editor of the HTML5 specification, and current editor of HTML the living standard, Ian Hixie, claimed that it was unnecessary as the start of the main content can be deduced by eliminating all the other content that’s contained within elements such as nav, footer, aside and so on. This has now become known (by a term originally coined by Bruce Lawson) as the “Scooby Doo Algorithm.”
Misuse
In the past I was inclined to agree with this but after seeing how people have been using the new HTML5 elements, both when curating the HTML5 Gallery and viewing other site’s source code, the truth is that people are often not using these elements correctly and probably need any help they can get.
This in turn could mean that such a main element would also be misused, but since, unlike section and article, it’s meaning is quite clear and it is less likely to be a problem.
The existence of such an element itself would also aid accessibility, as the main content of a HTML document is easily identifiable by devices that needs to do so.
Personally I now feel that the addition of such an element would aid web authors who are laying out their content.
However.
Such an element will lead to different interpretation of what is main content?
Some may decide that all their elements are main content and therefore will lump them into any main element, whilst others may decide that all generic page headers, navigation, sidebars and footers are not main content and will therefore only enclose the page’s specific content within such a main element.
Which is correct? Perhaps neither of them are. So despite me saying earlier on that the meaning of such an element is “quite clear”, perhaps it isn’t, although Faulkner’s extension specification mentioned above does give some good examples of how it should be used, it is still open to misuse and it no doubt will be, if it is implemented.
Update –
The W3C has issued a call for consensus to publish the main element specification as a first public working draft.
8 Responses
Personally I don’t feel the main element is required. role=”main” does a more than adequate job in terms of markup and accessibility. A main element would be too vague for me. What is “main”? Is it the article itself? The article and meta data surrounding it? Is it the primary column of content which may contain multiple articles? It’s certainly open for debate.
What we can infer from data on use of id values to identify the main content, use of containers with those id values in conjunction with the role=main and as the target for skip to main content links is that authors have had and do have a clear conceptual understanding of the main content semantic. The spec also includes authoring requirements and ‘Contexts in which the element can be used’ which will result in conformance (validation) errors if misused. main is also a simpler construct than article (for example), its use is clearly prescribed and therefore less prone to misunderstanding and misuse.
Having said that I anyone has concrete suggestions on how the spec text can be improved, please provide!
PS: Links to the volumous data and use case doc are available in the notes at the bottom of the spec.
As a prevalent user of both HTML5 and ARIA landmark roles, within a site build I often find myself having several instances where referring to role=”main” seems the most appropriate.
Sometimes it’s to a ‘core’ div that wraps multiple elements of content (which may be a few articles or several sections or both … or more). But sometimes I apply it to a single section.
The latter is one where a main element makes sense but that mental flow chart of which element fits becomes increasingly convoluted. A section works, but its the main section, so it should be main – but both are right so should I wrap my section in a main?
ARIA landmark roles float nicely and independently from the document outline model but should HTML rely on them to be the right tool?
I there are some further considerations to make before understanding if it’s the right way forward but if the Scooby Doo method isn’t too pesky to deduce main content by proxy then maybe it’ll stick.
@lewis
Browsers have started to implement semantics for the nav/section/header/footer/article/aside elements using ARIA roles where native platform accessibility APIs do not provide the roles (most cases for the new structural elements).
The WAI-ARIA 1.0 specification has a requirement that there SHOULD be no more than one role=main in a document. From a recent study that is understood and followed in aprox 95% of cases, which is a very good result for a markup pattern.
The main element also floats independently of the document outline (by design) as it does not have any effect on it. Not that there is any practical effect since the document outline algorithm is not implemented in any browser and there is not indication it will be.
The scooby doo algorithm relies upon a number of elements all being used AND being used correctly, for the main element to do its job it only requires the use of a single instance of an element
Pingback: On HTML5 and the proposed main element | Ian Devlin | My "Web" Blog | Scoop.it
Pingback: On HTML5 and the proposed main element | Ian Devlin | HTML5 in Higher Education | Scoop.it
Pingback: On HTML5 and the proposed main element | Ian Devlin | Rapid eLearning | Scoop.it
Pingback: The main element | Ian Devlin