This method is even mentioned in the ARIA Authoring Practices design pattern for Modal dialogs. Historically, the method used to achieve the expected behavior of screen reader focus being trapped in the dialog was to apply aria-hidden='true' to elements outside of the dialog. In the case of aria-modal, developers who implement it without fully understanding how it is meant to be used, could easily render whole applications inaccessible, so I could understand why screen reader would be reluctant to implement it. For instance, most screen readers don't implement aria-label exactly to specification, only honoring it on controls that it anticipates a legitimate need for it. This does not surprise me, because screen readers are often reluctant to implement or fully implement aspects of specifications that would be easy to misapply and would cause major accessibility issues if applied incorrectly. To make sure I am up to date on support for this property, I tested it with a variety of screen readers and browsers and the only combination where I could get it to work in a consistent manner for any combination (it may work with NVDA and Chrome, but it does not appear to be consistent and I could not rule out quirks of the specific environment I was testing in). While it is true that the ARIA spec does state that aria-modal='true' should trap focus, this has been the case for a while, and I am not aware of a browser screen reader combination that has implemented it successfully. Reply to this email directly, view it on GitHub, or mute the can we consider reopening this issue? You are receiving this because you authored the thread.

A workaround solution that some users suggested is to add aria-hidden on elements that are supposed to be blocked while the Dialog is active (in our scenario, it would probably be the component wrapper, since the Modal is appended to the end of the DOM. I found a stackoverflow issue mentioning the usage of aria-modal but it doesn't seem widely supported at the moment. Dialog uses FocusTrapZone with a isClickableOutsideFocusTrap= if it's a blocking dialog, however even testing a simple FocusTrapZone with that prop set to false allows the Narrator scan mode to visit outside elements. ( or, do you have any insight on this issue? I did some digging around and I'm not sure if this is an Narrator issue, or a Fabric issue.

Subject: Re: : In scan mode, Narrator focus moves out from the dialog and lands on background elements when navigate back by 'Up' key on 'Blocking Dialog'. Cc: Arvind Prakash (HCL America Inc) Author

Ui browser screen reader