Suggest adding a warning about outline algorithm #83
Comments
|
I kind of feel we should either leave as-is or just remove the outline algorithm altogether... |
|
An outline algorithm probably makes sense to keep around, given outlining is used in some sense in most screenreaders, as far as I'm aware. That said, may well make sense to drop the current one (and the semantics that go along with it...). |
|
The algorithm just describes the semantics of the elements. If the tools aren't supporting the semantics, they're buggy and should be fixed. Changing the semantics would be a pretty drastic change to the spec, especially as people have been using these elements for years. We can't just remove the outline algorithm, either. We need something to define the semantics of these elements. Even if we were to say that tools should ignore the semantics and just use the h1-h6 elements in the naive flat way (ignoring tree structure, as if we were back in the 90s), you'd still need the algorithm to be able to define the authoring conformance criteria (so that conforming documents only used h1-h6 in a manner consistent with the semantics). That's pretty silly though. The right solution is just to fix the tools. |
|
@Hixie, when you say "tools," do you include user agents and their accessibility bindings? At some point we cannot claim that user agents are broken. They are instead rejecting our change request. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003 contains comments from both Firefox and Chrome accessibility developers explicitly rejecting the idea of implementing the outline algorithm in their accessibility bindings. It also outlines the history of JAWS removing their support. Although their reasoning may be wrong, it doesn't seem fruitful at this point to challenge them. I think it would be better for the semantics in the spec to match the semantics already exposed through accessibility bindings in implementations. People have been using these elements for years, but either (a) they have been using them in a way supported by user agents, which contradicts the spec; or (b) they have been using them in the way specified, which means their content is broken in current user agents (for users which count on those accessibility bindings). Neither of these seem good. |
|
My last message wasn't entirely clear. I agree with @gsnedders and phrasing this as "removing the outline algorithm" was incorrect. Rather, we should update the outline algorithm to reflect implementations. In some ways this is a "revert" of the "change request" that proposed a sectioning-based outline algorithm; it differs only in degree from a4313d3, which was a revert of the change request 78f1994 to simplify selector case-sensitivity matching rules. |
|
If we want to require that authors use h1-h6 instead of being able to do the XHTML-style <h1>-everywhere, then we need two outline algorithms: one that describes how user agents are to act, and one that describes the restrictions that authors have to follow in order for their h1-h6 headers to not contradict the sectioning semantics. (And maybe a third one, that describes how an authoring tool could convert from the saner one-heading-element style to the legacy h1-h6 style for UAs.) But IMHO that's a poor place to be in. I don't really see why accessibility tools couldn't expose the real semantics here. It doesn't require a complex algorithm (you only need "previous", "next", and "up" to be able to navigate the tree, and walking around the tree that way is pretty straight-forward as far as I can tell). Accessibility tools are notoriously slow about catching up to implementing new features, this algorithm is not that old by their time scales. (I mean, they still haven't implemented stuff from the 90s correctly, even though there's obvious usability gains to be had by doing so.) |
|
Can you explain why you need two outline algorithms? Authors would use the sectioning elements the same way they are exposed in accessibility technologies: just like divs. |
|
That ignores that fact that both Firefox and Chrome have explicitly refused to support it, and that algorithm is hella old by their standards (it's what, seven years old now?). I think the battle's lost at this point, sadly. I don't have strong opinions on what we should do, but the spec as it stands now is fiction and will remain fiction. Your argument that they should implement it because they're buggy per spec is trying to oblige behaviour by spec, and we know that's a fallacy when everyone is refusing to implement it. |
|
@domenic Consider the following: <h1>A</h1>
<section>
<p>aaa
<h1>B</h1>
<p>bbb
</section>
<p>bbbWhat are the sections in that document? If the <section> element doesn't align with that answer, then what are the semantics of <section>? @gsnedders I don't think the battle's been fought. Any time I've seen people say they don't want to do it (e.g. in the bug above) the reasons they've given don't actually fit the facts (e.g. I've heard complaints that it would be prohibitively expensive, but that's only if you recomputed the entire tree, which as far as I can tell is unnecessary). But in any case in my comment above I gave two paths: one that I think is the right path, and another path for the case where we give up on making accessibility tools give good results. We could go down the second path, certainly. It's not just removing text from the spec, though, as I described above. |
|
My understanding is that as implemented section has no semantics, just like div. I am not sure that implementations have a concept of "sections of a document" as much as they have an accessibility tree plus an outline tree which consists of links into nodes in the accessibility tree. But I am not sure on that; presumably @stevefaulkner has done the research there. |
|
I'm not sure what it would mean for <section> to have "implemented" semantics. Semantics by their very nature are about the meaning of the elements, which is something for humans. It's how you get maintainable documents that different people who have never met can approach and understand. |
|
Yeah, I guess either you keep the current outline algorithm, or you obsolete |
|
Is the idea to keep the current outline algorithm but the output of the algorithm is only something that exists in authors' minds? If so I'd be fine moving it to some section with a preface like "If you want to assemble a mental outline, that does not match that displayed by screen readers, follow the following algorithm: ... NOTE: authors are advised not to author documents that produce outlines catering to this algorithm, but instead author documents catering to accessibility tools, which follow the algorithm in $cross-link-here, according to the priority of constituencies (users over authors)" But that seems kind of pointless. |
|
It all depends on whether user agents will implement these elements. If they don't, we should scrap them and the outline algorithm can be simplified to what is supported. If they do, or we expect them to within the next five years or so, it might be worth waiting a little longer. |
|
Hmm, to be clear, what does "implement these elements" mean? They implement them as HTMLElement instead of HTMLUnknownElement, but they do not implement the accessibility mapping implied by the current outline algorithm, and as discussed up-thread at least a couple have publicly stated they are not planning to do so. (Are those the only two relevant requirements on implementations, or am I missing some?) |
|
There are some styling and parser requirements too. And there are some speculative CSS features that would build upon the outline algorithm. We would have to check. But styling and outline would be the most important aspects. |
|
Ah right, thanks for pointing those out. Also, when you say "obsolete |
|
Perhaps it would end up like |
|
@domenic section is mapped to a region role in browsers, section is not exposed in the aural UI unless it has an accessible name. There are 2 document scope navigation methods implemented across AT:
Implementation of accessibility layer semantics for html element landmarks and h1-h6 is complete in chrome, firefox, Safari Data on the utilisation of each can be found in webaim screen reader surveys |
|
The reason for the warning is so authors are not mislead into thinking that use of sectioning elements actually does anything for users who consume heading semantics to make sense of and navigate document content. |
annevk
added
removal/deprecation
|
Adding a similar warning makes most sense, IMO, at least until the Outline Algorithm starts being more adopted. Many authors most likely think that (correctly) placing a |
|
I do quite a bit of accessibility training and regularly come across developers who think they should just use H1s (they don't always know about sectioning either). |
|
I would love to help campaign UAs to use it. It would make everyone's lives (developers and users) if they did. |
|
Has a web developer, I also would be really happy if the outline worked as intended with sectioning elements, at last. Working with only |
|
Some Twitter discussion reminded me about this neglected issue. I wanted to summarize the action items here:
Potential future work:
All that said, this isn't that high on my priority list, or my employer's. If someone does have the time to devote to this, I'd be happy to help review patches. |
While there is normative requirement for UAs to implement the outline |
|
I agree with much of the comments fro @Hixie and @annevk in this thread, especially the comment from @Hixie that “We can't just remove the outline algorithm” without needing to make other changes as a consequence, and the question “Yeah, I guess either you keep the current outline algorithm, or you obsolete But all that said, I have over the years learned a huge amount of things from @stevefaulkner around the problems that some things in the spec cause for AT users, and I think others should read his comments here very carefully. We’re here to solve existing real problems for real users—not to hypothetically solve problems for some of them if we could somehow just get browser implementors to see things our way and implement what we’ve specced, or get AT vendors to fix their horribly broken/buggy tools. In that spirit I agree very strongly with the implicit goals in the latest comment that @domenic posted and with his concrete suggestions there about how to get progress here. See the related IRC discussion. Some ways I could help with this might be:
As far as the second item above, I have already implemented experimental support in the checker for reporting (mis)use of H1 as anything other than a top-level head, and that’s been deployed in the checker for quite a long time now, and I think it’s been helping. But I’d like to help more if I can. I want to make the HTML checker be a tool that helps developers avoid making uninformed authoring choices that are going to cause problems in practice for real users. |
|
The main misconception seems to be that sectioning nodes (headings, section elements, etc.) can be treated like any other element: As being isolated and independent from one another. That however is not the case:
Sure, under certain conditions you will be consistent. The problem with that is however: You won't be able to guarantee consistency. That is, under different conditions, you will still be in conflict. And that will keep us from having a Semantic Web. These kind of issues will keep nagging you over and over again. Simply because mathematics is the only language computers understand. And because mathematics is what it is, it is "reality" that needs to change. The only thing you can do to finally solve our problem is to figure out how to properly deal with it. (But, you already made it pretty clear that there still is not enough interest for a proper solution.) |
This makes a number of fairly big changes: * Introduces a heading and heading level concept. * Replaces the outline algorithm with a document headings concept. * Requires document headings to not skip heading levels and start with heading level 1. * Introduces a :heading pseudo-class selector. * Introduces a :heading(level) functional pseudo-class selector. * Does away with the section concept (except insofar it's needed to influence the heading level of h1/hgroup). * Does away with sectioning roots. Tests: ... Fixes #83.
|
I've read the whole discussion around this issue and #3499 and I'm aware that many of the points I mention were already discussed. Yet I want to add my own perspective, which maybe someone will find useful. TL;DR
IssuesAfter reading proposal of fix in #3499, I noticed some potential issues. Breakage of existing conforming usage of sectioning elements and headingsSuch example was mentioned here before, but I'd like to return to it once more: <body>
<main>
<article>
<h1>Title of the page</h1>
</article>
</main>
</body>According to the model defined in #3499, I do not agree with the argumentation that authors shouldn't use the above markup as it is redundant. Even if we consider it redundant, it is still valid HTML. However I do not agree that it's redundant – and the new proposal seems to agree with me on that. If it was redundant, the result of calculating heading level in such structure would be the same as for the following one: <body>
<main>
<h1>Title of the page</h1>
</main>
</body>Yet it is not the same, as the second one produces a level 1 heading. So there is a slight difference in semantics. As a spec states, What's more, such <body>
<main>
<article>
<h1>Title of the page</h1>
</article>
<section>
<h2>Comments</h2>
</section>
</main>
</body>In such case there are two independent sections inside I'm wondering how popular is the above pattern. I often find it on sites that use WordPress (including mine), as default themes use it. I'm afraid that the change in treating CompatibilityThe new heading level algorithm have sense only if there is enough support for it. However there will be a transition period between putting the algorithm into the specification and implementing it in browsers. And during that period websites need polyfiils not to appear broken in unsupported environments. However gaining support can take years, as statistics show that IE is still very popular among AT users. Browsers are only one side of the problem, but it is rather easy to imagine that users use also outdated versions of screen readers. In such cases polyfills will be needed for years or even longer. And we should also consider the possibility that some browsers won't implement the algorithm, which happened already with several HTML features, e.g. Yet there is even a bigger compatibility issue. As I mentioned in the previous point, many sites that have now correct heading levels will become incorrect when the new algorithm is introduced. And that would require action from webmasters to update their sites to the new rules. However many sites can be not actively maintained, still containing much valuable content. They will become less accessible to the users due to the change in the specification. It's very similar situation to Smooshgate, when the normative change would break the web (although we can argue if the case here would really break it or "just" make it less accessible). Breakage of expectationsFor years numbers in
The new proposal breaks this expectation and ties heading's level directly with the new algorithm. There are tons of tutorials that explain headings outline using their rank, e.g. MDN's one. Changing it would make most of these materials obsolete in the best scenario and harmful to the accessibility in the worst one. Webdevs creating their sites using advices from such tutorials would create websites that are suboptimal for some groups of users. What's even more confusing is the fact that the special treatment is reserved only to the one of the headings – the top-level one. Due to that there can be a lot of incorrect websites due to assumption that all headings participate in the new algorithm. How I perceive headingsBefore I describe my vision of ideal headings algorithm, I'd like to quickly describe how I personally use headings. Some time ago I developed (discovered?) something I call Headings First Principle (HFP). The rule is simple: divide the page into sections using headings, e.g. <body>
<h1>Title of the article</h1>
<h2>Subsection 1</h2>
<h2>Subsection 2</h2>
<h3>Subsubsection 2.1</h3>
<h2>Subsection 3</h2>
</body>After dividing page in such way, I add sectioning elements to make the division explicit: <body>
<main>
<article>
<h1>Title of the article</h1>
<section>
<h2>Subsection 1</h2>
</section>
<section>
<h2>Subsection 2</h2>
<section>
<h3>Subsubsection 2.1</h3>
</section>
</section>
<section>
<h2>Subsection 3</h2>
</section>
</article>
</main>
</body>This way I'm sure that all my headings and sections point to the same portions of the site. It is clear that in the above model sectioning content is somehow redundant and headings alone can be used to structure the site. However similar arguments were raised against All of my proposals are based on the above understanding of headings and sections. Keep the current status quoIn my opinion headings definition should be kept as is, with the association between number in heading name and its heading level. This solution de facto fixes all of the above mentioned issues. The only downside of this approach is the fact that it won't fix the pages that use outline algorithm. However I'm not sure if the usage of this algorithm is so big that would overweight the breakage of mentioned WordPress sites. There is also issue with default styling of headings inside sections, due to rendering guidelines, however I do not find it critical. First of all, whole rendering section is not, strictly speaking, normative:
Secondly, thanks to cascade order, this styling can be overridden with any heading styling, making it basically a non-issue (as only unstyled pages will be hit by the UA's rules). Reconsider adding
|
|
At TPAC HTML/ARIA joint meeting, it's suggested that we should discuss this issue with the APA WG. |
This makes a number of fairly big changes: * Introduces a heading and heading level concept. * Replaces the outline algorithm with a document headings concept. * Requires document headings to not skip heading levels and start with heading level 1. * Introduces a :heading pseudo-class selector. * Introduces a :heading(level) functional pseudo-class selector. * Does away with the section concept (except insofar it's needed to influence the heading level of h1/hgroup). * Does away with sectioning roots. Tests: ... Fixes #83.
|
Unless I've missed something, it does not look like the outline algorithm is any closer to resolution or replacement than it was two years ago. Until such time as this changes, please can the algorithm be removed for lack of implementation, or the warning be added? |
|
Another outside perspective on the previously mentioned example: <body>
<main>
<article>
<h1>Title of the page</h1>
</article>
<section>
<h2>Comments</h2>
</section>
</main>
</body>
Technically you could resolve that with some nastiness using a conceptual <body>
<main headedby="article_heading">
<article>
<h1 id="article_heading">Title of the page</h1>
</article>
<section>
<h2>Comments</h2>
</section>
</main>
</body>Technically the It's not like such a thing would be the only case where explicit attribute markup could perform shifting in things like the structure of the accessibility tree. (E.g. |
|
@annevk and @domenic, I could use your help to resolve an objection raised against publishing the Jan 2021 HTML Review Draft as W3C CR. I understand that finding and implementing a solution for the problem that the outline algorithm was intended to solve is not a small thing, despite welcome efforts made by @annevk on a polyfil/prototype. In the interests of taking a small step in a good direction, would you be willing to accept a PR that added a warning to the HTML Standard, to let readers know that the outline algorithm presently has no implementations? Thanks. |
|
No, I don't think that's a good solution. First of all, it's not correct; the outline algorithm has plenty of implementations in various tools. The problem is about the mismatch with accessibility tech, not about lack of implementations. Second of all, an internally-incoherent document is not desirable, as stated back in 2015. |
Mistmatch of AT, or mismatch of what user agents expose programmatically to those ATs? Implemented, but broken at the UA end? |
What tools? In a quick test, web browsers still don't expose it. Using the third block of sample code from 4.3.11 Headings and sections, I made a sample to quickly test: https://codepen.io/aardrian/pen/PoEQjRa The "debug" version with no Codepen wrappers: https://cdpn.io/pen/debug/PoEQjRa That WHATWG example nests When I visit that in Edge, Chrome, Firefox, or Safari and explore the accessibility tree and document structure, none of those browsers exposes any of the Sure, visually the text is smaller when the
In this case, the lack of implementation in Edge, Chrome, Firefox, and Safari precludes any accessibility tech. So what plenty of various tools, specifically, implement the outline algorithm? Then we can explore if or how there is a mismatch with assistive technologies. |
|
Thank you @domenic
It does have implementations in tools other than browser engines, yes. As I understand it however, the expectation here is that it is browser engine implementations that matter, hence the position taken on the decision not to accept changes to the ruby family of elements. If implementation in tools other than browser engines meets the WHATWG benchmark, it would help to have that clearly stated.
The problem is that although there is a certain amount of cosmetic support in browser UA stylesheets, there is no browser implementation that exposes the semantics of the revised outline. If the revised semantics are not exposed to the accessibility API, assistive tech cannot query the information without scraping the DOM, and I trust you're not suggesting we return to those days again. If you consider changes to the UA stylesheet to be an implementation that is fit for purpose based on the intent of the outline algorithm, it would help to have that clearly stated. Otherwise, it would help to know if any implementors are intending to put time and effort into implementing the outline algorithm in a way that supports its semantics in ways that assistive tech can utilise, and to do so within an established and reasonable timeframe. Thank you. |
|
To be clear, we should 100% revise the spec's outline to match accessibility technology's view of the outline. That has been the proposed plan since 2015, and has only been lacking people to do the work. That's the best path forward to resolve the issue. I could go into depths on how conformance classes work, what the spec currently does and does not mandate with regard to browsers, authors, ATs, etc., and how that intersects with the WHATWG working mode requirements. But none of that really matters, because the path forward is for someone to edit the spec in the way that was outlined 7 years ago. |
Isn’t that what #3499 is? |
Unfortunately no. Throughout the history of this issue, there have been essentially three outline algorithms under consideration:
So #3499 was an attempt to introduce a third alternative outline algorithm, along with a couple of new CSS features. It was not an attempt to align HTML and HTML-AAM. My understanding is that #3499 is mostly abandoned, per https://groups.google.com/g/mozilla.dev.platform/c/SdnMKYwWxzU/m/U-v_b8c2BwAJ. @jakearchibald still seems to think it was somewhat salvageable, per the discussions in https://bugzilla.mozilla.org/show_bug.cgi?id=1590366, but I think the implementation appetite has waned, and we should go back to the 2015 plan. |
and others
Currently the HTML standard does not provide any advice in regards to the outline algorithm not being implemented, This has lead to some developers believing that the outline algorithm has an effect in browsers and assitive technology which it does not. THis can lead to developers using markup patterns that don't convey document structure. Suggest adding a warning, for example this is the warning in the W3C HTML spec
The text was updated successfully, but these errors were encountered: