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

NVDA Screen Reader Does Not Read Text Within Modal Dialogs #4493

nvaccessAuto opened this issue Sep 26, 2014 · 14 comments

NVDA Screen Reader Does Not Read Text Within Modal Dialogs #4493

nvaccessAuto opened this issue Sep 26, 2014 · 14 comments


Copy link

@nvaccessAuto nvaccessAuto commented Sep 26, 2014

Reported by bblldeveloper on 2014-09-26 21:14
Paragraph text within modal dialogs with the role attribute set to dialog (role="dialog") is not read and is ignored by NVDA screen readers. Instead, it only gives focus on interactive focusable elements, such as form fields, links and buttons and completely skips over any paragraph text.

  • Adding a tabindex="0" to each paragraph and header tag, which is not ideal, seems to resolve the issue in IE11 and Chrome, but it does not solve the issue in Firefox Version 31.
  • Removing role="dialog" did not solve the issue.

Here is a snippet of code for the markup used for the modal dialog:

<div class="dialog dialog-info" data-bindattr-219="219" data-bindattr-220="220" aria-labelledby="dialog-header" data-bindattr-221="221" role="dialog" style="position: fixed; top: 50%; margin-top: -193px;">
   <div class="dialog-content">
      <div class="dialog-content-inner" tabindex="0">
            <h2 id="dialog-header" data-bindattr-222="222">Header Text</h2>
         <a href="#" class="dialog-link-close" data-id="close-dialog-link" title="Close dialog">
            <span id="ember2803" class="ember-view icon icon-close"></span>
         <h3 class="ember-view" tabindex="0">Header Text</h3>
             <p  class="ember-view" tabindex="0">Paragraph Text</p>
         <h3 class="ember-view" tabindex="0">Header Text</h3>
             <p id="ember2832" class="ember-view" tabindex="0">Paragraph Text</p>
         <h3 id="ember2833" class="ember-view" tabindex="0">Header Text</h3>
         <p id="ember2834" class="ember-view" tabindex="0">Paragraph Text</p>
         <div class="button-box">
            <button type="submit" data-id="close-btn" data-bindattr-224="224" data-bindattr-225="225" data-ember-action="226">
Copy link

@nvaccessAuto nvaccessAuto commented Sep 29, 2014

Comment 1 by jteh on 2014-09-29 01:30
Marking something as a dialog suggests it isn't intended to be browsed like a document, so we don't use browse mode there. However, users can force this with NVDA+space.

We never add anything to the tab order that isn't already there.

When a dialog gets focus, NVDA will report the caption/dialog text/description of the dialog. If the dialog doesn't explicitly specify this, NVDA tries to determine it using heuristics. We don't want to just read all text in a dialog, as this might cause us to arbitrarily read labels for controls. In this case, our heuristics aren't catching the text you want read. The only way to be certain that it will work as you expect is for you to explicitly specify the text that should be associated with the dialog using aria-describedby on the dialog.

Copy link

@nvaccessAuto nvaccessAuto commented Sep 30, 2014

Comment 2 by bblldeveloper on 2014-09-30 00:01
Thank you for your reply! The attribute aria-describedby was added to the dialog in an attempt to solve the issue, but it still does not work properly in Firefox version 31 on a Windows 7 machine. The screen reader reads "paragraph" or "header" depending on which element it is focusing on instead of reading the text. Do you have any further suggestions for resolving this issue?

Copy link

@nvaccessAuto nvaccessAuto commented Dec 2, 2014

Comment 3 by jteh on 2014-12-02 03:18
Please provide an updated test case (including the aria-describedby change), exact steps to reproduce the issue, exactly what you expected and what happened instead. Thanks.

Copy link

@nvaccessAuto nvaccessAuto commented Oct 26, 2015

Comment 4 by gblanc on 2015-10-26 16:44

I have a similar issue. You can use this jsfiddle to reproduce my issue with Firefox 41.0.2.

During the initial reading of the modal there is no mention of the buttons present inside the modal. Also once opened the modal is not readable with the arrow keys.

If I understand well you are omitting voluntarily the reading of the buttons.

Does that means we have to add inside the modal some description like "Press continue button to proceed" ?

Also you mention that in order to be able to read the content of the modal again you have to activate manually the browse mode using NVDA + spacebar.

Is it considered a normal behavior or do we have to change the tabindex on the modal-content to 0 for it to be accessible using the tab key ?
In this case it only read "section" when my focus get back on the modal content.
And I have to get out of the modal and get back in it to read the dialog again. Which should not happen as I will manage my focus to stay inside my modal


Copy link

@nvaccessAuto nvaccessAuto commented Oct 29, 2015

Comment 6 by jteh on 2015-10-29 03:13
If you use role="dialog", you are indicating that this should be treated like a dialog, which is not a document. In a dialog, we don't read all controls, just the description. For a simple example, try the Windows Run dialog (Windows key+r). Also, in a dialog, we don't use browse mode because, again, it's not a document.

If you want to have the content inside your dialog be treated as a document, use role="document" on a node inside the dialog. That way, NVDA will use browse mode automatically.

@nvaccessAuto nvaccessAuto added the bug label Nov 10, 2015
Copy link

@JonWhiting JonWhiting commented Feb 9, 2017

The definition for dialog has changed in ARIA 1.1

ARIA 1.0:
"A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response."

ARIA 1.1:
"A dialog is a descendant window of the primary window of a web application. For HTML pages, the primary application window is the entire web document, i.e., the body element."

This change in ARIA 1.1 reflects the way dialogs are often used on web pages. Based on this updated definition, it would make sense to NOT trigger focus mode when something has role="dialog".

This issue is currently being discussed on the WebAIM discussion list (Feb 8, 2017). This comment from Birkir Gunnarsson provides great points on this topic.

Copy link

@PratikP1 PratikP1 commented Feb 9, 2017

Copy link

@jcsteh jcsteh commented Feb 9, 2017

Copy link

@derekriemer derekriemer commented Feb 9, 2017

@feerrenrut feerrenrut added ARIA p2 labels Feb 9, 2017
Copy link

@Wildebrew Wildebrew commented Feb 9, 2017

You are right James, the cause of this problem is that authors use dialogs differently on the web. They are much more content heavy than a typical OS dialog.
I believe displaying dialogs in browse mode is typically a better experience. A case could be had for switching to application mode for role="alertdialog" but that assumes that web authors use the alertdialog role appropriately, which is something I have never seen in the wild.
I would not have the dialog role override the application role of a parent element
The ARIA spec says that the only role that overrides the browsed mode behavior of the application role is role="document".
And, yes, I share your frustration that you guys who are responsible for implementing all these behaviors for the users do not have nearly enough say in ARIA spec decisions and priorities.
Rock on!

Copy link

@Cambridgeport90 Cambridgeport90 commented Jul 7, 2017

This is still happening.

@jcsteh jcsteh added the 2017webfix label Jul 7, 2017
Copy link

@StommePoes StommePoes commented Jul 19, 2017

alertdialogs in the tutorials and examples we're using internally and giving to our devs does expect the dialog-as-application setup; regular dialogs are filled with web content. It might have been better had developers, being told by their designers to modal-all-the-things, didn't use the dialog role in the first place but just had things to let users know they were in a "modal" and leave dialogs for... dialogs. But that horse has bolted.

Re "It's worth noting that I have concerns about UX here. When a user hears
"dialog", I'd argue they should be able to expect that it behaves like any
other "dialog" they've used elsewhere; that's why we did it this way in the
first place."
I wonder: is it sensible to have what NVDA announces for web dialogs something more like "web dialog" when it encounters the "dialog" role on a web page? This can ensure people hearing "dialog" elsewhere get the expected dialog behaviour, while getting a slightly different name when encountering these documenty dialogs on the web?

Also: I agree with Derek for any explicit application roles. Assume the dev meant it everywhere, instead of checking all over the place. Devs are being strongly recommended to not use application roles anyway so I would hope it's more likely that where they are being used in new development, they're being used more correctly (and thus developers being aware of the consequences).

Copy link

@Wildebrew Wildebrew commented Jul 20, 2017

Copy link

@jcsteh jcsteh commented Jul 20, 2017

With respect, there is no need to discuss this further. I already stated in #4493 (comment) that this will be changed. We need to be pragmatic despite my concerns about consistency. It has been triaged as a p2 issue and will be addressed hopefully later this year. Locking further discussion for now.

@nvaccess nvaccess locked and limited conversation to collaborators Jul 20, 2017
@nvaccessAuto nvaccessAuto added this to the 2017.4 milestone Aug 29, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

9 participants