First of all, Let us understand What is a modal. Modal is something that interrupts your current work flow on your main page and usually, user navigation is limited within the modal element itself. In other words, users cannot access the background content when modal is displayed. Even though visually the background content is inert/grade out, it is high chance that screen reader users can access the background content, which is a problem.
To address this problem, what we have been doing is that we use aria-hidden=”true” attribute to hide the background content from the screen reader users. When modal is closed, we flip the aria-hidden value from true to false, so that screen reader users can access the content when they are returned to the actual web page. These are the techniques that we have been following to hide/unhide the background content from the screen reader users.
Aria 1.1 introduced the aria-modal attribute to hide the background content directly instead of using aria-hidden attribute. Authors should use aria-modal attribute in conjunction with dialog/alertdialog role. When aria-modal is set to true in the dialog/alertdialog container then the expectation is that:
- Assistive technologies do not expose the background content
- User navigation is limited to the modal elements itself
- Assistive technology should place the focus on the modal element when it is displayed unless the focus has explicitly been placed else where
all these things are being taken care automatically when aria-modal=”true” is used. Imagine’, how cool it is. Hence, we don’t need to use aria-hidden attribute any more.
Author notes
- Author should use aria-modal attribute in conjunction with dialog/alertdialog role.
- When a modal element is displayed, authors MUST ensure the interface can be controlled using only descendants of the modal element. In other words, if a modal dialog has a close button, the button should be a descendant of the dialog.
Sample code snippet
if given
<body>
<h1 id=”Test2″>Modal Dialog Box Test</h1>
<div role=”dialog” aria-modal=”true” id=”test”>
<input type=”button” value=”ok”/>
</div>
</body>
then the element with role=”dialog” and id=”test” exposes aria-modal=”true”
References
If AT does not support this new prop then we need to polyfill it with JS.
Is there a way to detect AT support?
Isn’t such [auto] behavior (making outer content inert, autofocusing etc), violates the separation between DOM and a11y tree?
Does the spec imply that AT should parse authors js code to determine if activeElement is managed by the author?
Hi Neil,> >>
great questions and here are my answers in the inline below:
If AT does not support this new prop then we need to polyfill it with JS.
Is there a way to detect AT support?
<
Isn’t such [auto] behavior (making outer content inert, autofocusing etc), violates the separation between DOM and a11y tree?
<
Does the spec imply that AT should parse authors js code to determine if activeElement is managed by the author?
<
Hope this helps.
Hi Neil,
Please let me know if you don’t see my comment
Hi Suman, I don’t see your comment
Hi Neil,
great questions and here are my answers in the inline below:
If AT does not support this new prop then we need to polyfill it with JS.
Is there a way to detect AT support?
Suman: the answer to the first part of the question is that yes, we should use java script to move the focus to the modal content till AT supports this. other part of the question is how do we understand AT supports and answer is that run screen reader on the modal and see if the parent content is not exposed. if the parent content is not exposed and there is aria-modal attribute along with the dialog role in the code then it means that it supports. here is the matrix about the same:
JAWS Supports in IE
JAWS supports in the FF
NVDA Supports in the IE
NVDA supports in the FF
Voice over support is partial in the safari
Note:
1. supports here means it fills 2 conditions(parent content is hidden for the screen reader users and user navigation is limited within the modal content during arrow key navigation) but other condition(AT should take the focus to the modal content automatically) does not fill
2. voice over hides the parent content when this attribute is set but it also hides some of the modal content, which is not correct and hence, the support is partial.
Isn’t such [auto] behavior (making outer content inert, autofocusing etc), violates the separation between DOM and a11y tree?
Suman: i don’t think so and it makes the authors life easy. in addition, accessibility API gets updated with teh aria-modal attribute and there won’t be any issue in the APIs
Does the spec imply that AT should parse authors js code to determine if activeElement is managed by the author?
yes, it clearly specifies that if the authors explicitly place the focus else where in the modal content then AT should not take the focus by it’s own and it should follow the focus where the author has set the focus
Hope this helps.