Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include accessibility in the spec #25

Closed
MelSumner opened this issue Feb 5, 2021 · 3 comments
Closed

Include accessibility in the spec #25

MelSumner opened this issue Feb 5, 2021 · 3 comments
Labels
foundational Foundational open questions whose resolution may change the model dramatically

Comments

@MelSumner
Copy link

It would be good if the known needs of assistive technology were mentioned in this API, if only just to ensure that it isn’t forgotten or ignored in the inevitable edits & changes.

Thanks for considering!

@domenic
Copy link
Collaborator

domenic commented Feb 5, 2021

For tracking, a lot of the background is discussed here: w3c/aria#1353 and in this doc from @marcysutton

I'm going to work on a PR to add some initial accessibility considerations right now, and will look forward to your thoughts.

@domenic domenic added the foundational Foundational open questions whose resolution may change the model dramatically label Feb 17, 2021
@domenic
Copy link
Collaborator

domenic commented Mar 19, 2021

To give a quick status update on the work done so far and what remains:

  • There seem to be two big problems with SPA navs and accessibility that people mention over and over: telling the AT user a navigation happened, and focus management.

  • We believe telling the AT user that navigation happened slots really well into this API, with the navigate event and its respondWith() method. That is, this API has a first-class notion (much more so than history.pushState()) of telling the browser about a navigation and when it starts and ends, which the browser can then use in turn to tell AT about the navigation.

    On the Chromium side, where we've been prototyping the navigate event already, we've investigated how to implement this and want to work on prototyping the AT integration soon as well.

  • Focus management is a bit trickier. Although the app history APIs first-class notion of navigations helps here as well, there are conflicting opinions on what exactly should be done with focus on a navigation. Some developers we've talked to said that they prefer the cross-document behavior, where focus just resets to the body element, whereas others (backed by research) indicate that something more app-specific would be best.

    Maybe by default the focus should be reset to the body, but there should be an easy way for a SPA router to make a more intelligent decision? This intelligent override could either be done using app history somehow, or with a new API (like setSequentialFocusNavigationStartingPoint(), which would be independently useful) that people use together with app history.

@domenic
Copy link
Collaborator

domenic commented Nov 18, 2021

I've posted a detailed proposal for focus management during SPA navs at #190. Thoughts welcome!

domenic added a commit that referenced this issue Feb 1, 2022
Plus, expand and organize the stuff about accessibility technology announcements and loading spinners.

Closes #25. Closes #187. Closes #190.
@domenic domenic closed this as completed in 8a3d47b Feb 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
foundational Foundational open questions whose resolution may change the model dramatically
Projects
None yet
Development

No branches or pull requests

3 participants
@domenic @MelSumner and others