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

JAWS still exposes document elements when aria-modal dialog is open #179

Open
scottaohara opened this issue Mar 6, 2019 · 6 comments

Comments

@scottaohara
Copy link
Member

commented Mar 6, 2019

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.

  1. Go to ARIA Practices modal dialog example
  2. Go to the first button, 'Add delivery address' and activate to launch the dialog.
  3. Escape forms mode and open JAWS's listing of elements (e.g. Insert + f6 or f7)
  4. 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

@menovak menovak self-assigned this Jul 2, 2019

@menovak

This comment has been minimized.

Copy link

commented Jul 2, 2019

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>

@scottaohara

This comment has been minimized.

Copy link
Member Author

commented Jul 2, 2019

Agreed, also would recommend the inert polyfill

@menovak

This comment has been minimized.

Copy link

commented Jul 2, 2019

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.

@electronicwoft

This comment has been minimized.

Copy link

commented Jul 4, 2019

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 element is enjoying increasing support and may eliminate the need for these ARIA attributes and polyfills/hacks.

@scottaohara

This comment has been minimized.

Copy link
Member Author

commented Jul 4, 2019

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.

@JAWS-test

This comment has been minimized.

Copy link

commented Aug 24, 2019

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 #91 should be opened again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.