Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle lazy loading of rows for a11y #1608

Open
DanielleRameau opened this issue Oct 24, 2024 · 1 comment
Open

How to handle lazy loading of rows for a11y #1608

DanielleRameau opened this issue Oct 24, 2024 · 1 comment
Labels
accessibility question Further information is requested

Comments

@DanielleRameau
Copy link
Collaborator

No description provided.

@DanielleRameau DanielleRameau converted this from a draft issue Oct 24, 2024
@DanielleRameau DanielleRameau added question Further information is requested accessibility labels Oct 24, 2024
@DanielleRameau DanielleRameau moved this from 📥 Incoming to ⏳ Waiting for input in SL Design System Team Oct 24, 2024
@anqaka
Copy link

anqaka commented Oct 24, 2024

Lazy loading it's not very accessible for assistive technologies users.

I did some research about infinitive scrolling, it's not the same approach, because infinitive scrolling is mostly use for a feeds and articles but is has a lot of common.

To make lazy loading for data accessible we should consider a11y users::

  1. Screen reader users: loading data should be announced to SR user and also position of the row in a grid (totals rows number loaded) should be updated and announced to the SR user
  2. Keyboard users: keyboard only users should be able to easily access the content outside the data grid
  3. Speech Recognition: how scrolling and lazy loading should work for speech recognition users?
  4. Users who use a switch device: Just think of users who use a switch control to browse the web, the amount of stress they might have to go through if they are forced to use lazy loading to access a particular content
  5. People with various motor impairments: Lets assume that a person with a motor disability browsed through a set of content in the lazy loaded data & found what the user is looking for. While the user is interacting with content if there is a twitch or a tremor while the finger is on the mouse wheel the content will move and it will be a time consuming task to find the same content again.
  6. Low vision users: users who have low vision tend to use a screen readers, screen magnification software or windows high contrast mode. Just imagine how easy it will be for a low vision user to access your content wrapped inside an lazy load? Low vision person often uses mouse with screen magnification. His/her hand & eye are in continuous coordination all the time and since the screen is magnified up to 6x times it was a continuous stress to find the right content.
  7. Cognitive users: There are various cognitive user groups like Dislexia, ADHD, Short term memory loss... They need a control of the loading content and it's hard to them to navigate through the content without knowing where it's the end.

Additionally, there is a great article (resources below) from Adrian Rosseli and after him, I list questions about accessibility of infinitive scrolling / lazy loading:

  1. Can the user hit “back” and return to the exact same place? Does loading data impact url?

  2. Is there paging for when the JavaScript breaks?

  3. Can a keyboard user access all other content on the page?
    Do keyboard and screen reader users can easily access other components on the page, like footer, sidebars etc, or they need to tab through all lazy loading content?

  4. Can you share a URL to a specific place on the page?
    After you’ve gone a few screenfuls deep you may have found a few links of interest. Can you copy the address from the browser and email it (or even tweet it) and expect the recipient will come to exact state of the page (a few screenfuls in and with that content visible in the viewport)? Remember, an anchor is useless if it hasn’t loaded yet (or has been co-opted by your script).

  5. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?
    In a traditional paged navigation you could jump ahead a few screens to more quickly get further down the timeline. If your approach doesn’t afford users this control, you’re wasting your users’ time and bandwidth.

  6. Does the memory footprint of the page dramatically increase after just a couple new “pages?”
    Keep your favorite memory monitoring tool open and load a few screenfuls. Then a few more. Then perhaps all. Take a look at how much memory this requires and then compare to available memory on other devices (such as smart phones). Remember that a mobile browser may reclaim memory by dumping other resources from working memory, potentially purging the rest of your site and its assets from the user’s cache, resulting in more bandwidth overhead and longer download times on subsequent pages.

  7. Is there a way to disable automatic infinite scrolling and lean on standard paging?
    Can the user easily disable the infinite scroll? Forget browser configuration acrobatics, instead look for a very visible single-click/tap option for the user to disable infinite scrolling and move on.

  8. Have you conducted any user tests?

  9. Are you satisfying a use case that has come from research or user request?

  10. Do you have any analytics/tracking to measure success?

For infinitive scrolling (more feed, articles solution on social media services), there is a new ARIA solution: role="feed". It's not perfect and it provides only a partial support for accessibility users. It requires also specific roles that we are not implemented in a grid or table component.

I recommend to read:
So You Think You’ve Built a Good Infinite Scroll
OK ARIA! Role=feed is here & it’s not ready for prime time

More about aria feed role:
ARIA: feed role, Mozilla docs
Infinite Scrolling Feed Example

Nice article about usability of infinitive scrolling:
Infinite Scroll UX Done Right: Guidelines and Best Practices

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility question Further information is requested
Projects
Status: ⏳ Waiting for input
Development

No branches or pull requests

2 participants