alice
commented
4 years ago @cookiecrook was musing on one potential direction for this (as food for thought, as opposed to being confident this is a viable direction specifically):
<!-- (these buttons could be hidden or visibly displayed.) -->
<!-- author must also register keyup/keydown/keypress/click handlers -->
<button rel="next" aria-keyshortcuts="j">Next article</button>
<button rel="prev" aria-keyshortcuts="k">Previous article</button>Then, Rossen suggested browsers could add a feature that would display the registered list (e.g. maybe the heuristic is any that had a rel and aria-keyshortcuts?) to the users. iPad UI shows something similar if you have a keyboard connected and you hold the Command key for about 1 second.
Something like this:
Then the user could see the shortcuts registered by the current page (presumably along with any others defined by the browser) and this becomes a mainstream feature, not limited to AT.
If adoption of this ^ is successful, it may be reasonable to move forward with more link rel extension vocabulary like “nextheading” and “prevheading”...
robdodson
Malvoz
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.