Author-registered shortcuts for loading more content

[atanassov]

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.

[cookiecrook]

Scenarios I think we agree we're trying to solve are:

1. Loading more of any type of content… whether "previous" content or "next" content in DOM order. The "feed" problem. I get to the end of the Twitter infinite scroller using AT, how does the AT consistently "load more" in regular scroll views or custom scroll views?

2. Loading a specific type of content that is in the localized, logical, content flow order: e.g. next/prev heading, next/prev link, next/prev table. Many types of AT, especially screen readers, have this functionality built-in, but it doesn't currently work with XHR-loaded web views... It only works with the headings/links/tables that are already rendered in the DOM. Note: This should work with RTL content (Hebrew/Arabic) and vertical content (e.g. certain Japanese type layouts are TTB/RTL compare to the more common Western LTR/TTB)

3. Some more specialized views (Maps, or drawing canvases, for example) that have directional orders (and potentially depth or zoom direction) instead of localized, logical content flow orders. These may be out-of-scope for a first implementation.

[cookiecrook]

Some of the ideas spitballed in the call today (attendees Meredith, Rossen, me) were:

Note: All syntax very loose and TBD.

1. Declarative attribute approach.

{on the server side <h1> Heading 1 </h1> <h2> Heading 2 </h2> etc.}

<div aria-virtualcontent="block-end HEADING Meta+h, block-start HEADING Meta+Shift+h">
   <h1>Heading 3</h1>
   ...
    <h2>Heading 4</h2>
   ...
</div>

{on the server side <h1> Heading 5 </h1> etc.}

2. JavaScript Registration linking an AT's interface to a simulated keyboard shortcut. E.g. an iOS VoiceOver user might select the heading rotor, and swipe down, which would then simulate these keyboard shortcuts on the web element.

/* register these only if the web app "knows" there is more of this content
   in the model that is not yet rendered in view. */
element.accessibility.registerAction('nextHeading', 'Meta+h');
element.accessibility.registerAction('prevHeading', 'Meta+Shift+h');

/* Once all remaining headings have been loaded, unregister the hotkey
   so normal AT navigation can resume. */
element.accessibility.unregisterAction('nextHeading');

3. A document heading markup registration... e.g. <meta>

[cookiecrook]

Note: Acknowledged that each of these spitballed approaches has potential privacy implications...

[atanassov]

Arguably, Scenario 1 is the most privacy preserving path forward and the rest of them are various levels of regression.

[cookiecrook]

Scenario 1 also yields the least desirable user experience IMO. I could only see it being a viable path for a general "load more" function, not the other stated goals like "next heading," "next table," etc.

[cookiecrook]

FYI https://github.com/NavidZ/overscroll-scrollend-events

[atanassov]

Scenario 1 also yields the least desirable user experience IMO. I could only see it being a viable path for a general "load more" function, not the other stated goals like "next heading," "next table," etc.

This is covering the 80% scenario, which is "load more" type of problem today. The advanced apps that use various ways to hide and hijack controls could be addressed through the JS proposal of scenario 2.