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
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.
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...
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.
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?
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!
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.
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.
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?
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.
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).
I wish you could make a full Udemy course
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
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.
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.
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??
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...
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
Really like the idea of bringing back the focus to the previous active element on close, thanks :)
Hey, Rob. If have a video in pop-up in the CTA button, Vedio plays automatically right? As per WCAG.
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?
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!
what about the new HTML dialog element? are these automatically applied when i use that or do i have to add them in myself
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.
Very useful component. Nice work as always, Rob. Thanks 👍
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?
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.
Which WCAG SC violation it is? if a modal dialog is not accessible?
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?
Why remove the `click` and `keydown` event listeners when dialog closes?
Why it is not showing when the window or tab is out of user focus??
Are you using dialog polyfill?
pls show how to implement carousel. It is also not easy
Are you using the Apples voice over or the ChromeVox extension?
Tom
Andrew Carreon that's my name
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.
Thanks
The "Inert" spec should be implemented in browsers by default.
Well, if a container has visibility: hidden (or display: none) all of tis children will not be able to receive focus.
inert ain't working for me
Where's the source code??
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
Can someone share this dialog code or codepen link here ? so we can understand that logic
yes would love to have the code....
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?
my comment
The mouth clicks are unbearable. There are so many ways to prevent and treat it in post production!
thanks