aria-modal(property)

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:

  1. Assistive technologies do not expose the background content
  2. User navigation is limited to the modal elements itself
  3. 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

 

 

5 Replies to “aria-modal(property)”

  1. 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?

  2. 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?
    <>
    Does the spec imply that AT should parse authors js code to determine if activeElement is managed by the author?
    <>
    Hope this helps.

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

Leave a Reply

Your email address will not be published. Required fields are marked *