Modal dialogs/overlays not recognized as superceding page content

[XLTechie]

I've seen other examples of this, but a recent mailing list discussion lead to this one.

Steps to reproduce:

1. In either Firefox or Brave, visit: https://www.globalplayer.com/live/smoothcountry/uk/
2. Move up and down with arrow keys, and also explore with the H and B browse mode commands and their shifted alternates.
3. Find and attempt to press one of the two play buttons.

Actual behavior:

You will find that you can't. The text under the first heading contains three buttons: create account, sign in, and maybe later. You must press one of these three buttons before other elements of the page will work.

A sighted user reported that the text after the first heading is actually an overlay dialog, which--for a mouse user--captures the pointer and does not allow actions on the play button, or other controls of that page.

Expected behavior:

NVDA should indicate that the text is a dialog, and that the user must interact with it before accessing the page. It should not allow interaction with, or even discovery of, the content being overlaid.

System configuration

NVDA

Installed, alpha-21656,90c37874

Windows version:

2004 (OS Build 19041.746)

Name and version of other software in use when reproducing the issue:

Firefox 84.0.2 (64-bit) Brave 1.19.86 Chromium: 88.0.4324.96 (Official Build) (64-bit)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes, presumably. Will edit if that proves incorrect.

Have you tried any other versions of NVDA? If so, please report their behaviors.

No.

If addons are disabled, is your problem still occuring?

Yes.

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Yes.

[Brian1Gaff]

I've seen similar things on Waterfox when you need to have logged in to access the content, but it is still visible,yet no action is allowed on the buttons etc. Its as if the controls were made visible by the screenreader when in fact to the sighted they are seen as not operative until after a log in. Unfortunately not got a page address but some forums and some interactive council web sites are like this. Brian

bglists@blueyonder.co.uk Sent via blueyonder. Please address personal E-mail to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field. Newsgroup monitored: alt.comp.blind-users ----- Original Message ----- From: "Luke Davis" notifications@github.com To: "nvaccess/nvda" nvda@noreply.github.com Cc: "Subscribed" subscribed@noreply.github.com Sent: Saturday, January 23, 2021 8:21 AM Subject: [nvaccess/nvda] Modal dialogs/overlays not recognized as superceding page content (#12009)

I've seen other examples of this, but a recent mailing list discussion lead to this one.

Steps to reproduce:

1. In either Firefox or Brave, visit: https://www.globalplayer.com/live/smoothcountry/uk/
2. Move up and down with arrow keys, and also explore with the H and B browse mode commands and their shifted alternates.
3. Find and attempt to press one of the two play buttons.

Actual behavior:

You will find that you can't. The text under the first heading contains three buttons: create account, sign in, and maybe later. You must press one of these three buttons before other elements of the page will work.

A sighted user reported that the text after the first heading is actually an overlay dialog, which--for a mouse user--captures the pointer and does not allow actions on the play button, or other controls of that page.

Expected behavior:

NVDA should indicate that the text is a dialog, and that the user must interact with it before accessing the page. It should not allow interaction with, or even discovery of, the content being overlaid.

System configuration

NVDA

Installed, alpha-21656,90c37874

Windows version:

2004 (OS Build 19041.746)

Name and version of other software in use when reproducing the issue:

Firefox 84.0.2 (64-bit) Brave 1.19.86 Chromium: 88.0.4324.96 (Official Build) (64-bit)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes, presumably. Will edit if that proves incorrect.

Have you tried any other versions of NVDA? If so, please report their

behaviors.

No.

If addons are disabled, is your problem still occuring?

Yes.

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Yes.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/12009

[britechguy]

I have tried this page with NVDA under Firefox, Brave, and now Vivaldi (just for kicks) and can confirm that the overlay dialog/modal dialog is not being handled as I would expect. When something like this comes up a sighted user such as myself instantly recognizes that we must interact with it in some way to dismiss it (whether by going through a sign-in, sign-up, or "maybe later" dismissal) before I can possibly interact with the underlying content on the webpage.

I would expect this sort of dialog on a webpage to be handled analogously to dialogs in programs that will not allow you to interact with the underlying program functions until that dialog has been dismissed.

NVDA is not trapping the user within this dialog, which I think it should, forcing them to interact in the way of their choosing that would allow it to be eventually dismissed and focus then returned to the underlying webpage.

By the way, I'm using the latest versions of all noted browsers and NVDA 2020.4beta1

[Adriani90]

@XLTechie in this case the web author should actually put a "not available" atribute on buttons that cannot be activated unless the requests in the dialog are followed. The design of the website might have changed now, NVDA reports that there is a dialog at the very top of the page and I can press enter on the dialog and read the message "sign in before using ..."

Is this sufficient to close this issue?

[britechguy]

I just tested this under Edge Dev, Firefox, and Vivaldi again. The behavior is different among those browsers, and I was using an NVDA Alpha I just installed last night for testing purposes.

Edge Dev still does not recognize that modal dialog and NVDA's focus remains on the main page and its controls. If a test is wanted with 2023.1 I can do so after I have the chance to reinstall it.

[XLTechie]

@britechguy

If a test is wanted with 2023.1 I can do so after I have the chance to reinstall it.

I don't see any value in testing with the stable version as opposed to the upcoming version, as nothing has been altered in NVDA regarding this between the two AFAIK.

[XLTechie]

@Adriani90 I agree that there is a web authoring problem here, that was clear from the start. However, the overarching difficulty is the same: a dialog appears that expects the user to interact with it. NVDA does not indicate this to the user at any time. Yes, if you know it appears, and you go hunting for it with Shift+o, you will find it, but shouldn't NVDA alert the user that the dialog has shown up in the document?

Moreover, since to the mouse user this dialog acquires and keeps focus until it is dismissed, shouldn't NVDA have some analogous reaction?

This is a sample site, and maybe it isn't the best example, but I have observed this behavior on countless others.

Having just tested this in Firefox 111.0.1, after pressing one of the play buttons, nothing happens. No notice of a dialog being available; no movement of focus to, or expansion of, the dialog which now evidently has visual focus. CC @jcsteh

[jcsteh]

I think it's probably reasonable for NVDA to indicate that a dialog has opened somehow, especially since there are also modeless dialogs which deliberately don't block other actions. It is only possible for NVDA to reliably detect this if the dialog has role="dialog", though, and there's no guarantee that will be the case where poor authoring is at play.

I can't think of any way NVDA could detect whether the dialog is modal or not, so it wouldn't be able to behave accordingly; i.e. focusing it and refusing access to the rest of the page.

There are many ways code could prevent the user from accessing other parts of the page. I don't see a way NVDA could reliably detect all of these.

[Adriani90]

Yeah I also think even if NVDA could recognize that there is a dialog on the page after page has loaded and announces it withouth the focus being redirected, it is still not possible to assign a priority for a specific dialog. There are websites which often have more than one dialog on one page and it depends on how far you scroll down the page, there could be two or three dialogs which require interaction before being able to interact with the page itself.

I think developing really stable heuristics for this could be hard. i.e. it could help assessing how much of the screen interface in cm^2 or what ever is overtaken by a role=dialog or <dialog>tag and redirect the focus there when building the virtual document depending on a certain threshold for the interface overtaken by the dialog, regardless of its atribute modal or non modal. The css properties should give enough information of its foreground and appearance like width and height But this could require a lot of ressources and might not be possible at all. However it would be really interesting to test a propotype on something like that.

In my browsing habit it is kind of usual to check from time to time with o or shift+o whether there is a modal dialog or not. But this is a fragile workaround though.

However, what NVDA could probably do is to kind of scan the html code when loading a page and building the virtual document, look for role="dialog" and <dialog> tag and count them to a number which iss reported after the page has been loaded and the virtual document has been built ("page with x dialogs has been loaded"). This could at least minimize the situations in which people don't know there is a dialog. See also this discussion on role=dialog and <dialog>tag. https://github.com/w3c/aria/issues/1421

This kind of code scanning when building the virtual document could be applied to other elements as well if fully implemented (i.e. regions, landmarks and separators), but I don't have an idea of the effects this could have on performance.

Jaws had a similar feature when loading web pages but they exagerated with that analytic approach and it often impacted performance, at least this was my experience when I was using it. But this does not mean that NVDA would suffer of the same issues.

[XLTechie]

@Adriani90 While I generally agree with you, my main concern in this issue particularly, is dialogs that appear after the page has loaded.

So, you do your o/O scan for dialogs, then you do something with the page that causes a new dialog to appear, such as is the case with the page in this issue. But currently, NVDA gives no indication at all that this has happened, and from the user POV, the virtual document is not reloaded.

While indicating dialogs in general is important, the most important ones are those that appear in response to user action, that the user knows nothing about unless he knows to search for it after the action.

Leaving aside the "how" to implement it, what would be a good speech/braille way of presenting that information at time of event?

I have been thinking a high-priority spoken message, along the lines of "Page has new pop-up", although I'm not satisfied with that wording.

We could eventually get to a browse mode option to automatically move focus to newly created dialogs, but that is later.

[jcsteh]

Yeah, I'm fairly sure most dialogs, even the ones that appear pretty early, are still pop-ups; they appear after the page finishes loading and thus after the initial buffer has been built. So, I don't think including them in a page summary or the like is going to work.

Auto focusing new dialogs is risky because they might not be modal. In that case, they shouldn't intrude on the user's current interaction.

[Adriani90]

Auto focusing new dialogs is risky because they might not be modal. In that case, they shouldn't intrude on the user's current interaction.

Yeah I agree, unless they are really distracting visually by overtaking a lot of the screen surface. In that case, I would say it is legitimate to move the focus automatically let's say at the top of the dialog, if the dialog occupies more than x% of the screen surface, regardless whether it is modal or not. However, I doubt NVDA could measure such things in the background continuously by reading CSS properties for dialog size without breaking performance.

A sighted person for example recognizes imediately a modal or non-modal dialog when it distracts visually and can close or hide it instantly. Although I think a web author which wants to distract visually by adding a dialog probably wants the user to interact with it in some way.

When working together with sighted people, they often see dialogs that appear in foreground an I don't have a clue about them or how to reach them very fast, especially if they are not modal. It is really difficult to handle this with the current approach in NVDA, especially when holding a presentation or so.

cc: @leonardder any thoughts on this?

[jcsteh]

To be clear, my recommendation is that we start with a message informing the user that a dialog has appeared if it doesn't get focus, wording to be determined. That seems like the most important piece of missing functionality, since the user can then choose to interact with they wish. It also mitigates risk, since the user can also choose to ignore it. Heuristics to auto focus could potentially be investigated later, but I don't think we should block this on that, as auto focusing is more risky.

[Adriani90]

That sounds reasonable. In fact, maybe we could also think about using speech refactor in this case and play a sound when a dialog appears, or at least make it configurable if a sound should be played or a message should be reported.

[britechguy]

I will also chime in, as a sighted user, that when these things come up and overlay most or all of a page, sighted users are pretty much forced to interact with these things in order to get back to the underlying webpage.

When I've done the testing I've done with this, it is really peculiar to see the screen reader being able to interact with things literally not seen. I know what's going on, but were a screen reader user and an average sighted user working together they'd be entirely lost and confused about what's happening. Although I know that the sighted are not the target demographic for a screen reader, I consider screen readers (not just NVDA) to be collaboration tools as much as strict accessibility tools, and it's helpful if all sitting around the screen are, literally, "on the same page."

[jcsteh]

That's reasonable, but the problem is that we don't have a reliable way to detect when a dialog is modal (forces interaction) vs non-modal. There are probably heuristics that can be used (does the dialog consume most of the screen, etc.), but they're not reliable (risk of false positives). For example, even with the size heuristic, it's possible that the so-called "dialog" is transparent, has a lower z-index, etc. because it isn't actually intended to be visible yet. The key point is that if the author failed to implement correct focus behaviour, they likely failed in some other way as well, so any heuristics are suspect.

[XLTechie]

@jcsteh wrote:

To be clear, my recommendation is that we start with a message informing the user that a dialog has appeared if it doesn't get focus, wording to be determined. That seems like the most important piece of missing functionality, since the user can then choose to interact with they wish. It also mitigates risk, since the user can also choose to ignore it. Heuristics to auto focus could potentially be investigated later, but I don't think we should block this on that, as this is more risky.

At the moment, that seems to be the best we can do. If we can solve the critical (IMO) bug that users don't even know that these dialogs show up in response to actions, we are already a significant step further along.

Next priority in my opinion, would be telling the user how to get to the dialog. That is: is it up, is it down, is it at? In relation to the current focus location.

Third priority, and a distant one given its complexity and potential impossibility, would have to be replicating the sighted user experience that @britechguy talks about. Not that I think it's any less important to do that--it was my original hope with this issue, after all--but it is evident that we may not be able to with any reliability.

One thing I will point out, is that while the totally reliant screen reader user should be our first design target, magnification users or the partially sighted are a factor to keep in mind. So replicating the sighted experience does have some significant weight. @britechguy mentioned the confusion resulting from a sighted and blind user working together in such a situation, but it would be equal, I suspect, for a partially sighted magnification user trying to understand what is going on in one of these.