Are 'Headings' enough to pass 2.4.1: Bypass Blocks #1712
Comments
|
ps. I also read "the same headings" but how to distinguish IF heading ARE implemented and sufficient? |
|
(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") |
|
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. |
|
@detlevhfischer but it won't help, you still need to go through all headings to find them... |
|
My take is that headings alone are not enough as heading navigation for keyboard only users is not accessibility supported. the SC
The mechanism is not available for keyboard only users. |
|
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. |
|
@stevefaulkner so you agree / say the techniques for using Headings must be deleted from this SC? |
|
And ARIA landmarks? |
|
my take would be: move all the sufficient techniques under |
I agree that the understanding doc wording needs to be reframed to make it clear as @patrickhlauke states
|
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"
|
|
@patrickhlauke wrote:
See techniques, answer 'yes' => headings |
|
@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. |
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. |
|
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. |
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. |
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 would consider landmarks sufficient to comply with 2.4.1, since there are browser plugins for it. Accessibility supported is defined as:
I don't know of any plugins for headings. If this is the case, 2.4.1 would also be fulfilled in my opinion |
|
When you need a plug-in for navigating I don't think that really works. |
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. |
- the use of "heading graphics" and "headings" in the benefits is confusing, and - unless I'm mistaken - there to signify more broadly "header content". current use of "headings" is in apparent contrast with techniques that then talk about using headings - see #1712 - in the intent, the "This is in contrast" section is missing the first bit...the part that explains how users that navigate sequentially actually have to go through all the stuff first. and THEN that sets up what "This is in contrast" to.
only if "widely-distributed" |
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..." |
|
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. |
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)... |
Why would SCR28 not be enough to meet 2.4.1? I would agree on the other techniques. See also: #1146 and #86 |
|
@patrickhlauke
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? |
This assumed dichotomy makes your arguments hard to follow for me. |
|
@MarcHaunschild As I've said, I believe the question that seems to be on the table (about whether to move the techniques from sufficient to advisory) comes down to a subjective decision since it is not clearly defined normatively.
On the contrary, My thinking here is solely based on the normative text plus adjacent notes:
So, putting all these together, my reading is that headings could be sufficient if there is a widely distributed plugin to facilitate navigation by heading, but the WG explicitly does not define how much support is required to qualify, or what widely distributed means. In this particular case, the available plugins don't seem to me to rise to the level of support that I would base a conformance claim on. As nice as they are, they are produced by individuals or small groups of volunteers and make no guarantees about their future availability. One of them does not appear to be fully keyboard operable, which would mean it is not accessibility supported itself. Again, I'm not trying to downplay the utility of these plugins or the dedication of their authors - but I don't feel that they are enough to base conformance decisions on. |
|
hmm I think that plug ins are kind of iffy as qualifying as being part of the platform or user agent.... But it is a gray area and probably could be called either way (not much help). It would CLEARLY be better if the browsers would just make this a simple feature in their browser (jump to next heading). One reason they probably don't is that a lot of headings aren't really marked up as headings, so the feature would always look like it was failing to people who can see what appear to be headings, but are not marked up as headings. So because it would not always work, they wouldn't want to put it in as a feature and get lots of complaints and bug reports. As we get to the next stage where we have intelligent browsers, that can automatically tag headings in the DOM even if they are not properly marked up as headings, we may be able to ask for such a feature in the browser. |
|
In your quotes this part is important (if we really want to look into the informational parts): "The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies." AT actually can rely on headings. Maybe I'm not getting something here, because even for native speakers the WCAG is not easy to read. It took me quite a while to understand it. But even after 20 years there still might be parts that I don't get right. To me this part means
To me it seems you look for information that covers your subjective opinion. You miss for example this technique: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA11.html And also other SCs allow mechanisms that are only available for AT, like values of aria attributes (aria-label is such a thing, that provides information exclusively for people with AT). We accept this for many SCs. I don't see why and how someone could think of stricter rules for this SC. What is so special about 2.4.1 - I mean, it's nice to bypass blocks but if not, you even can still reach every content. |
If we're taking the "consider keyboard users that don't run AT" stance for 2.4.1, then that should be advisory. Then again, a large number of techniques are of dubious quality and have been dubiously categorised.
But those are generally complemented by other SCs that ask for the equivalent for non-AT. assuming you mean using |
I do admire the unshakeable faith in spicy autocomplete / statistical guessing models and how they'll magically make accessibility work obsolete. but in the here and now, this doesn't help all that much... |
|
“Intelligent browsers” aka browsers that interpret the content and visuals through some kind of LLM on the client side make zero sense as the analysis would be done on every page load, consuming a significant amount of additional energy. For the convenience of not showing existing headers. Which is a three line JavaScript that browsers could ship tomorrow. They do not care. |
|
Just for reference...
On Friday, December 15, 2023 01:40:29 (+01:00), Gregg Vanderheiden wrote:
... As we get to the next stage where we have intelligent browsers, that
can automatically tag headings in the DOM even if they are not properly
marked up as headings, we may be able to ask for such a feature in the
browser.
Getting a reasonably useful feature like this doesn't take an intelligent
browser, it takes a bit of heuristic code. Things that are short on text,
have distinctive styling, are a fraction of the overall content, especially
if they are consistently referenced in blocks of mostly links (which are
likely to be a navigation block with or without being a nav element) are
likely to be headings. Likewise, if there is a similar style that regularly
precedes lists, it's probably a heading...
We could ask for it today - or 20 years ago. Back then, the Opera browser
offered keyboard navigation of (properly marked up) headings as a standard
browser feature, and the JAWS screen reader was just introducing it as a
wonderful new feature for users.
And it turns out that 20 years ago, we *did* ask for it in browsers.
Consider for example
https://www.w3.org/TR/UAAG10/guidelines.html#tech-nav-structure - or the
bit introduced by the heading "Doing More" in the section at
https://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-provide-outline-view
This isn't a question of "can't, at least until some magical future", even
for the more speculative bits where headings aren't properly coded. I don't
know, but I get the sense that more often than previously, they *are* in
the markup. As we have asked for over the last quarter century.
As the discussion is surfacing, there are functionaliites we think are OK
if they are only available through the user adding some special tool, there
are functionalities we think have to be available in Google Chrome out of
the box or they don't count as feasible for real people, and we don't seem
to have a clear explanation for how we decide where on that spectrum we
place a given requirement.
I believe, after participating here for about 25 years, that how we make
those decisions is "it's somewhat arbitrary, based mostly on what the group
can get consensus about", but it seems people don't like to say that. If
it's not obvious we can come up with a better explanation, maybe we should
just say that's what happens. (Or are we, as a group, up for a discussion
on whether we *can* change that model?)
cheers
…--
Chaals Nevile
Using Fastmail - it's worth it
|
|
I know I'm quoting an old comment, but it illustrates a stance that has been taken by many others:
In my opinion, the definition of accessibilty-supported is exactly why landmarks and headings alone are not sufficient to "bypass blocks" and why skiplinks are still needed. The definition uses the phrase "widely distributed", not "widely distributable". When a plugin is in the Chrome Webstore, it is merely "widely distributable", i.e. it has the potential to become "widely distributed". However, the phrase "widely distributable" is not about a potential future situation but about an actual current state. For this reason, pointing to the existence of plugins is insufficient. Note that at the time when Technique H69: Providing heading elements at the beginning of each section of content was written for WCAG 2.0, there was a user agent that supported heading navigation natively, namely Opera and, if my memory is correct, there was hope that this feature would become available in other browsers. Unfortunately, exactly the opposite has happened, so sighted keyboard users who don't know about browser extensions or are afraid of modifying their browser by installing extensions are out of luck. |
For employers that disallow plug-ins (waves arms at half a dozen banking clients employing tens of thousands) and for which an employee is not technical enough to make the case for an exception, this Sufficient Technique leaves them stranded. See also my comment above from 31 March 2021 about reliance on future abandonware. Also, IMO the case has been made repeatedly in this discussion. Also also, Firefox and Safari are browsers. We are not yet fully consumed by the Chrome monoculture. |
sadly yes, it seems in addition to some often implicitly subjective SC wordings, there's an additional "just vibes" layer when it comes to things like deciding if something is "accessibility supported" or not |
|
Technically, sufficient techniques must be accessibility supported when they are written. For a technique to be sufficient, you must meet the success criterion – sometimes in conjunction with other techniques. Having H69 alone as a sufficient technique means that the WG has decided – at one point – that it is accessibility supported. If that was done under the assumption that Opera’s solution would filter through to other browsers, then that decision needs to be revisited. It’s 10 years since the switch from Presto to Blink, which is the time when all these browser functions disappeared, if I recall correctly. If the techniques are relevant at all, they need to be current and not confuse practitioners. Otherwise, maybe it is time to not publish techniques at all if they are not useful. |
This seems to be devolving a bit into personal attacks, and other folks have picked up the discussion in the meantime, but I wanted to add one distinction that seems relevant here:
This is, I think, subtly misleading. 2.4.1 requires that "a mechanism is available". It does not require a mechanism that AT could potentially make use of (like 1.3.1, which says information can be programmatically determined), rather it requires that a (accessibility supported) mechanism is currently available. Or, to put it another way, it's not enough that the content provides the information - the user must actually be able to act on it to bypass blocks. This brings us back to the question of whether an accessibility supported mechanism currently exists. A sighted keyboard user is unlikely to be using a piece of assistive technology like a screen reader that might provide this mechanism. This leaves the user agent. While the definition leaves the door open to plugins, the current state of browsers/plugins does not seem to meet the threshold of navigation via headings/landmarks being accessibility supported for all the reasons others have mentioned.
Yes, as mentioned I agree with @ghost suggestion that we "make all of the techniques in Grouping blocks of repeated material in a way that can be skipped, except for SCR28, advisory" so technique ARIA11 would also no longer be sufficient. |
As a longtime Firefox user myself I agree wholeheartedly, but do note that the two plugins mentioned up-thread are available for both Chrome and Firefox. All hope is not lost :) |
That's not what I meant. My argument was:
I talk about todays WCAG. After WCAG has been changed I will completely agree with you! |
|
in March 2021 this discussion was at this point:
I think this change/ reevaluation is long overdue. Remove headings from the list of sufficient techniques. |
|
in March 2021 this discussion was at this point:
I think this change/ reevaluation is long overdue. Remove headings from the list of sufficient techniques at 2.4.1 |
Policies within individual employers can cause all sorts of havoc. An employer might only allow a particular and less-accessible browser or not allow non-standard software (including some AT) by default. We can't avoid all possible issues unless we require web content authors to provide direct support for all needed functionality, but that is problematic given the amount of functionality that AT and user agent extensions provide.
Sure, so the concern is that the extensions referenced may go away and that support within a browser is preferred. In general, I agree, but should point out that the referenced functionality in the Opera browser went away, so this concern is not limited to plugins/extensions. To me this signals the need for developers to be able to know whether assistive technologies or other user agents can support users in accessing information that the developers provide using different techniques. That knowledge may come from techniques, investigations publicized in an accessibility advocate's blog, company marketing materials or help docs, etc.
Why are plugins iffy? In WCAG's definition of "accessibility supported":
If an extension is available, for free via the relevant app stores, for more than one browser and allows users to navigate past a set of repetitive links using headings and/or landmarks, what's iffy? |
|
What has not been discussed is that the requirement is to skip each repeated block of content - so it's not enough to just have headings or a skip link but that each repeated block in a page within a set of web pages can be skipped. So the placement and location of skip links, collapse controls, and headings is critical to meeting this. |
|
BTW: distributed widely - what is the definition of this? Is it enough to have an extension for a single browser? With what market share? 10%? 40%? 80%? What if this browser is banned fro EU or US or any other region/ country? Is it fair to consider it distributed widely? What if it is banned in just one poor country, that most people don't even know about. Is it ok to exclude these people from accessibility? I don't consider it a wise decision to use such an expression that will bring the WG in a position where it has to defend WCAG wording like this: "Back then there was this promising cute browser, with 2% market share that we all loved so much and we hoped that with a little bit lot of luck one of its cool features one day would make it's way into other browsers" I'd suggest to get rid of this "widely distributed" expression unless you can define what it means - and the definition should be free of vibes and dubious quality. |
A single skip link ist enough. The intent of this SC is to get quickly to the main content. More than a single link to the main content is not necessary. And its much better for this purpose than headings of course. |
…ches normative WCAG fixes #1712
|
Are headings enough to pass 2.4.1 Bypass Blocks? A technically correct answer is: "yes, if headings are accessibility supported for keyboard use." Accessibility supported allows reliance on a plug-in to meet any criterion, provided that any of these four statements is true:
Note the fourth statement. If a user agent (whose definition includes plug-ins) isn't already widely distributed, it's enough for the user agent to be available for no cost and easy to find and obtain. Understanding Conformance makes it clear that words like "available" and "easy to find" are not globally defined, but contextual depending on things like language and cultural context, and these judgments are left to the community. But it's equally true that inserting I conclude that we can't demote H69 to an advisory technique, but it needs to be much clearer that it's only sufficient for 2.4.1 to the extent it is accessibility supported. I've attempted to add this clarity with PR #3656. If there's a way to make the caveat still stronger, I would support that too. |
|
while the logic is sound, it does reveal how the concept of "accessibility supported" as defined in the spec is - surprise - a handwavy bunch of weasel words that just abdicate responsibility. in theory, as long as there's one single obscure web page somewhere that offers a plugin/extension/bookmarklet for free, under that last point it can be considered "accessibility supported". |
|
The problem with H69 is that while it states that its objective is "to use section headings to convey the structure of the content" it immediately continues with a vague list of things headings might be used for (ony the third bullet returns to "to demarcate different navigational sections"), and the examples add to the blur. My line would be that IF headings are used to meet 2.4.1, they should at least cover the page structure (say, be used equivalent to nav and main and footer). The way it is written now, the Technique seems to be close to worthless. Is it worth sharpening this old blunt knife if we need to keep it as sufficient? |
|
Adding to the "accessibility supported" thoughts above, my colleague @deanholden rightly noted that while plugins/extensions/bookmarklets may be available for desktop browsers, the same can usually not be said for browsers on mobile/tablet operating systems. This can certainly put a dent in the argument over whether or not a particular solution is "accessibility supported" |
I noticed that Safari on iOS has extension support - so this does seem to be coming to mobile. |
|
PR #3656 is a good first step but I've removed "fixes #1712" from it, because:
WCAG over time has reduced the cautionary notes on all of its techniques. This is a good thing, a testament to the years of amazing work by advocates and browser developers to improve accessibility support. As a consequence however, H69 no longer has the old warnings, which it needs now as much as it ever did. Compare current H69 with WCAG 2.0 H69. The WCAG 2.0 version had these layers of warnings:
The current H69 has none of those warnings, only this cheerful first sentence (emphasis not mine):
|
- the use of "heading graphics" and "headings" in the benefits is confusing, and - unless I'm mistaken - there to signify more broadly "header content". current use of "headings" is in apparent contrast with techniques that then talk about using headings - see #1712 - in the intent, the "This is in contrast" section is missing the first bit...the part that explains how users that navigate sequentially actually have to go through all the stuff first. and THEN that sets up what "This is in contrast" to. I believe this is an editorial change only. --------- Co-authored-by: Mike Gower <[email protected]> Co-authored-by: Alastair Campbell <[email protected]>
and others
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:
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?
The text was updated successfully, but these errors were encountered: