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.

[StommePoes]

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).

[Wildebrew]

Designers often don't refer to web dialogs as dialogs. They call them overlays or lightboxes. But I constantly come across users who get confused and frustrated by NVDA going into application mode when a dialog pops up on a webpage. NVDA does not give the pop sound associated with aplication mode when a dialog opens (but it does in all other situations I believe, such as when user enters a text input field). I don't hink application mode does anything good for the user in a dialog , but it does a lot of harm to many. I still strongly advocate that NVDA remains in browse mode inside web elements with role="dialog" or "alertdialog".

…

On 7/19/17, Mallory ***@***.***> wrote: 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? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #4493 (comment)

-- Work hard. Have fun. Make history.

[jcsteh]

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.