Are 'Headings' enough to pass 2.4.1: Bypass Blocks

[jake-abma]

Sufficient techniques for 2.4.1: Bypass Blocks is:

https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks#techniques

H69: Providing heading elements at the beginning of each section of content PDF9: Providing headings by marking content with heading tags in PDF documents

In the Understanding you can read Benefits:

Benefits When this Success Criterion is not satisfied, it may be difficult for people with some disabilities to reach the main content of a Web page quickly and easily:

- Screen reader users who visit several pages on the same site can avoid having to hear all heading graphics and dozens of navigation links on every page before the main content is spoken.

- People who use screen magnifiers do not have to search through the same headings or other blocks of information to find where the content begins each time they enter a new page.**

Indication only heading is not enough... even the reason to have 'other ways' (?!) like Landmarks etc...

But again, Heading are enough to pass... so the question is not if the rational is clear, if headings are sufficient, BUT, is are the Benefits not contradictory to the techniques proposed as sufficient?

[jake-abma]

ps. I also read "the same headings" but how to distinguish IF heading ARE implemented and sufficient?

[jake-abma]

(bottom line, is it correct I read: "it's very annoying and irritating to go through all heading for some people and the reason for this SC [to skip them], so please add headings and it is sufficient")

[detlevhfischer]

My take (for pages that have different structurally separate content sections such as nav, main, footer etc) would be that headings as the only way to bypass blocks would not pass 2.4.1 when the page merely has content headings - it would require explicit (often accessibly hidden) section headings ("navigation", "content", footer" or "sitemap") etc.

[jake-abma]

@detlevhfischer but it won't help, you still need to go through all headings to find them...

[stevefaulkner]

My take is that headings alone are not enough as heading navigation for keyboard only users is not accessibility supported.

the SC

A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

The mechanism is not available for keyboard only users.

[jake-abma]

and there's a lot more to them, are those names 'required'? Understood? clear where they need to come? Others not possible? like a small page where it does not matter that much? And what about the examples in the Techniques, they do not show this? Etc. etc.

[jake-abma]

@stevefaulkner so you agree / say the techniques for using Headings must be deleted from this SC?

[jake-abma]

And ARIA landmarks?

[patrickhlauke]

my take would be: move all the sufficient techniques under 2. Grouping blocks of repeated material in a way that can be skipped, using one of the following techniques into the advisory techniques section. they're all good things that should be done, but won't, on their own, pass this SC for all user groups.

[stevefaulkner]

@stevefaulkner so you agree / say the techniques for using Headings must be deleted from this SC?

I agree that the understanding doc wording needs to be reframed to make it clear as @patrickhlauke states

they're all good things that should be done, but won't, on their own, pass this SC for all user groups.

[patrickhlauke]

if headings are sufficient, BUT, is are the Benefits not contradictory to the techniques proposed as sufficient?

to answer the original bit, i think you're getting tripped up by the use of "headings" in the benefits? I assume in the benefits they mean "header content" as in the logo etc at the top of the page. not actual "headings"

heading graphics and dozens of navigation links...

same headings or other blocks of information

[jake-abma]

@patrickhlauke wrote:

to answer the original bit, i think you're getting tripped up by the use of "headings" in the benefits? I assume in the benefits they mean "header content" as in the logo etc at the top of the page. not actual "headings"

See techniques, answer 'yes' => headings

[detlevhfischer]

@stevefaulkner As long as H69 and ARIA11 are around as sufficient Techniques, I would find it difficult to fail a page that marks up sections by hidden headings - or uses landmarks, or native sectioning elements, for that matter. That blocks can be bypassed also by keyboard users is desirable - but does your take not imply that skip links are required to pass 2.4.1? One could equally blame user agents for not making good use of semantic information present on the page.

[patrickhlauke]

See techniques, answer 'yes' => headings

If with this cryptic sentence you mean "well, look at the techniques, clearly in those benefits it's meant at 'headings'..." then I disagree with that reading. The benefits seem to be awkwardly and confusingly phrased though.

[yatil]

Considering that headings are a sufficient technique since 2008, I assume that the WCAG founding people intended that they are sufficient, and as with color being re-defined in techniques as hue only for 1.4.1, we probably can’t change the interpretation.

[patrickhlauke]

One could equally blame user agents for not making good use of semantic information present on the page.

but the reality of this is that there's no accessibility supported "mechanism" available to users if you just use headings. or landmark regions. yes, the blame is on user agents.

[patrickhlauke]

Considering that headings are a sufficient technique since 2008, I assume that the WCAG founding people intended that they are sufficient, and as with color being re-defined in techniques as hue only for 1.4.1, we probably can’t change the interpretation.

techniques are open to changes/reevaluation though, since they're only informative. i'd say there was a lot of misplaced hope that user agents would do something useful back in those days...

[JAWS-test]

I would consider landmarks sufficient to comply with 2.4.1, since there are browser plugins for it.

Accessibility supported is defined as:

... b. The technology is supported in a widely-distributed plug-in that is also accessibility supported ...

I don't know of any plugins for headings. If this is the case, 2.4.1 would also be fulfilled in my opinion

[ZoeBijl]

When you need a plug-in for navigating I don't think that really works.

[yatil]

Considering that headings are a sufficient technique since 2008, I assume that the WCAG founding people intended that they are sufficient, and as with color being re-defined in techniques as hue only for 1.4.1, we probably can’t change the interpretation.

techniques are open to changes/reevaluation though, since they're only informative. i'd say there was a lot of misplaced hope that user agents would do something useful back in those days...

I do not disagree in principle. But we’re going one way (Techniques have defined the interpretation of the SC, so we cannot change the technique) in one case and the other (Technique have no bearing on the SC, so change the technique) in another case.

This leaves the impression that nothing in WCAG is set in stone.

[stevefaulkner]

I don't know of any plugins for headings. If this is the case, 2.4.1 would also be fulfilled in my opinion

only if "widely-distributed"

[stevefaulkner]

If we think it's a good idea for UAs to make headings focusable, we'd be recommending authors add tabindex="0" to them today.

then we would have more blocks of navigation to bypass ;-)

[patrickhlauke]

then we would have more blocks of navigation to bypass ;-)

"yo dawg, i heard you like skip links ... so i added some skip links to skip over your skip links..."

[MarcHaunschild]

I don’t agree, that keyboard users can’t navigate to headings. A keyboard user either is blind and can benefit from AT features or he can see. Than the user is able to search for any text on the page to not only bypass any clutter but even jump directly to any part of the page by setting the focus on the search result This (of course) works even with strings that are not in the viewport. Although I’m an advocate for techniques that don’t rely on AT features (aria in real life is not accessible to anybody but people with sr), in this case I don’t think that sighted keyboard users need more than headings or any other text. Only images of text would not be accessible, but this is a topic covered by another SC... BTW: it works in edge, Firefox, chrome, but not in safari. So actually browsers do support it and every safari user has voice over integrated in his system. So in my opinion you can’t say that sighted keyboard users need any additional support. Although I appreciate (and always implement) in page links like in a skip navigation or a table of content - and of course I would use the possibility to jump to headings (I do this all the time, when Voiceover is running)

[patrickhlauke]

Than the user is able to search for any text on the page to not only bypass any clutter but even jump directly to any part of the page by setting the focus on the search result

taking this to a logical conclusion, they don't even need to be headings then...so is your sufficient technique "use text that can be searchable"?

also, doesn't really account for other user groups that navigate sequentially, such as users of switch controls. i'm sure they don't want to go through the faff of searching (having to enter a search string using switch controls on-screen keyboards)...

[JAWS-test]

@patrickhlauke

my take would be: move all the sufficient techniques under 2. Grouping blocks of repeated material in a way that can be skipped, using one of the following techniques into the advisory techniques section. they're all good things that should be done, but won't, on their own, pass this SC for all user groups.

Why would SCR28 not be enough to meet 2.4.1?

I would agree on the other techniques. See also: https://github.com/w3c/wcag/issues/1146 and https://github.com/w3c/wcag/issues/86

[MarcHaunschild]

@patrickhlauke A keyboard user either is blind and can benefit from AT features or he can see.

Than [if he can see] the user is able to search for any text on the page to not only bypass any clutter but even jump directly to any part of the page by setting the focus on the search result

taking this to a logical conclusion, they don't even need to be headings then...so is your sufficient technique "use text that can be searchable"?

If you want to support only sighted keyboard users: sure! But I don't think so ;-)

With AT features I mean using structural markup (landmarks, headings...) to navigate in a page.

So of course blind people do need structural information.

But as a matter of fact I'm not very familiar with sighted users of switch controls, that are not able to use speech-to-text to search a page.

Do they benefit from headings?

[erikkroes]

I don’t agree, that keyboard users can’t navigate to headings. A keyboard user either is blind and can benefit from AT features or he can see.

This assumed dichotomy makes your arguments hard to follow for me.

[mitchellevan]

I agree H69 should be changed to advisory for 2.4.1.

Changes over time in user agent support are not the main reason; user agent support was never very good. What has changed is that more people than ever are reading WCAG who are not full-time accessibility professionals. Even with its extra disclaimer note, H69 still reads like a sufficient technique for 2.4.1 on a typical public-facing website.

In exceptional cases, a web site could still legitimately rely on headings to pass 2.4.1. For example, a company that pushes a specific browser along with a heading navigation plug-in to its employees can legitimately claim accessibility support for headings as a bypass mechanism in their company intranet. This is still perfectly fine as another way to meet the success criterion.

I do hope that in a year or a decade we'll see all sorts of accessibility improvements in user agents, including heading navigation in a broad range of user agents. When and if that happens, I'll look forward to reverting this change in H69.

[MarcHaunschild]

Sorry, I should do the research first and than start asking things like

Do they [users of switch controls] benefit from headings?

Obviously they do (at least when using switch controls in combination with VoiceOver - https://100daysofa11y.com/2019/02/03/day-65-identifying-a11y-issues-for-switch-control-users/).

So maybe I miss something, but I really don't understand, why @stevefaulkner, @detlevhfischer and @patrickhlauke think, that headings are not a sufficient technique?

Who is this user, that cannot bypass blocks by using headings or a simply text search?

[erikkroes]

@MarcHaunschild How about people that are zoomed in? In theory they can text search (but so can people that use AT). Or people with lower resolutions devices? Search is easy on computers but it's not always easy.

[patrickhlauke]

Who is this user, that cannot bypass blocks by using headings or a simply text search?

nobody's saying that users cannot do it. but the SC aims at allowing users to do it "quickly and easily". what's quicker and easier: adding a skip link, or saying that the user should do a find-in-page, type in some wording they see roughly where the main content where they want to be starts, going through potential multiple results, until they finally reach the part of the page they wanted to get to?

[mitchellevan]

Who is this user, that cannot bypass blocks by using headings or a simply text search?

Tabbing skips the following custom control, but I can use browser text search to activate it without a screen reader. @MarcHaunschild would you likewise argue that it should pass 2.1.1 Keyboard?

<div onclick="doSomethingImportant();">Save</div>

I'm in favor of new mechanisms to meet existing requirements, if a website owner would be prepared to say publicly that they meet requirement x through mechanism y. But I would never endorse this statement for a public-facing website accessibility statement: "Our website meets keyboard and bypass blocks requirements by relying on browser text search."

[mitchellevan]

That said, I do appreciate that there's a world of difference between complete lack of keyboard access on the one hand, and Bypass Blocks failing a subset of users with workarounds possible for the more technically-savvy users. Today both of these cases fail WCAG. I look forward to the WCAG 3 concepts of functional needs and conformance levels, which I hope will help soften these bright-line distinctions between pass and fail.

[MarcHaunschild]

The question is: "Are 'Headings' enough to pass 2.4.1: Bypass Blocks?" With this in mind I wrote:

Who is this user, that cannot bypass blocks by using headings or a simply text search?

nobody's saying that users cannot do it. but the SC aims at allowing users to do it "quickly and easily". what's quicker and easier [...]?

The answer is not relevant, because using the search is a quick and easy way to navigate a page. This is true although there are even quicker and easier ways like a skip navigation.

WCAG is a set of minimal requirements. It also nowhere says, we have to use the best possible contrast (what would be just black and white), but that contrast must be at least 3:1. 4,5:1 or 7:1. We all know, that might end up in hard to read passages depending on which colours you use for background and text.

As I understand we just talk about: if I check a website, do I have to give it a pass for 2.4.1, if the page has headings for every section. And although I do not like this answer, I think I would have to say: yes it's a pass.

I also have to give a pass for orange on blue if it has at least a contrast ratio of 3:1 and a size 18.5px bold text - and I do not like this either! ;-)

[MarcHaunschild]

Who is this user, that cannot bypass blocks by using headings or a simply text search?

Tabbing skips the following custom control, but I can use browser text search to activate it without a screen reader. @MarcHaunschild would you likewise argue that it should pass 2.1.1 Keyboard?

<div onclick="doSomethingImportant();">Save</div>

Difficult to say, as I have no idea, how this should work, I never tried. But I guess, it should pass, although (once again) I would not like it.

On the other hand it would fail "4.1.2 Name, Role, Value" anyway and after adding role="button" (or much better: using the button element) it would automatically be focusable. So this this doesn't look like a real world problem to me.

So I never put a lot of thoughts in this and this is just a quick answer...

[ericwbailey]

So I never put a lot of thoughts in this and this is just a quick answer

Maybe you shouldn't be participating in this discussion.

[patrickhlauke]

@MarcHaunschild so in short, the bone of contention here is if "as a sighted keyboard user, you can skip things by doing an in-page search for some text you see that's near where you want to get to" is an acceptable "mechanism". I grant you it is ... a way for sighted keyboard users to get around. assuming the user can see where they want to get to and it's not outside of their viewport/browser window (perhaps they zoomed in, or have their browser window set quite small, or the header section/what they want to skip is so huge that it takes up most of the space). For those uncertainties, I'm still not convinced it can be counted as a solid "mechanism", but I can see your rationale.

[MarcHaunschild]

So I never put a lot of thoughts in this and this is just a quick answer

Maybe you shouldn't be participating in this discussion.

I'm sorry? - That was not about the whole discussion, but about a specific question, in which I was explicitly mentioned. So why I should not give a thought even if I'm not sure, that I have thought it thorough to the very end?

By the way: you are free to give a better answer if you have one. ;-)

[awkawk]

The Headings Map extension allows keyboard users to navigate headings from the keyboard. Available for Firefox and Chrome, and the Landmarks extension provides keyboard access to landmarks. There is no requirement that the ability to navigate by headings must be built into the browser natively, just like there is no requirement that image alt values are read out loud by the browser.

[stevefaulkner]

The Headings Map extension allows...

so this is a widely distributed plug-in?

[awkawk]

@stevefaulkner would you say that plugins available in the Chrome store meet that threshold for Chrome?

[MarcHaunschild]

@MarcHaunschild so in short, the bone of contention here is if "as a sighted keyboard user, you can skip things by doing an in-page search for some text you see that's near where you want to get to" is an acceptable "mechanism". I grant you it is ... a way for sighted keyboard users to get around. assuming the user can see where they want to get to and it's not outside of their viewport/browser window (perhaps they zoomed in, or have their browser window set quite small, or the header section/what they want to skip is so huge that it takes up most of the space). For those uncertainties, I'm still not convinced it can be counted as a solid "mechanism", but I can see your rationale.

Just to make one thing clear before my next answer: I'm arguing against some of the most treasured people when it comes to accessibility, so I'm very aware that I might miss something here.

Anyway it takes quite some courage to defend my point of view. I even would like to be wrong, because I think there should be a SC explicitly demanding name, role and value for content (so that developers have to use the main element or the main role), but even 4.1.2 only addresses user interface components.

This said: I never even considered this SC to address sighted users, no matter which screen setup they use, as the "How to understand" says: "This is in contrast to a sighted user's ability to ignore the repeated material either by focusing on the center of the screen (where main content usually appears) or a mouse user's ability to select a link with a single mouse click rather than encountering every link or form control that comes before the item they want."

It also clearly states that "It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent."

If you prove me wrong, I would really appreciate it and give fails for this SC with a big satisfaction, whenever a site provides nothing more than headings to bypass blocks. When I first joined this discussion I expected, that someone would just provide a link to a piece of information, that I was not aware of yet. I did not expect this to be such a long discussion. But if there is nothing within the WCAG I can use as an argument for a fail, I think I would have to give it pass...

[stevefaulkner]

@awkawk wrote:

@stevefaulkner would you say that plugins available in the Chrome store meet that threshold for Chrome?

I think that terms such as widely distributed need to be formally defined before i could answer that question with confidence.

Take for example the Headings Map extension has a user base of 30,000+ users which appears impressive, (although a drop in ocean compared to people who may benefit from in browser functionality that specifically supported bypassing of blocks) and may be considered widely distributed, but it appears to be a 'developer' tool rather than and end user tool. And my initial testing (just now) of it using the keyboard found it to be sub-optimal using the keyboard, it does not appear to be designed with keyboard only users in mind. So in this case irrespective of it being available on the chrome store or not I would not consider its to be a widely distributed plugin to support bypassing blocks.

[awkawk]

@stevefaulkner Since widely distributed is not, and realistically probably will never be formally defined the definition falls to what is common usage so there is subjectivity there. I think that the breadth of the distribution is less about whether users have installed the tool but whether it is distributed widely enough that they can install it if needed. I'm sure that many more people would benefit from a tool like this than who have it, just as there are probably many more people who would benefit from high contrast support or text resizing than those who are aware of how to make these work.

I'm not promoting that tool as the answer, I've tried it out and found that from a keyboard user perspective that it does allow you to skip the navigation, but I'm sure that there are improvements that can be made.

I believe that due to tools like these that headings or landmarks are sufficient to meet 2.4.1, but I will also say that we are working to implement skip navigation / jump menus more widely because we do think that end users can benefit from the ability to use the document semantics for navigation in a more straightforward way that doesn't require a plugin.

I would love to see browsers implement support for heading and landmark navigation. Maybe @cyns can help!

[erikkroes]

Different question, but what happens when an extension that helps one SC is available for Chrome, and an extension that helps another SC is available for FireFox?

[awkawk]

Different question, but what happens when an extension that helps one SC is available for Chrome, and an extension that helps another SC is available for FireFox?

If you don't have a solution that provides support for an end user using a single browser than you will have a conformance and user issue.

[bruce-usab]

IMHO, in the context of WCAG, availability for free in an app store would satisfy widely distributed. Note that if the feature is just one browser, then accessibility supported becomes pretty significant. In the early days, we wrote up some techniques for Silverlight, but since then most work is on cross-platform approaches.

I will also volunteer here that with the 508 refresh, particularly at the proposed rule stage, we tried to use widely distributed a criteria for when 508 must be applied to off-line documents. In the end, we were not successful with nailing that term down sufficiently.

[stevefaulkner]

I believe that due to tools like these that headings or landmarks are sufficient to meet 2.4.1

We will have to agree to disagree on this then as I do not consider this sufficient and no arguments brought forward so far have lead me to modify my interpretation.

[mraccess77]

Many accessibility consultants are failing this criteria for public site audits when skip links are not present. So there seems to be a strong feeling generally that headings may not be enough or could be challenged by advocates as not enough and thus skip links are needed to provide equitable access.