[BITV] Lazy loading is not accessible

[PVince81]

"Lazy loading not accessible as you can not move very far to the past quickly. Pagination would be much better here"

To discuss how this applies to:

• file lists
• comments list in sidebar
• versions list in sidebar

[PVince81]

as soon as we know how to do it (ex: pagination) we can at least do it for comments and versions

for file list it is going to be tricky due to legacy jquery code

[PVince81]

maybe we can check how other solutions are doing it that deal with file lists

[skjnldsv]

So, to add more on this, a proper lazy loading should be accessible if tabbing or keyboard arrow-down focuses the next row.
Screen readers can have hidden cue that the list is incomplete if they want. But really, it should just start announcing how many items are in the list (we know the total amount), and then announce each row as the focus move forward.

Best of both worlds +1

[skjnldsv]

But what kind of accessibility are we talking here?
Screen readers I assume, right? Because if this is only about keyboard navigation, then this is easily covered.

Screen readers should just state:

• Files list below, one hundered and thirty three entries
• <tab>
• Entry one. Image1.jpg. 145KiB. Last modified: 3 days ago.
• <tab>
• Entry two. Image2.jpg. 211KiB. Last modified: 2 hours ago.
• <pagedown>
• Entry twenty-five. Quarter results 2021.ods. 211KiB. Last modified: 19 January 2022.

[PVince81]

as far as I remember it goes further than that: on table elements you can set aria attributes that have the screen reader announce how many entries there are in the table (or it might be automatic)

with lazy loading it would only say that there are 20 rows but actually there's more

and with pagination implemented, there are also ways IIRC where you can have the screen reader tell you that there's pagination and that you're on page X of Y, and possibly some allow you to jump directly to specific pages or to the pagination controls

[skjnldsv]

with lazy loading it would only say that there are 20 rows but actually there's more

But we can trick the screen reader into that. Screen readers can also read whatever we want them to :)

[PVince81]

let's split the topics:
files list I think is most important because the likeliness of pagination there is much higher

for versions and comments we currently don't paginate nor lazy load but also it's seldom that there's more than one page of entries there

[PVince81]

note: we need to keep the "table" element for the file list, otherwise a lot of code and apps will break

so we need to research how to make the table/listing/pagination accessible with the current structure

[skjnldsv]

We can use role=table.
Table elements have too much downsides with css.

[PVince81]

to clarify:

for the files 2 vue project, we can switch to whatever we need.

for stable25 accessibility we need to keep the table with minimal changes to make it pass certification in regards to pagination

[JuliaKirschenheuter]

I've researched around for the possible solution.

We have 1 main requirement: content in a <table> form should be kept.
There are 2 possibilities to solve this task:

• Change / extend a lot for existing infinity scrolling solution.
• Replace infinity scrolling with common pagination.

There are some requirements for accessible infinity scrolling:

• Cut the whole content in invisible pages:
  
  https://adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html
• user have an option to jump ahead a few "pages" backwards and forwards (if content is loaded) to achieve a quick navigation through all content. (which shortcut should be used?)
  • user can hit "back" button and return to first entry of "previous" page.
  • user can hit "forward" button and return to first entry of "next" page if content is loaded.
• user can see and reach via keyboard current and whole amount of entries "loaded amount of whole amount" somewhere on the bottom of the page.
  
  https://uxmovement.com/navigation/infinite-scrolling-best-practices/
• user can see and reach via keyboard a "page footer" as "load more results" button or link that explicitly invites the user to load more entries (how to come to entry back)? (which shortcut should be used?)
  
  https://uxmovement.com/navigation/infinite-scrolling-best-practices/
• user can see the navigation bar persistently visible.
• user have an access to all content on the page and can easily leave an infinity scrolling area. (which shortcut should be used?)
• user can go back to infinity scrolling area (to which entry / page?). (which shortcut should be used?)
• use a role="feed".

Links:
https://adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html
https://www.webaxe.org/infinite-scrolling-and-accessibility/
https://uxmovement.com/navigation/infinite-scrolling-best-practices/
https://www.deque.com/blog/infinite-scrolling-rolefeed-accessibility-issues/

The whole content is inside of the <table>. How could we provide this content in a most accessible way? Jump form row to row via "tab"?

[skjnldsv]

So, let me take a step back.
We did some testing in the past. We can drop lazy loading AND/OR pagination.
The issue is not about loading 10, 100, 1k or 10k files. it's rendering them.

The real dilemma is about virtual scrolling.

EDIT: this is for 26 only, the question and complexity level dilemma for 25 remains

[JuliaKirschenheuter]

As known we are using a <table> to present the content of file list. The main question for now is a right rendering of content into the table (entries will be rendered and be visible only at the scroll position). As far the file list is incomplete (not fully rendered or not fully loaded) there would be problems with a screen reader.

Open questions:

• how to influence a screen reader to announce the total number of rows and entities?
• how to provide an information to screen reader that the file list is still incomplete (with right semantic, without <table> interruption)?
• could this approach still work with virtual scrolling?

@michaelnissenbaum could you please help us with this questions? Thanks a lot!

[JuliaKirschenheuter]

Update: it is important to keep infinite scrolling and it is not possible to change the code to pagination (would be a large breaking change). Only small fixes or adjustments could be done in this point.

⚠️ virtual scrolling is only for "files to vue" (NC27+)
⚠️ infinite scrolling is for NC25, NC26

[michaelnissenbaum]

@JuliaKirschenheuter
The simplest solution for "table"-element will be to inform screen reader users that additional rows will be added once end of the screen is reached. This can be achieved using the aria-describedby attribute - see https://www.w3.org/WAI/tutorials/tables/caption-summary/#using-aria-describedby-to-provide-a-table-summary.

[JuliaKirschenheuter]

Thank you @michaelnissenbaum!

• Could you please also tell us which points are "must-have" to pass certification and which are "nice-to-have" from [BITV] Lazy loading is not accessible #33844 (comment)?
• You mentioned also "filter"-feature, but could you please write more details about it? Which filter should be there exactly?
  • navigation via months/time could be useful
• Is there some more features to implement for passing certification regarding infinite scrolling with table?

Thanks again!

[karlitschek]

Quick comment from me. I don't think we should fully switch to pagination for everyone. Endless scrolling is so much nicer and expected nowadays. I hope there is some option to do endless scrolling and also be accessible. Paging is soooo 90s internet ;-)

[michaelnissenbaum]

@JuliaKirschenheuter I'm not saying that lazy loading isn't accessible, but it's not optimal for users with certain limitations. As I've already written, my first suggestion is to use the aria-describedby attribute to inform users that the table is expandable. Second, you could include a filter area (accordion element) above the table where users could reduce the number of table rows. For activities, for example, filters for tag, month, year, file type, added, deleted, etc. could be used.

[JuliaKirschenheuter]

Quick comment from me. I don't think we should fully switch to pagination for everyone. Endless scrolling is so much nicer and expected nowadays. I hope there is some option to do endless scrolling and also be accessible. Paging is soooo 90s internet ;-)

To drop infinity scrolling was never my intention. But make an accessible existing solution 👍

[JuliaKirschenheuter]

I think this issue can be closed for now. Will reopen it if will be relevant.