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
Provide notification that new page is loaded #322
Comments
Hi James, <html> is not exposed in the accessibility tree. Thus, any aria-busy attribute associated with it would be lost. The root of the accessibility tree for HTML is based on the <body> element I wrote code that used aria-busy on the body element to mitigate ReSpec's behaviour when loading from rawgit urls. In that case, aria-busy is initially 'true', but is set to 'false' when ReSpec is done. However, I didn't find the time to evaluate it. And, I suspect user agents are already firing something like a "document done" accessibility API event. Here's a link to a version of the ARIA spec that used aria-busy in this way, if it's of any use: The changes are documented here: |
@klown Do you know how I can view accessibility events which are being fired by the browsers? |
@jnurthen Partial answer: an accessibiltiy inspector. I mostly use Accerciser on GNOME/Linux, and AccProbe on Windows sometimes. I don't know what's available for events on OS X nor UIA/Windows. What browser/platform are you testing with? |
anything... I'll dig out AccProbe. |
If ARIA 1.2 is still limited to HTML Role Parity, this issue is not in scope. |
Perhaps the browser history API should be firing page load events when the page marks a new point in history. On the flip side, creating an artificial page load event when there isn't a new item in history would be confusing, and potentially cause the user to go back to where they didn't want to go. Might they lose data? They'd definitely waste time and get confused. |
@jnurthen related: https://github.com/WICG/app-history#customizations-and-consequences-of-navigation-interception edit: related to #1353 (going to put 1353 on the agenda as there is already discussion about the wicg proposal in there) |
@scottaohara might this feature be relevant for the ARIA Notification Proposal? |
@pkra possibly, i mean, the navigation-api proposal i linked to seems like where this specific sort of notification is handled. but, in lieu of that / for other similar use cases that wouldn't be appropriate for the navigation api, sure. probably useful. |
Thanks, Scott. I was mostly asking to find a connection of this very old issue with more recent activities, hoping that some resolution can be found eventually. |
Also WICG/aom#3 |
The "ScreenChanged" portion of that is most equivalent here, and is directly from: https://developer.apple.com/documentation/uikit/uiaccessibility/notification/1620198-screenchanged |
Another old ARIA issue on the same topic: #832 |
@MelSumner would you be interested in taking this on, maybe in the context of https://github.com/WICG/navigation-api/ ? |
With the increasing use of single page applications ARIA should provide a way to notify the user that a "new page" or even a significant portion of a page load has completed.
Currently applications normally have a live region which they insert a message into when the new page load is complete. This feels like a hack and there should be a better way.
Could we use aria-busy on the html element (or other document element in other languages). Changing this to true would signify to the browser (and AT) that a new page is loading and changing it to false would signify the page load is complete.
AT could then repsond to this event just like they do with conventional page loads and provide a comparable user experience.
The text was updated successfully, but these errors were encountered: