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 |
jnurthen
added
feature
|
@MelSumner would you be interested in taking this on, maybe in the context of https://github.com/WICG/navigation-api/ ? |
* update allowance column update role descendant allowances. update “kind of content” column to reflect HTML kind of content categories for elements with implict matching roles. These do not always have a 1-to-1 match as there are variants in what ARIA might allow vs the native HTML element. Additionally, content model categories like sectioning root, or labelable elements, etc. were purposfully left off as the ARIA roles do not automatically come with the features associated with these categories. * update placeholder link in changelog * additional wording updates add informative label to this section. revise wording to remove normative "must not" since we need this section to be informative at this time. provide additional wording regarding the roles that indicate to review the 'Required Owned Elements' as specified in ARIA * fix typo on column number
* clarify img naming steps related to w3c/accname#27 * remove reference to note that’s no longer there add in new note as a reminder that `alt=“”` means the `img` is meant to be exposed as role=presentation
|
@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. |
|
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? |
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: