Infinite scroll and bypass blocks

[kimviens]

I would like to know how WCAG applies to infinite scrolling content. I was faced with a website that has an infinite scroll as main content. After the infinite scroll in the tab order, there was a menu.

When testing with a keyboard, I found it was impossible to access the menu that follows the infinite scroll.

To me, this kind of accessibility failure should be covered by ByPass blocks. However, in the wording of the criteria:

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

It says specifically "content that is repeated on multiple web pages". What if this infinite scroll is not repeated on multiple web pages?

[JAWS-test]

Probably the menu would be accessible with SHIFT+TAB, but it should also be accessible with TAB, that's why: Failure of SC 2.1.1 https://www.w3.org/TR/WCAG21/#keyboard

[kimviens]

Hi @JAWS-test, the menu is accessible by keyboard. The problem is that you must go through the infinite scroll first. So for example, I had to tab more than 100 times to get to the right side content.

So the problem is not keyboard accessibility, the problem is that it takes a gazillion tabs to get there.

[detlevhfischer]

The Sufficient Techniques listed for 2.4.1 Bypass Blocks have long included headings markup for sections and landmarks / native markup (nav, main, etc). Both techniques would help screen reader users bypass infinite scroll content, but only those knowing about them - and it would not help sighted keyboard users (unless they install a plugin to use lanmarks with the keyboard). Some people here and elsewhere have long argued that in many cases, skip links are therefore not only desirable but essential to support sighted keyboard users and conform to 2.4.1. (Side note: Pragmatically, a menu after main content with infinite scroll may be reached by tabbing backwards through the browser chrome so that focus enters from the end of the page, but of course that is not a good solution. I am also not sure how many keyboard users know about that.)

As to the point of that Bypass Blocks applies to content repeated on multiple pages: It seems relatiely rare to have a navigation which is only on one page and not provided similarly on other pages. I cases where a site is just one long page (or a few) I do not think that Bypass Blocks would automatically not apply. If the menu is critical for using the page, I would see it fall under 2.4.1 even when there are no other pages. But people may diverge in their judgment here.

[kimviens]

@detlevhfischer Thank you for your response, I agree with everything you just said. At the end you say: "In cases where a site is just one long page (or a few) I do not think that Bypass Blocks would automatically not apply. If the menu is critical for using the page, I would see it fall under 2.4.1 even when there are no other pages. But people may diverge in their judgment here."

If I were to write a WCAG report and I wanted to fail that website because there is "technically" no good way to access the content at the other side of the infinite scroll. I don't think I could fail them. Instead I would report that issue as "usability".

I feel that the problem here is that this is an accessibility issue that falls through the cracks of WCAG.

[kimviens]

If I were to generalize this issue, I would like to be able to fail websites when the number of tabs become unreasonable to get to core functionality. Like if a section in the focus order is huge, there should be a way to bypass it.

[JAWS-test]

@kimviens I understood "infinite" literally and thought there was no way with TAB to the menu.

The way you describe the problem, I see it as an accessibility issue, which is not covered by WCAG. I think there is a gap that should be closed with WCAG 3.0. Otherwise, I would currently sort this in is SC 2.4.3 Focus Order - I see the focus order at the beginning (through the feed to the menu), but then suddenly more content is added that prevent me from getting to the menu as expected. But this is also not really in accordance with SC 2.4.3 - that's why we need a new SC for it

[kimviens]

@JAWS-test I agree with you, I hope that there could be a way to cover infinite scroll content in WCAG.

[alastc]

Hi @kimviens,

If the infinite scroll prevents you from accessing subsequent links you could fail that under 2.1.1 keyboard. If the infinite scroll is practically infinite, you could consider it a "keyboard trap".

It doesn't really fit the scope or intent of 'bypass blocks', although the solution may be similar (i.e. skip link).

[kimviens]

Hi @alastc !

I agree with what you wrote. I have a new question for you, what if its just a really long main content area? Lets say it takes the user 25 tabs to get to the right side menu. Could bypass blocks be rephrased to help those situations?

[patrickhlauke]

Could bypass blocks be rephrased to help those situations?

the existing definition/interpretation of a long-standing and established SC can't simply be rephrased/reinterpreted retrospectively

[junykallukalam]

The underlying intent is to prevent users from getting "trapped" in large blocks of content and to ensure that they can easily reach the main content of the page. An infinite scroll can certainly create a "trap,”. This can make it practically impossible for the user to ever reach the menu.

[kimviens]

I see that a discussion tag was added to this issue. Has a discussion taken place?

[avkuo]

@kimviens , is this still an issue? Please provide any update, or close if it is no longer an issue.

[kimviens]

@avkuo I think that this issue can be closed if we agree on the following:

• Infinite scroll region preventing access to items can be filed under keyboard trap
• Its a best practice to offer bypass blocks over huge blocks of content

[patrickhlauke]

I'm all for the best practice (to be added to bypass blocks understanding), but not sure the infinite scroll would fit the case for keyboard trap. i'd more closely associate it with 2.4.3 Focus Order perhaps (as in the focus order must make sense/be logical, but the site keeps injecting extra focus stops after your current one, so it keeps shifting the logical structure, or something along those lines)

[kimviens]

I think it could be a slippery slope to put it into Focus Order, in that case, is inserting anything in the focus order after your current focus a failure?
Wait! What if it were 2.1.1 Keyboard??? Because you cannot test if the content after the infinite scroll works by keyboard because you can never reach it?

[patrickhlauke]

I think it could be a slippery slope to put it into Focus Order, in that case, is inserting anything in the focus order after your current focus a failure?

I guess it depends if you can define when it's "infinite" versus a discrete change

Wait! What if it were 2.1.1 Keyboard??? Because you cannot test if the content after the infinite scroll works by keyboard because you can never reach it?

That seems a bit spurious, and you can generally still reach them if you navigate in reverse through the page (i.e. shift+tab backwards so that it starts focussing at the end of the document)

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.