W3C home > Mailing lists > Public > public-html@w3.org > January 2015

Re: About the main element

From: VILAIN Dominique <dominique.vilain@hepl.be>
Date: Thu, 29 Jan 2015 12:41:09 +0000
To: "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <84160F4D-A09B-4FC9-AA55-BCA422520E4B@hepl.be>
Hi Léonie and thank you for your answer.

I must admit, though, that i’m a bit frustrated and i think it’s my fault. I have to better describe the context in which my question makes sense.

Most of the time, when i make websites, i use HTML 4.01 Strict. My choice is motivated by accessibility concerns essentially and especially by the fact that i am well aware that many assistive technologies have relatively poor support of a number of the many features of HTML5, particularly the Outline. In many cases, i don’t even need HTML5 features, so why bother managing compatibility and accessibility issues? Regarding the outline, I know that there are alternative strategies than the headings list, of course, to browse the content but as i referenced and also experienced working with blind people, not all users are aware that it is possible to navigate with another strategy than the one they are used to. And not all Assistive tools support Landmarks navigation. When building websites, shouldn’t we try to be compatible with as much strategies as possible? Isn’t it, in some way, a bit of the essence of our jobs to embrace as much as possible the diversity of users particularities ?

But I’m not only some guy building websites.  I’m also, and essentially,  a teacher for 12 years. I teach Web Technologies in a bachelor’s degree in computer graphics, in Belgium. Since the beginning i’ve tried to be an advocate for best practices and W3C standards when i speak with my students and my colleagues.

Till last year, because I and my colleagues care much about accessibility, we were still using HTML 4 / XHTML 1 as a reference for our courses in the first year. I was introducing HTML5 and ARIA in the third year for advanced students. This year, we’ve decided to take the step towards HTML5 from the first year, mainly because it makes no sense to continue to put on the market students who have learned an "old" standard like HTML 4 when the companies that will hire them require HTML5.

So now, we teach HTML5 and we want to do it like it’s designed. We believe in Web Standards, we are strong advocates to the W3C’s cause, and furthermore, it’s hard to predict how things will be in three years, when the students of the actual first year will leave school to find a job. So we try to teach Web Standards as close as possible to their definitions but we also comment the problems it can generate to follow them religiously, and we try to find the best compromises to make it really work in the real world. We’ve also added ARIA to the list of contents we teach from the beginning in order to reduce the risks of producing badly accessible code.

So, that is the context of my question : Since the W3C specification describes an algorithm that User-Agents should use to outline the hierarchy of headings, we want to teach it. We try to do it with the idea that the heading strategy used in a document must be compliant with both HTML 4 and HTML5 outliners for accessibility reasons. Ideally, we encourage our students to target identical outlines in both algorithm. We can’t just tell our students : “Please forget what the specification says about the outline of HTML5 and its sectioning elements. Anyway, you won’t find any accessible technology nor regular User-Agents using it. Just continue to use the div elements and think about the headings the old way“. What credibility would Web Standards have if we did ? We have to find some compromise like always with Web technologies.

I don’t know if i really have a question after this explanation of my context. I hope i don’t cross a line in the use of this list explaining it. I think that the question of teaching Web Standards is closely linked to the elaboration of the specification, so I’ve allowed myself to do it. There is on one side the real world and on the other side, the ideal specification world. It has always been like that with Web Technologies, but being teachers, we have to find a way to provide reliable resources (i.e. the specifications) to our students, especially in the first year, as well as describe the extremely variable implementations. Generally, i keep those last considerations for the advanced students, in second and third year. But in the first year, we have a more academic, idealistic approach. It’s also a matter of time. Some of our students barely know how to use a computer and they have to learn HTML at a very slow rhythm, 4 hours a week, amongst many other things like Graphic Design, 3D, Video, etc. And thus, when i see the example mentioned before, about the “main” element, i feel worried that it could give our students (and more generally, any newbies) bad clues about an accessible and Standard compliant way to tag such a content.

To get back to the example, in my understanding, it’s useful to use sectioning elements when I want to impact the outline. If I don’t want to impact the outline, I use divs or any other grouping elements that doesn’t impact the outline. So in the example, if i don’t want to insert a new entry in the outline, i would probably use a div instead of a nav and I would probably add a navigation role to it. If i decide to use a sectioning element, i think that it’s better to explicitly describe it’s status for the outline, giving it a real heading rather than leaving such a poor information as "untitled section" in the outline.

So, your opinion means a lot. Coming from a member of the Piacello Group who is also an Assistive Technology User, i must say that your answer has a huge value and a strong impact. But it’s so frustrating, regarding that, (i am reformulating, please excuse me if i go too far from your intentions) to read that authors shouldn’t care about an important part of the specification just because the real world is not ready yet and that the examples provided in the specification can, in some way, create ambiguities, at least.


PS. Please excuse my poor english… I hope everything is understandable.

Le 26 janv. 2015 à 18:00, Léonie Watson <lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>> a écrit :

Dominique Vilain wrote:
"In my understanding, if there is a main element in a document, it’s the best candidate to own
the h1 tag. But what happens if some sectioning content comes before the main element ?
The HTML5 outliner deals quite well with it, but the HTML 4 outline becomes messy if we use
explicit heading in that sectioning content (which is desirable in my opinion). Thus, knowing
that the support of HTML5 is extremely variable regarding AT, what can authors do ? I guess
i know the answer for some time now since it’s not a new problem, but regarding the example
in the spec, i thought it could be interesting to collect several new opinions about it."

To the best of my knowledge no browsers or assistive technologies support the HTML5 outline algorithm. There is therefore no material difference in the experience for assistive technology users.

The HTML5 sectioning elements are accessibility supported in Firefox, Chrome and Opera, but either not implemented or not accessibility supported in IE11 [1]. Where those elements are supported they should map to their corresponding ARIA landmark roles [2].

For those screen readers that support landmarks, they provide a way of navigating through content that is complementary to heading navigation. It isn't necessary for an element (like the <nav>) to have an accessible name for this to be an effective navigation strategy, although where there are multiple instances of the same sectioning element on the page it can be a useful way to differentiate one from another [3].


[1] http://html5accessibility.com/

[2] http://www.w3.org/TR/wai-aria/roles#landmark_roles

[3] http://tink.uk/enhancing-aria-landmarks-with-aria-labelledby/

Senior Accessibility Engineer, TPG
@LeonieWatson @PacielloGroup

Received on Thursday, 29 January 2015 12:43:18 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:11 UTC