search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
645 stars 125 forks source link

Provide notification that new page is loaded #322

Open jnurthen opened 8 years ago

jnurthen commented 8 years ago

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 commented 8 years ago

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

jnurthen commented 8 years ago

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

klown commented 8 years ago

@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 commented 8 years ago

anything... I'll dig out AccProbe.

klown commented 8 years ago

@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 commented 7 years ago

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

aleventhal commented 4 years ago

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.

scottaohara commented 2 years ago

@jnurthen related: https://github.com/WICG/app-history#customizations-and-consequences-of-navigation-interception

edit: related to https://github.com/w3c/aria/issues/1353 (going to put 1353 on the agenda as there is already discussion about the wicg proposal in there)

pkra commented 1 year ago

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

scottaohara commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

Also https://github.com/WICG/aom/issues/3

cookiecrook commented 1 year ago

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

cookiecrook commented 1 year ago

Another old ARIA issue on the same topic: https://github.com/w3c/aria/issues/832

pkra commented 5 months ago

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

MelSumner commented 4 months ago

@pkra I wonder if it's even an issue anymore once navigation-api is standard and available for use in all browsers? I need to check but I think we've been around this particular mountain a few times.

scottaohara commented 3 months ago

largely we were looking for confirmation that this would be handled by the navigation api as it's been spec'd. Unless i've missed it, i haven't seen anything overtly what browsers are to do for AT to pick up on when the web page navigates to the new 'page'. but testing this in chromium browsers with jaws, nvda and narrator, it seems that each handles the navigation slightly differently. JAWS is rather close if not the same as if a standard navigation to a new web page took place - while nvda and narrator have some differences. But seems to me this may well just be AT that need to get in sync, rather than anything with the API?