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

Provide notification that new page is loaded #322

Open
jnurthen opened this issue Apr 8, 2016 · 15 comments
Open

Provide notification that new page is loaded #322

jnurthen opened this issue Apr 8, 2016 · 15 comments
Labels
feature may add new concept(s) to ARIA which will require implementations or APG changes
Milestone

Comments

@jnurthen
Copy link
Member

jnurthen commented Apr 8, 2016

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.

@klown
Copy link
Contributor

klown commented Apr 8, 2016

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:
https://rawgit.com/w3c/aria/ad7005f1249fa327c768c747aa0dc0de57cd0e67/aria/aria.html

The changes are documented here:
ad7005f

@jnurthen
Copy link
Member Author

jnurthen commented Apr 8, 2016

@klown Do you know how I can view accessibility events which are being fired by the browsers?

@klown
Copy link
Contributor

klown commented Apr 8, 2016

@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?

@jnurthen
Copy link
Member Author

jnurthen commented Apr 8, 2016

anything... I'll dig out AccProbe.

@klown
Copy link
Contributor

klown commented Apr 11, 2016

@jnurthen FYI, the event table entry for aria-busy lists the events for the various AAPIs. If you're using AccProbe, you want to look for an MSSA/IA2 EVENT_OBJECT_STATECHANGE.

@cookiecrook
Copy link
Contributor

If ARIA 1.2 is still limited to HTML Role Parity, this issue is not in scope.

@jnurthen jnurthen modified the milestones: ARIA 1.2, ARIA 1.4 Aug 30, 2018
@jnurthen jnurthen added this to Needs triage in Live Region updates Mar 18, 2020
@jnurthen jnurthen moved this from Needs triage to High priority in Live Region updates May 21, 2020
@aleventhal
Copy link
Contributor

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 jnurthen removed the ARIA 1.4 label Feb 27, 2021
@scottaohara
Copy link
Member

scottaohara commented Feb 6, 2022

@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)

@pkra
Copy link
Member

pkra commented Jun 28, 2023

@scottaohara might this feature be relevant for the ARIA Notification Proposal?

@scottaohara
Copy link
Member

@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.

@pkra
Copy link
Member

pkra commented Jun 29, 2023

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.

@cookiecrook
Copy link
Contributor

Also WICG/aom#3

@cookiecrook
Copy link
Contributor

The "ScreenChanged" portion of that is most equivalent here, and is directly from: https://developer.apple.com/documentation/uikit/uiaccessibility/notification/1620198-screenchanged

@cookiecrook
Copy link
Contributor

Another old ARIA issue on the same topic: #832

@jnurthen jnurthen added feature may add new concept(s) to ARIA which will require implementations or APG changes and removed enhancement labels Sep 12, 2023
@pkra
Copy link
Member

pkra commented May 13, 2024

@MelSumner would you be interested in taking this on, maybe in the context of https://github.com/WICG/navigation-api/ ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature may add new concept(s) to ARIA which will require implementations or APG changes
Projects
Live Region updates
  
High priority
Development

No branches or pull requests

7 participants