Provide guidance for handling focus when simulated page loads happen for single page applications.
#4400
Replies: 1 comment
-
|
I came across a community draft of a new API (it doesn’t yet exist in JavaScript, and it may never exist) which would be perfect for addressing this problem — the AppHistory API. One problem it’s attempting to address:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Is your feature request related to a problem? Please describe.
When performing full-page navigations in single page applications, screen readers have no default indication of the page load. This leaves a question — what should happen?
There are two leading approaches being considered by framework developers —
Immediate user research isn’t always possible due to feature prioritization, leaving developers with a choice to validate later with user research. This is the situation that @kkoskelin has currently, when addressing focus changes for https://dawson.ustaxcourt.gov/.
Describe the solution you'd like
I’d like USWDS (or another trusted government agency site) to provide user-research backed guidance on how to handle page navigation events in single page applications. That would enable the mission of being the most accessible by default until the next round of user research can validate the approach.
Describe alternatives you've considered
As far as handling focus, @kkoskelin has tried:
Doing nothing. This results in screen readers not reacting to the updated content, because focus has not changed in the application.
Focusing the main content (same behavior as skip to main content). This results in an announced content change, but a potentially jarring experience as a user is moved to an unknown location on the page. On first implementation, this caused the undesirable side-effect of moving user focus to the main content without passing the skip to main content link or menu.
Focus the skip to main content link. This caused the undesirable side effect of announcing the navigation as the skip to main content link, and for sighted users, causes the skip to main content link to become visible.
Focus a focusable item before the skip to main content link. This restored the most similar to native browser load experience as far as focus order is concerned, however needs a custom announcement (aria-label or similar) added to the region to announce the content change, otherwise nothing is announced as the focused element is empty.
Do nothing on first page load, focus main content on subsequent page changes. This results in the user being presented with the skip to main content link and menus before hitting the main content on the first page load, and on subsequent loads the new content is announced.
Additional context
Application screenshot & video demo at flexion/ef-cms#7512.
Beta Was this translation helpful? Give feedback.
All reactions