Accessible Modal Dialogs -- A11ycasts #19
HTML-код
- Опубликовано: 21 окт 2024
- ARIA Authoring Practices: Dialog - goo.gl/ibNKWw
eBay MIND Patterns: Dialog - goo.gl/FI5NHa
Inert Polyfill - goo.gl/nXMS1V
The accessible modal dialog. It seems like such an easy thing to build, but in reality, it's a total pain! Today on A11ycasts I'll show you how to properly manage focus when adding a dialog to the page, and how to prevent a screen reader user from accidentally escaping behind the modal. In a few short minutes you'll be up to speed and ready to ship your first full accessible dialog!
Watch all A11ycasts episodes: goo.gl/06qEUW
Subscribe to the Chrome Developers RUclips channel for updates on new episodes of A11ycasts: goo.gl/LLLNvf
Rob, can you gist it or commit it to some repo? Thanks in advance.
As well it looks like it is great to use tags for dialog and clone/append its content to document.body so it always will be at the top of the screen (no z-index issues).
Thanks Rob, great show.
One other alternative is to set focus on the element itself. As role dialog is interactive, windows SR users cant navigate the a11y tree and there for all text should be communicated through to aria-describedby attribute.
BTW, last time i checked, this inert polyfill failed to work with MS Edge
I wish you could make a full Udemy course
Was hoping to see this one covered. Thank you. I emulate bootstraps modal for a fallback. The inner Article with role of document usually gets detected by the screen reader as if it was another page.
Really like the idea of bringing back the focus to the previous active element on close, thanks :)
what about the new HTML dialog element? are these automatically applied when i use that or do i have to add them in myself
Awesome stuff!! I will think in accessibility in my next projects for sure. One question, What is the font are you using in the code editor? Thanks and cotinue bringing this essential content!
Hey, Rob. If have a video in pop-up in the CTA button, Vedio plays automatically right? As per WCAG.
Very useful component. Nice work as always, Rob. Thanks 👍
Nice explanation Rob, thanks. Just one question. Why did you not use the tag? Brings some accessibility features with it like close on ESC.
Browser implementation for those features is minimal (I'm not sure but may be just Chrome implementing them?)
Edited: Rob says near the end of the video that it's just Chrome and Opera that supports it.
Even if not all the browsers support it, that hasn't stopped us from using other features in similar situations, and given that the fallback is that the dialog behaves just like the plain divs that he's already using, I fail to see the problem to use it instead.
Thanks for your reply. I know browser support is not that great but you could use some polyfill to shim it.
chrome and opera have partial implementations only. It would be a good idea to write/use a polyfill once one or more UA fully implement the spec
There already is one by Google: github.com/GoogleChrome/dialog-polyfill
I've heard that some old screen readers still show the alert modal content even if it has display: none...
Will it work same on Angular application??
I've seen solutions that trap tab (and shift-tab) and manually direct focus inside the modal - is there a way to do that, and to to direct the next tab event to something outside the web content, or would inert be the only way to handle it?
If you guys want to make sure that the screen reader will read the alert dialog, don't forget to give focus to the first button inside the modal.
How do you make a non modal dialog accessible, for example a cookie layer, or any other layer, that appears on screen, after loading the page? These layers cover content and I want to close them asap using the keyboard. But I don't want to navigate the whole page before I get to this cookie layer. Should I provide a keyboard shortcut to access the layer?
Setting all non-dialog controls to inert, then setting them all back to non-inert. What if some of those controls are supposed to be inert already? You've now reset them all regardless...
Great! Just one think I don't like. The position: fixed. If for some reason the dialog gets super big or viewport is super small, there is no way to move it. If you use position: absolute, you can achieve fairly similar behaviour, with this edge case covered.
I think that you should also set previousActiveElement to null on dialog closing to let browser free it in case it is removed from DOM.
How can you tell the screen reader to read the contents of the screenreader? I noticed that your screen reader read it but cant work out why from the JavaScript.
Would you advise implementing similar techniques for a slide in menu?
Which WCAG SC violation it is? if a modal dialog is not accessible?
Why remove the `click` and `keydown` event listeners when dialog closes?
Are you using the Apples voice over or the ChromeVox extension?
Tom
Andrew Carreon that's my name
Why it is not showing when the window or tab is out of user focus??
Hey Rob, I'm using React in my project. How do I get inert to work with React and its virtual dom?
Also worth pointing out, there is an open issue on the react GitHub regarding non-standard attributes. github.com/facebook/react/issues/140
Cool. Thanks for the swift replies.
Are you using dialog polyfill?
pls show how to implement carousel. It is also not easy
Lets convert this to custom element. With best practices. Z-index for example. :) And what about native element? Whats the progress on implementation?
about the native element, is there a planned video in this series about that? chromium browsers have the most support for it, and the chrome team have developed a polyfill so that would be a natural fit here. yes?
inert ain't working for me
Well, if a container has visibility: hidden (or display: none) all of tis children will not be able to receive focus.
The "Inert" spec should be implemented in browsers by default.
Where's the source code??
Can someone share this dialog code or codepen link here ? so we can understand that logic
yes would love to have the code....
Thanks
Oh god please don't promote the transform centering method, I've had people ask me why their dialog was getting blurry for no reason and it's because of that 100% of the time
Yeah I know I've run into this problem as well. It mostly happens on Chrome though. It's probably the element landing on a sub-pixel position or something.
Was not aware of that. Does it also happen with vh/vw units?
But, but, but, flexbox 😖
That was my thought... Anybody know why? browser support?
This tends to be how I go about it (it's quite old now but can be JS free)
jsfiddle.net
my comment
The mouth clicks are unbearable. There are so many ways to prevent and treat it in post production!
A ton of code when you can implement a modal dialog with jQuery in just a few lines of code.
Why use jQuery at all? There is a dialog element with a good polyfill from the Chrome team for browsers where it isn't supported.
thanks