NVDA Screen Reader Does Not Read Text Within Modal Dialogs

[nvaccessAuto]

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">
         <header>
            <h2 id="dialog-header" data-bindattr-222="222">Header Text</h2>
         </header>
         <a href="#" class="dialog-link-close" data-id="close-dialog-link" title="Close dialog">
            <span id="ember2803" class="ember-view icon icon-close"></span>
         </a>
         <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">
               <span>Close</span>
            </button>
         </div>
      </div>
   </div>
</div>

[nvaccessAuto]

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.

[nvaccessAuto]

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?

[nvaccessAuto]

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.

[nvaccessAuto]

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

I have a similar issue. You can use this jsfiddle http://jsfiddle.net/qey5tdb6/4/ 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

Regards.

[nvaccessAuto]

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.

[JonWhiting]

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."
https://www.w3.org/TR/wai-aria/roles#dialog

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."
https://www.w3.org/TR/wai-aria-1.1/#dialog

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.

[PratikP1]

Based on this new definition as well as practical experience with ARIA-dialog, I urge this change. It is rare that the focus mode is appropriate. Developers insist on using modal dialogs for multiple purposes. The only category of web sites or apps where dialog seems to be used as dialogs are online food ordering sites. The auto focus mode results in confusion and unnecessary extra keystroke. This has come through several usability studies I have conducted now. My normal question when developers use modal dialogs is whether there is a business case for using them. In most cases, I can say with a fair bit of certainty that there is such a business case and not simply as a typical dialog box with all that it implies.

[jcsteh]

This is definitely on the roadmap for 2017 as part of our ARIA 1.1 work. 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. That is, normally, you can't read a dialog like a document; you can't use the cursor keys to move line by line, you can't use single letter navigation, etc. This change breaks that consistency. When a user hears "document", they know they can expect to do these things, but not "dialog". Even if users do get used to this, they'll then possibly expect dialogs everywhere else to work like this, but they won't. Either way, it's inconsistent. "The web is different" is not a good enough argument for inconsistent UX IMO. That said, I agree we need to be pragmatic here: this is how it's being used in the wild. Essentially, we must sacrifice consistency for pragmatism, which is not ideal. There's one open question: what if a dialog is encountered inside a role="application"? Should we switch to browse mode or not? If we're changing the definition of dialog on the web to say it acts like a document, that would suggest we should. However, some might argue that breaks the idea of role="application". There are also performance concerns here: if we need to check whether there is a parent document to decide whether to enable browse mode for a dialog, we're potentially going to have to walk the entire ancestry of the dialog. That is hideous from a performance perspective. As is more often the case with ARIA than I'd like, I feel like consistency, edge cases and implementation weren't given sufficient consideration, if any at all. That in turn results in ugly confusion like this when it comes to implementation time.

[derekriemer]

If its in an application, I would say, unless there's a document inside the dialog, we should go focus mode.

…

On Wed, Feb 8, 2017 at 7:42 PM, James Teh ***@***.***> wrote: This is definitely on the roadmap for 2017 as part of our ARIA 1.1 work. 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. That is, normally, you can't read a dialog like a document; you can't use the cursor keys to move line by line, you can't use single letter navigation, etc. This change breaks that consistency. When a user hears "document", they know they can expect to do these things, but not "dialog". Even if users do get used to this, they'll then possibly expect dialogs everywhere else to work like this, but they won't. Either way, it's inconsistent. "The web is different" is not a good enough argument for inconsistent UX IMO. That said, I agree we need to be pragmatic here: this is how it's being used in the wild. Essentially, we must sacrifice consistency for pragmatism, which is not ideal. There's one open question: what if a dialog is encountered inside a role="application"? Should we switch to browse mode or not? If we're changing the definition of dialog on the web to say it acts like a document, that would suggest we should. However, some might argue that breaks the idea of role="application". There are also performance concerns here: if we need to check whether there is a parent document to decide whether to enable browse mode for a dialog, we're potentially going to have to walk the entire ancestry of the dialog. That is hideous from a performance perspective. As is more often the case with ARIA than I'd like, I feel like consistency, edge cases and implementation weren't given sufficient consideration, if any at all. That in turn results in ugly confusion like this when it comes to implementation time. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4493 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivb1ZuN1dLSyzoc_N1OluZIITkUTuks5ran0kgaJpZM4L7jM5> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[Wildebrew]

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!

[Cambridgeport90]

This is still happening.