FreedomScientific
JAWS still exposes document elements when aria-modal dialog is open
Summary
Following up on testing #91, the virtual cursor and hot keys are limited to navigating the contents of a role=dialog when it has the attribute aria-modal=true. However, a user still has full access to the elements in the base document if interacting with the various JAWS element dialogs.
- Go to ARIA Practices modal dialog example
- Go to the first button, 'Add delivery address' and activate to launch the dialog.
- Escape forms mode and open JAWS's listing of elements (e.g. Insert + f6 or f7)
- Note that all elements beneath the modal dialog are still listed.
Expected result
Expected that elements beneath the modal dialog would be hidden from JAWS while the modal dialog remained active.
Actual result
Can access links, headings, and various other elements of the base document if opening their respective JAWS element dialog modals (e.g. Insert + F6).
Example
http://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
Additional Information
FWIW, NVDA 2018.4.1 does not list any elements within their elements dialog, aside from those within the opened modal dialog.
VoiceOver on macOS 10.14.3 with Safari work similarly to JAWS 2019, in that the VoiceOver rotor also exposes elements beneath the modal dialog.
JAWS version and build number
JAWS 2019 (latest build as of March 2019)
Operating System and version
Windows 10
Browser and version:
IE11, Firefox 65.0.2, Chrome 72
July 2019 update 1 - Issue still present, tested with JAWS 2019.1904, IE11, Firefox 67 and Chrome 75
2 - While waiting for this issue to be resolved, a workaround using aria-hidden cab be applied as follows:
Example code (elided): Using aria-hidden.
When dialog is visible set aria-hidden="true" on the container element for any non-dialog content.
<body>
<div aria-hidden="true">
<!-- page content not in modal dialog -->
</div>
<div role="dialog" aria-modal="true" ... class="visible">
<!-- dialog content -->
</div>
</body>
When a dialog is not visible set aria-hidden="false", or remove the attribute, on the container element for any non-dialog content:
<body>
<div aria-hidden="false">
<!-- page content not in modal dialog -->
</div>
<div role="dialog" aria-modal="true" ... class="hidden">
<!-- dialog content -->
</div>
</body>
Unrelated to the JAWS Insert f6/f7 issue, but good to know. An additional step is needed to help trap focus in Safari v12 or newer. The inert polyfill helps prevent Voice Over arrow key navigation outside the modal dialog in the Safari browser.
The aria-hidden technique only works if the dialog contents is not a child of the DOM node that hosts the aria-hidden attribute. The technique is detrimental if a dialog is invoked or injected into the content as a child node. The
i have yet to see evidence of increasing support (for the dialog element), nor is the current implementation in chromium based browsers flawless.
As mentioned, the inert attribute / polyfill is probably one of the best bets to implement modal dialogs with proper focusing/hiding of content in the primary document. Even were JAWS to fill the gap in the aria-modal support, the attribute by itself does nothing to help those not using a screen reader from escaping a dialog with the tab key, as is the intent of ARIA attributes to not actually modify default browser behavior.
The problem with aria-modal is not solved in IE 11. In the example https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html aria-modal=true or aria-modal=false has no effect on the output. Decisive is the role=dialog, which limits linear reading to the pop-up. If role=dialog is removed, the whole page can also be read with aria-modal=true. Therefore the https://github.com/FreedomScientific/VFO-standards-support/issues/91 should be opened again.
Hi do we have any update on this. aria-modal still exposes background elements when dialogs are open with JAWS 2019. Browser used for testing is Chrome 81. NVDA 2019 seems to support aria-modal.
Hello, do we have any update on this ? JAWS is still reading behind the modal though aria-hidden is set to true on the background.
@monika007: Do you mean aria-hidden or aria-modal? aria-hidden should work reliably in any browser with JAWS
@JAWS-test , I mean aria-hidden. I have aria-modal set to true on my modal. According to the documentation, background should not be accessible by having aria-hidden set to true on the background when the modal is open. But that isn't working for me. JAWS is reading all the fields behind the modal after it finishes reading the fields in the modal.
@monika007 this may be another issue then, especially if you are attempting to use both aria-hidden=true on the background content an aria-modal=true on the dialog element itself.
please provide an example for further investigation, because based on what you're describing right now, this doesn't meet expectations.
We are also seeing this issue. Pop-up a modal, background is disabled the modal has role="dialog" and aria-modal="true" but background elements are still being read.
Is there any update on this? I am facing the same issue. JAWS shortcuts exposes the content behind the modal when it is open. From the discussion above, I see using inert polyfill or using aria-hidden on the background content, the problem could be solved. However, I wanted to understand if there is any other way and whether this issue has been resolved from JAWS end.
hi sumitnaik-mck,
The issue surfaced again on some audits this week, and i've asked JAWS people to relook at again, but as far as I know, there has not been any progress on this, other than the prior work arounds.
Sorry I can't be more precise. Mark
Reported as Bug 132765 {(ST179) JAWS still exposes document elements when aria-modal dialog is open}.
@BrettLewisVispero this bug was reported 4 years ago, raised internally 15 months ago (https://github.com/FreedomScientific/standards-support/issues/179#issuecomment-1218388554), it is still evident in JAWS 2024
Testing this with JAWS 2024.2403.3 / Chrome 124.0.6367.92, this appears to be partially fixed...
The following all now appear to be working well and only include elements from the modal dialog:
- INSERT+F5/6/7
- CTRL+INSERT+B/X/T/F
However, I found the following is unfortunately still not working, and does still include non-modal elements:
- CTRL+INSERT+R (landmarks)
Does anyone know if fixing the landmark summary is also in the pipeline?
Thanks, Anthony
