wicg / accessible-loading-and-searching-of-content

Enable ATs to recognize and account for virtualized content when navigating a web page.

ARIA Virtual Content

This effort aims to create a privacy-preserving path for ATs to recognize and account for virtualized content (on the server side) when navigating web content.

Editors:

• Kevin Babbitt, Microsoft, [email protected]
• Rossen Atanassov, Microsoft, [email protected]

Details

Read the Explainer

accessible-loading-and-searching-of-content's Issues

Consider way to gain access to structural info without requiring scrolling

ATs often pull details such as the heading structure on a page or section of a page so they can present the number and depth of headings without actually having the user navigate by heading. It would be useful to perhaps query for this information without causing a visual change that might impact sighted users of assistive technology.

Has this incubation stalled?

Checking for status of this incubation. There appears to have been little activity in the last few years so wondering if this repository can be archived?

Unless anyone objects, we will archive this in a week or so.

Author-registered shortcuts for loading more content

In review of more app scenarios there appears to be a clear need for a mechanism that allows authors to register shortcuts or actions that can be fired by ATs in order to load more virtualized content.

The default behavior of loading content, as specified by the proposal, is for an AT to trigger scrollIntoVIew to the element marked as aria-virtualcontent. There are many advantages of this approach - author side script that's handling content loading wouldn't recognize if a scroll was triggered by AT or user (privacy); most apps that virtualize content between server/client today are already tuned to handle loading based on scroll (low author cost), etc.

However, there are use cases of input being redirected and captured by app logic in order to provide more advanced content handling. It will be helpful to enable authors to specify the shortcuts used for fetching content.

This has the potential to degrade experience when desired content is outside virtual-content container

The concern here is if the user is using the AT to search for content and that content is outside of the virtual-content element, the AT will scroll the the virtual-content region until there's no more scrolling (...what happens in infinite scrolling cases...) before searching outside of the virtual-content element.

This could result in poor performance and overall experience for the user, and in the worst case, like infinite scrolling, the user could become "suck" in the virtual-content element

Consider changing the name of the incubation effort repo

Can we change the name of the repo to something more agnostic, like “accessible loading or searching of content”? Leaving the repo titled with the proposed solution limits the flexibility of an incubation effort. Even if we all agreed on a declarative approach, there were specific concerns with the term "virtual" as people though it might be related to virtual reality (VR) interfaces, or associated with the AOM effort to load a virtual accessibility tree for HTML <canvas> or other custom views.

In addition to the proposed declarative approach (specifically “aria-virtualcontent” or other ones we discussed), there was chatter that this might be solved a number of other ways. For example, common AT actions (like jump to next heading) could be mapped to web-app-specific commands (opt-h?). There are probably a number of other ways to solve these problems, including new JavaScript API.

Additional privacy-preserving ways to fetch content

Essentially re-stating #4: can we come up with ways to provide AT users with familiar interactions like find in page and go to next heading, in such a way that the use of AT is not revealed to the page?

This might look like providing well-known, or author-registerable, keyboard shortcuts for a specific vocabulary of actions.

For example, if "Ctrl Alt H" was a well known keyboard shortcut to go to the next heading, a non-AT user could hit that shortcut to signal to the page to fetch content through the next heading. Conversely, an AT user could use their normal "go to next heading" interaction with the AT, and the browser could forward that intent as a keyboard event combination to the page, making it indistinguishable to the page whether or not an AT was used.