You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Contrary to a MPA generated on the server, an SPA does not need to reload for changes to be displayed on the page.
This is a problem for accessibility (a11y) since changes might not be announced/visible to screen readers etc.
One way to deal with this is to change the active element (element in focus).
Basically, a SPA can be seen as a composition/nesting of dynamic elements (outlets). Each outlet essentially defines a nested body. Either it is focusable itself or it has a focusable element.
If none applies, we can look at its parent.
That could be the element that captures focus on change, similarly to body in a MPA?
The point is to handle things such as tabbed lists gracefully. Moving the focus to the very begining is likely to be too cumbersome. As the name indicates, focus determines the locality of the user-intent, area of change.
In a sense, the identity of the currently focused element is a property of the UI state that should be recoverable between navigations. If MPA do not persist UI state by default, we have here the opportunity to do it.
We should also be able to deal with error mode where the focused item disappears in-between navigation. In that case, where should the focus go? to the closest focusable parent element?
Problem statement
Contrary to a MPA generated on the server, an SPA does not need to reload for changes to be displayed on the page.
This is a problem for accessibility (a11y) since changes might not be announced/visible to screen readers etc.
One way to deal with this is to change the active element (element in focus).
Basically, a SPA can be seen as a composition/nesting of dynamic elements (outlets). Each outlet essentially defines a nested body. Either it is focusable itself or it has a focusable element.
If none applies, we can look at its parent.
That could be the element that captures focus on change, similarly to body in a MPA?
The point is to handle things such as tabbed lists gracefully. Moving the focus to the very begining is likely to be too cumbersome. As the name indicates, focus determines the locality of the user-intent, area of change.
In a sense, the identity of the currently focused element is a property of the UI state that should be recoverable between navigations. If MPA do not persist UI state by default, we have here the opportunity to do it.
We should also be able to deal with error mode where the focused item disappears in-between navigation. In that case, where should the focus go? to the closest focusable parent element?
Ref.
https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/
https://a11y-guidelines.orange.com/en/articles/single-page-app/
http://web-accessibility.carnegiemuseums.org/code/skip-link/#content
The text was updated successfully, but these errors were encountered: