I used to be constructing a Modal element that makes use of the component’s showModal technique. Whereas testing the element, I found I might tab out of the (in modal mode) and onto the deal with bar.
And I used to be shocked — accessibility recommendation round modals have generally taught us to entice focus inside the modal. So this appears mistaken to me.
Upon additional analysis, it looks as if we now not have to entice focus inside the (even in modal mode). So, the focus-trapping is deprecated recommendation when you use .
Some notes for you
As an alternative of asking you to learn by means of your complete GitHub Challenge detailing the dialogue, I summarized a few key factors from notable individuals under.
Listed here are some feedback from Scott O’Hara that tells us in regards to the historical past and context of the focus-trapping recommendation:
WCAG is not normatively stating focus should be trapped inside a dialog. Slightly, the normative WCAG spec makes zero point out of necessities for focus conduct in a dialog.
The informative 2.4.3 focus order understanding doc does discuss limiting focus conduct inside a dialog – however once more, that is within the context of a scripted customized dialog and was written lengthy earlier than
inertorhave been extensively accessible.The aim of the APG is to show tips on how to use ARIA. And, with out utilizing native HTML options like
orinert, it’s far simpler to entice focus inside the customized dialog than it’s to attain the conduct that thecomponent has.Each the APG modal dialog and the WCAG understanding doc have been written lengthy earlier than the
inertattribute or thecomponent have been extensively supported. And, the choice to instructing builders to entice focus within the dialog would have been to inform them that they wanted to make sure that all focusable parts within the internet web page, exterior of the modal dialog, obtained atabindex=-1.
Léonie Watson weighs in and explains why it’s okay for a screen-reader consumer to maneuver focus to the deal with bar:
Within the web page context you possibly can select to Tab out of the underside and across the browser chrome, you should utilize a keyboard command to maneuver straight to the deal with bar or open a specific menu, you possibly can shut the tab, and so forth. This offers individuals a alternative about how, why, and what they do to flee out of the context.
It appears logical (to me no less than) for a similar choices to be accessible to individuals when in a dialog context as an alternative of a web page context.
Lastly, Matatk shared the conclusion from the W3C’s Accessible Platform Architectures (APA) Working Group that okay-ed the notion that ‘s showModal technique doesn’t have to entice focus.
We addressed this query in the middle of a number of APA conferences and got here to the conclusion that the present conduct of the native dialog component must be saved as it’s. So, which you could tab from the dialog to the browser functionalities.
We see particularly the profit that keyboard customers can, for instance, open a brand new tab to look one thing essential up or to vary a browser setting this manner. On the similar time, the dialog component thus offers an extra pure escape mechanism (i.e. shifting to the deal with bar) in, for instance, kiosk conditions the place the consumer can’t use different commonplace keyboard shortcuts.
From what I’m studying, it appears like we don’t have to fret about focus trapping if we’re correctly utilizing the Dialog API’s showModal technique!
Hope this information make it simpler so that you can construct parts. 😉
