There are currently no plans to implement the outline algorithm in Firefox AFAICS, so I'm OK with this change.

I agree, let's change it to match implementations.

(In reply to Dominic Mazzoni from comment #2)
> I agree, let's change it to match implementations.

Is that because you believe there's no potential benefit to it? No problem that it solves? Or just because pragmatically speaking you don't think vendors are going to implement it? Or you don't think the spec is clear enough about the requirements? Or something else?

Considering a document that does something like:

  <section><h1>Top-level section</h1>
  ...
      <section><h1>Nested Subsection</h1>
      ...
          <section><h1>Deeply nested sub-subsection</h1>

On the face of it, it seems to me that if AT handles those nested H1s as if they were at the same level (aria-level) as that top-level H1, that's not good UX.

Or am I mistaken and it's not actually a problem in practice for AT users if those H1s all get handled as being of the same heading level (aria-level)?

Here's my reasoning.

One reason is that I don't think it's always possible to nest sections properly, even when the web author has the best intentions. In order to achieve the desired layout, an author may make two sections siblings, even though one is a subsection of the other. In other cases an author might not have a choice because they're mashing up content from different sources to generate the final webpage - for example a news site may mix a hand-authored page template with article content generated by a CMS and then a commenting plug-in. It's just not always possible to make the resulting HTML nest properly when you do that.

Authors can place <h1>, <h2>, <h3> tags anywhere in the document. This creates a logical hierarchy that's often better than the actual hierarchy of the DOM, which has other constraints (due to mash-ups, layout issues, etc.). I consider this an advantage, not a disadvantage.

So I don't think there's anything wrong with a "flat" layout, like this:

<h1>Main title</h1>

<h2>Section One</h2>

Text

<h3>Subsection</h3>

Text

<h2>Section Two</h2>

Text

<h3>Subsection</h3>

Text

This works fine now - why break it?

It seems like following the spec as currently written would either break backward compatibility or increase complexity. Many screen readers currently announce "heading level 3" when they encounter an h3 element. Either they'd need to change their behavior to announce a level based on the nesting level (which would certainly degrade the experience of many webpages that aren't authored using nesting sections), or they'd have to handle native heading elements and ARIA headings separately, which seems like a needless complication.

Last, not a very important point but I'd note that AT can easily infer the nesting level by walking up the parent chain - so it's not critical that apps expose it. The "logical" heading level is more important to expose.

(In reply to Marco Zehe from comment #1)
> There are currently no plans to implement the outline algorithm in Firefox
> AFAICS, so I'm OK with this change.

I never looked at the issue but Steve and Hixie have different opinions on it. Also I'm not sure what benefits give the wording removal from the spec. I wouldn't support or not support it without some investigations.

(In reply to alexander surkov from comment #5)
> (In reply to Marco Zehe from comment #1)
> > There are currently no plans to implement the outline algorithm in Firefox
> > AFAICS, so I'm OK with this change.
> 
> I never looked at the issue but Steve and Hixie have different opinions on
> it. Also 

My opinion on the matter does not factor in to this, the opinion of implementers is what counts, or rather the intent to implement.

I'm not sure what benefits give the wording removal from the spec.
> I wouldn't support or not support it without some investigations.

please do investigate.

(In reply to alexander surkov from comment #5)
> (In reply to Marco Zehe from comment #1)
> > There are currently no plans to implement the outline algorithm in Firefox
> > AFAICS, so I'm OK with this change.
> 
> I never looked at the issue but Steve and Hixie have different opinions on
> it. Also I'm not sure what benefits give the wording removal from the spec.
> I wouldn't support or not support it without some investigations.

hi alex have you made any progress on looking into this?

I didn't. It sounds like complicated issue with no agreement. Do we have some dead lines?

(In reply to alexander surkov from comment #8)
> I didn't. It sounds like complicated issue with no agreement. Do we have
> some dead lines?

I think it makes sense for the HTML5.0 spec match reality i.e. reflect current and expected implementations for the foreseeable future, while the 5.1 spec can continue to reflect future, possible implementations. Unless implementers are going to move on implementing this in the near future, to date I have seen no indication.

thoughts?

(In reply to steve faulkner from comment #9)
> (In reply to alexander surkov from comment #8)
> > I didn't. It sounds like complicated issue with no agreement. Do we have
> > some dead lines?
> 
> I think it makes sense for the HTML5.0 spec match reality i.e. reflect
> current and expected implementations for the foreseeable future, while the
> 5.1 spec can continue to reflect future, possible implementations.

as long it's not lost and carefully moved to next spec then I don't mind at all.

> Unless
> implementers are going to move on implementing this in the near future, to
> date I have seen no indication.
> 
> thoughts?

agree, I just wouldn't want to lose some good ideas because nobody had a time to seriously consider them

(In reply to alexander surkov from comment #10)
> (In reply to steve faulkner from comment #9)
> > (In reply to alexander surkov from comment #8)
> > > I didn't. It sounds like complicated issue with no agreement. Do we have
> > > some dead lines?
> > 
> > I think it makes sense for the HTML5.0 spec match reality i.e. reflect
> > current and expected implementations for the foreseeable future, while the
> > 5.1 spec can continue to reflect future, possible implementations.
> 
> as long it's not lost and carefully moved to next spec then I don't mind at
> all.
> 
> > Unless
> > implementers are going to move on implementing this in the near future, to
> > date I have seen no indication.
> > 
> > thoughts?
> 
> agree, I just wouldn't want to lose some good ideas because nobody had a
> time to seriously consider them

it will remain here:

http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics

just modded here
http://www.w3.org/html/wg/drafts/html/CR/

My issue with this is mainly apathy. I don't think there is enough benefit to the outline depth computation of headings to warrant the implementation and subsequent author evangelism.

It is also specified in a way that ensures the new method is incompatible with previous authoring practices. Perhaps some spec changes could be made to prevent this from being backwards-incompatible. 

One spec change possibility to consider:

Only apply the outline depth to subsequent <h1> elements in a document. This way, the first <h1> is always level 1, and h2-h6 are unaffected. If an author wants to use the outline depth pattern, he can use <h1> for all heading, and all but the first would be  computed. If the author wants to intersperse headings of an explicit level, he can use h2-h6 unmodified, or h1 with an explicit aria-level value. This seems reasonably backwards compatible to me.

Thoughts?

(In reply to James Craig from comment #12)
> One spec change possibility to consider:
> 
> Only apply the outline depth to subsequent <h1> elements in a document. This
> way, the first <h1> is always level 1, and h2-h6 are unaffected. If an
> author wants to use the outline depth pattern, he can use <h1> for all
> heading, and all but the first would be  computed. If the author wants to
> intersperse headings of an explicit level, he can use h2-h6 unmodified, or
> h1 with an explicit aria-level value. This seems reasonably backwards
> compatible to me.
> 
> Thoughts?

Seems reasonable, on the face of it. It'd be interesting to get Hixie's opinion on whether he thinks it'd be feasible.

also see related bug:  outline depth calculation should not include empty sections https://www.w3.org/Bugs/Public/show_bug.cgi?id=25394

(In reply to James Craig from comment #12)
> My issue with this is mainly apathy. I don't think there is enough benefit
> to the outline depth computation of headings to warrant the implementation
> and subsequent author evangelism.

I totally agree with this. My principal view on this "beast" hasn't changed since you, Steve, explained it to me one or two CSUNs back.

Moreover, on Windows, we have basically two ways of exposure of web content: One, the more modern approach, is the exposure via accessibility APIs like IAccessible2 (Firefox and somewhat Chrome) and UI Automation (IE 10 and above). The other one is the exposure via what we call ISImpleDOM, which is the method used by JAWS, Window-Eyes, and even NVDA in IE (all versions), and by JAWS and WE at least in Firefox, and it basically means that screen readers do their own HTML interpretation and only use MSAA as sort of a basic pointer mechanism.
While, in theory, the exposure could be governed by the browser through mechanism one, and screen readers like NVDA, Orca, Firefox OS and Firefox for Android, would immediately get it, everyone using method 2 would have to implement the algorithm themselves to deal with the spec, and possibly spec differences. If you want one possible result of this, install JAWS 13 or 14, not 15, and test out your outline algorithm. Have fun with heading level 4711. :-)
So in addition to evangelizing this monster to web developers, which would be hard enough in itself, we'd have to explain a possible situation where the same code gives totally different results in screen readers. An h2 within a section is in scenario 1 turned into a heading 4711 correctly, whereas in scenario 2, due to lack of implementation, it is still an h2.
And no, I don't think even aria-level will mittigate this situation, because for that, the ARIA spec needs to be properly implemented, too.

> Only apply the outline depth to subsequent <h1> elements in a document. This
> way, the first <h1> is always level 1, and h2-h6 are unaffected. If an
> author wants to use the outline depth pattern, he can use <h1> for all
> heading, and all but the first would be  computed. If the author wants to
> intersperse headings of an explicit level, he can use h2-h6 unmodified, or
> h1 with an explicit aria-level value. This seems reasonably backwards
> compatible to me.

OK, my brain is already starting to form knots by just thinking about in how many ways this whole thing will go wrong in the wild.

In my opinion, this outline algorithm idea has so many unanswered questions and pitfalls that hardly any web developer will bother caring.

related browser bugs:
chrome https://code.google.com/p/chromium/issues/detail?id=365070
firefox https://bugzilla.mozilla.org/show_bug.cgi?id=998590
webkit https://bugs.webkit.org/show_bug.cgi?id=131920
IE http://connect.microsoft.com/IE/feedback/details/856898/expose-output-of-html5-outline-algorithm-as-a-dom-method

NV Access at this time has no plans to implement this. I tend to agree with pretty much all comments in favor of bringing things back to reality. The difference between outline and explicit level is just too big. To add to Dom's point about articles and pages pulling from various sources, Wordpress is a killer for this one. Especially with the way a lot of plugins and themes work. In absolute theoretical terms though I do quite strongly support the outline idea. There are obviously benefits  not just to screen reader navigation but to document parsing, transforming and table of contents generation. But, we must live with the past. We'll need some very strict rules around where this can safely be used. I.e. new elements or manditory attributes at the top of any subtree in a page that wishes to use the outline levels.

In my opinion, the only clean way forward for the outline algorithm is this:

1. Leave h1 to h6 alone as they always were. h1 through h6 are always that regardless of what they are nested in.

2. Introduce a new element named "heading" or the like that is the only element participating in the outline algorithm. it gets a level of 1 by default, and a level of greater than 1 depending on which section elements it is nested in. So a section heading gets a level of 2, a section section heading gets a level of 3 etc. And the calculation of the levels is the sole responsibility of the browser, indicating the calculated level as an implicit aria-level attribute. Styling could then be based off the section nesting or the proposed DOM attribute that would correspond to implicit aria-level.

This is the only way where there is a clean choice for web developers: Use the limited 1 to 6 heading levels, or choose a more free and modern way of structuring documents, and the browser takes care of communicating the level to assistive technologies.
Of course, the problem of ATs that use ISimpleDOM doesn't get solved by this, but the way forward is still cleaner, since they'd have to learn about the new heading element (or whatever it's called) anyway.

Feel free to take this under advisement in whichever channel you like.

I'd like to better understand some of the complaints here.

Dominic Mazzoni:
> I don't think it's always possible to nest sections properly

Perhaps (do you have an example?). But it's also possible to lose the game with numbered headings, especially when content is included from elsewhere. As an include author I decide "hmm, well, I'm probably not going to be top-level, so I'll start at h2". With sections I can start at h1, and the includer can place that in a section (or not) and the outline works.

Dominic Mazzoni:
> In order to achieve the desired layout, an author may make two sections siblings

To achieve a desired style, the author may make what should logically be an <h3> an <h1>. I don't think this is a relevant argument. If authors use semantic elements purely for visual formatting, the semantic game is over.

Dominic Mazzoni:
> Either they'd need to change their behavior to announce a level based on the nesting level (which would certainly degrade the experience of many webpages that aren't authored using nesting sections)

I thought sites authored without sectioning elements would be entirely backwards compatible (if not, they should be). What markup without sectioning elements breaks in the model?

steve faulkner:
> I think it makes sense for the HTML5.0 spec match reality… while the 5.1 spec can continue to reflect future, possible implementations.

This means the outline model becomes backwards compatible, which is a no-go. The new outline model was introduced with sectioning elements, we shouldn't have one without the other.

James Craig:
> My issue with this is mainly apathy. I don't think there is enough benefit to the outline depth computation of headings to warrant the implementation and subsequent author evangelism.

But evangelism has already happened, and people are already using it. Or is there a hunch here that developers aren't using sections + h1? If so, that hunch must be backed up by evidence.

Marco Zehe:
> If you want one possible result of this, install JAWS 13 or 14, not 15, and test out your outline algorithm. Have fun with heading level 4711.

Assuming that JAWS has correctly implemented the outline, what code generates heading level 4711?

Browsers should adopt the outline at the AT level. This paves the way for exposing this via the DOM. If the outline breaks backwards compatibility (sites without sectioning elements), we need to fix that. If authors are mixing outline models in a way that breaks the web, we need data for that.

> steve faulkner:
> > I think it makes sense for the HTML5.0 spec match reality… while the 5.1 spec can continue to reflect future, possible implementations.
> 
> This means the outline model becomes backwards compatible, which is a no-go.
> The new outline model was introduced with sectioning elements, we shouldn't
> have one without the other.


you may be misunderstanding, currently all browsers that implement acc API semantics for headings implement:

h1 role=heading level=1
...

h6 role=heading level=6

The HTML5.0 CR spec is meant to reflect interoperable implementations, thus the dropping features that don't currently have interop implementations (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24812). 

It has been agreed that the outline algorithm (http://www.w3.org/html/wg/drafts/html/master/sections.html#outlines) does not have any browser interop requirements and therefore will stay in 5.0 and live on in 5.1. The requirements to implement the separate acc layer part has no interop implementations and is the subject of this bug. If the acc layer part gets interop implementations before HTML 5.0 becomes a rec then it will not be removed, if not it will. It will remain in 5.1 awaiting further discussion/ changes/implementation.

(In reply to Jake Archibald from comment #19)
> Marco Zehe:
> > If you want one possible result of this, install JAWS 13 or 14, not 15, and test out your outline algorithm. Have fun with heading level 4711.
> 
> Assuming that JAWS has correctly implemented the outline, what code
> generates heading level 4711?

The "correct implementation" bit was the problem. Due to either a bug or misunderstanding of the spec or whatever, it was very easy to get to ridiculously high heading levels by just nesting an h6 into 5 levels of sections, for example. Anyway this was so screwed up that Freedom Scientific pulled it in JAWS 15 and went back to using h1 through h6 as they always were, ignoring section nesting. And thus far, that was the only "implementation" of the accessibility side of that outline algorithm in existence.

The number 4711 was meant to symbolize "arbitrary". It actually refers to some smelly aftershave and perfume brand.

(In reply to Jake Archibald from comment #19)
James Craig:
>> My issue with this is mainly apathy. I don't think there is enough benefit to >>the outline depth computation of headings to warrant the implementation and >>subsequent author evangelism.

>But evangelism has already happened, and people are already using it. Or is >there a hunch here that developers aren't using sections + h1? If so, that hunch >must be backed up by evidence.

yes it has and we have already had to mitigate such evangelism in regards to use of <section> as a replacement for <div> by changing  advice in the HTML spec :-)

Some developers are, some aren't, see the example pages i provided:

some data 252 HTML5 pages using the <section> element
http://www.html5accessibility.com/HTML5data/section/section.html

some data: 170 HTML5 pages that use the <article> element http://www.html5accessibility.com/HTML5data/article/index.html


there is raw data available at http://webdevdata.org/

> that hunch >must be backed up by evidence.

the hunch that the implementation of the outline algo in the acc layer only will be a win for users also needs to be backed up by evidence.

Marco has explained in Comment 15 some of the limitations of the acc layer only approach i.e. the DOM is used as the acc layer in some circumstances.

(In reply to James Craig from comment #12)
> 
> It is also specified in a way that ensures the new method is incompatible
> with previous authoring practices. 

If the correct (old style) heading structure is used in conjunction with the sectioning it is backwards and forwards compat, the evangelizing of all h1's is the issue, which I have tried to mitigate by modding the advice in the spec.

steve faulkner:
> The HTML5.0 CR spec is meant to reflect interoperable implementations

Ahh ok, but if outlining is dropped, then sectioning elements must also be dropped as they're part of that feature.

> we have already had to mitigate such evangelism in regards to use of <section> as a replacement for <div> by changing advice in the HTML spec :-)

Then that was incorrect evangelism. It's certainly not what I teach or follow. These kinds of errors will also happen. It happened with tables, it still happens with dl & forms etc etc.

> the hunch that the implementation of the outline algo in the acc layer only will be a win for users also needs to be backed up by evidence.

Comment 15 shows this, right? Not all ATs will benefit, but some will. And if ATs are struggling with the algorithm, they'll be able to avoid creating a buggy implementation and use the acc layer instead.

Also, it paves the way to the dom methods you propose.

after discussion on IRC http://krijnhoetmer.nl/irc-logs/whatwg/20140422#l-379

propose that the 5.0 CR spec changes to specifying 'no role' [1] for headings which leaves the door open for non breaking implementation of outline if it happens in 5.1 time frame

[1] http://www.w3.org/html/wg/drafts/html/master/dom.html#concept-role-none

(In reply to Jake Archibald from comment #24)
> steve faulkner:
> > The HTML5.0 CR spec is meant to reflect interoperable implementations
> 
> Ahh ok, but if outlining is dropped, then sectioning elements must also be
> dropped as they're part of that feature.

no, they have semantics (actually implemented see http://www.html5accessibility.com/) that are independent of their use in the outline algo. Also as stated, the algorithm is used by third party software (there is a epub XSLT implementation for example)


>> we have already had to mitigate such evangelism in regards to use of <section> >>as a replacement for <div> by changing advice in the HTML spec :-)

>Then that was incorrect evangelism. It's certainly not what I teach or follow. >These kinds of errors will also happen. It happened with tables, it still >happens with dl & forms etc etc.

the HTML spec was unclear, it has been edited to make it clearer http://www.w3.org/html/wg/drafts/html/master/sections.html#the-section-element

>Comment 15 shows this, right? Not all ATs will benefit, but some will. And if >ATs are struggling with the algorithm, they'll be able to avoid creating a buggy >implementation and use the acc layer instead.

From what Marco has stated the only AT to benefit would be VoiceOver as at is the only AT (I know) that uses the platform acc APIs exclusively. Suggest re-reading Comment 15  

"The other one is the exposure via what we call ISImpleDOM, which is the method used by JAWS, Window-Eyes, and even NVDA in IE (all versions), and by JAWS and WE at least in Firefox, and it basically means that screen readers do their own HTML interpretation and only use MSAA as sort of a basic pointer mechanism.
While, in theory, the exposure could be governed by the browser through mechanism one, and screen readers like NVDA, Orca, Firefox OS and Firefox for Android, would immediately get it, everyone using method 2 would have to implement the algorithm themselves to deal with the spec"

(In reply to Marco Zehe from comment #18)
> In my opinion, the only clean way forward for the outline algorithm is this:
> 
> 1. Leave h1 to h6 alone as they always were. h1 through h6 are always that
> regardless of what they are nested in.
> 
> 2. Introduce a new element named "heading" or the like that is the only
> element participating in the outline algorithm. it gets a level of 1 by
> default, and a level of greater than 1 depending on which section elements
> it is nested in. So a section heading gets a level of 2, a section section
> heading gets a level of 3 etc. And the calculation of the levels is the sole
> responsibility of the browser, indicating the calculated level as an
> implicit aria-level attribute. Styling could then be based off the section
> nesting or the proposed DOM attribute that would correspond to implicit
> aria-level.

I find the suggestion reasonable, alternatively section element could have @heading attribute. It doesn't address the relation between h1-h6 and section elements though.

(In reply to alexander surkov from comment #27)
> I find the suggestion reasonable, alternatively section element could have
> @heading attribute.

The problem with that is that section is acontainer, and heading can also become one if it contains formattings like "strong" or such. We wouldn't want to take that away from web developers. So I proposed a stand-alone new element instead of an attribute.

> It doesn't address the relation between h1-h6 and section elements though.

That's why I wrote:

> > 1. Leave h1 to h6 alone as they always were. h1 through h6 are always that
> > regardless of what they are nested in.

So even if h1 through h6 are nested within section elements, they will always be h1 through h6 for screen readers and not participate in any outline algorithm calculation. Clean separation between the "old" way (h1 through h6 usage, manual outline by the author), and the "new" way (section + new heading element, levels calculated by user agent).

(In reply to steve faulkner from comment #23)
> (In reply to James Craig from comment #12)
> > 
> > It is also specified in a way that ensures the new method is incompatible
> > with previous authoring practices. 
> 
> If the correct (old style) heading structure is used in conjunction with the
> sectioning it is backwards and forwards compat, the evangelizing of all h1's
> is the issue, which I have tried to mitigate by modding the advice in the
> spec.

Potentially, but depending on how the author crafted it, there may be different heading levels exposed to different platforms or in different browsers, or when the section was included using a different manner. 

The validator may be able to mitigate some of this by determining the section level computation and then throwing a warning if it doesn't match up with the expectation, but again, this is more work than it's worth. A perfectly nested heading structure is nice-to have, but an incorrectly nested heading structure doesn't cause any harm to any real category of user that I know of.

I think the algorithm is suffering from a more serious issue in that it is not taking into account user context within the page resulting of the use of landmarks whether they be native HTML elements defined in terms of WAI-ARIA landmarks or WAI-ARIA landmarks themselves. 

The outline algorithm needs to have a reset in each of these context. IOW you need to start at the highest heading level in these regions and work your way through the content contained within the landmark. 

You cannot have an accurate algorithm to produce a TOC if involves computation across landmark regions vs. within those regions. 

To do this work I believe it should be done for HTML 5.1 or later as there is not enough runway.

(In reply to Marco Zehe from comment #18)
> In my opinion, the only clean way forward for the outline algorithm is this:
> 
> 1. Leave h1 to h6 alone as they always were. h1 through h6 are always that
> regardless of what they are nested in.
> 
> 2. Introduce a new element named "heading" or the like that is the only
> element participating in the outline algorithm. it gets a level of 1 by
> default, and a level of greater than 1 depending on which section elements
> it is nested in. So a section heading gets a level of 2, a section section
> heading gets a level of 3 etc. And the calculation of the levels is the sole
> responsibility of the browser, indicating the calculated level as an
> implicit aria-level attribute. Styling could then be based off the section
> nesting or the proposed DOM attribute that would correspond to implicit
> aria-level.
> 
> Feel free to take this under advisement in whichever channel you like.

Hey marco, 

have realized your suggestion in the form of a custom element
https://github.com/ThePacielloGroup/w3c-heading/blob/gh-pages/README.md has details and working demo.

removed CR keyword as the mappings have been modded for 5.0 CR https://github.com/w3c/html/commit/9c8cb199f978fcf8f7122e4f1a84b24fac5c65f7

note:

w3c-heading has morphed into html5-h 
https://github.com/ThePacielloGroup/html5-h

ongoing discussion of the custom element is happening : http://discourse.specifiction.org/t/html5-h-custom-element/438

moved to HTML acc mapping spec https://www.w3.org/Bugs/Public/show_bug.cgi?id=28767