-
Notifications
You must be signed in to change notification settings - Fork 22.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix a11y issue with dialog element keyframes animation #36167
base: main
Are you sure you want to change the base?
Conversation
Changing the display property in the keyframes animation example causes focus to be dropped onto the body element when opening or closing the dialog. This is harmful for accessibility, since a keyboard and/or screen reader user may become confused when focus is not managed correctly. The dialog may still be animated using CSS keyframes without changing the value of the display property.
Preview URLs |
@clhenrick hi there, and thanks for contributing to MDN! I really appreciate your concern here, but the trouble with removing I wonder if we could fix the issue presented in another way, such as by programmatically setting the focus after the anmation has finished, or by adding a note to at least warn readers of this issue? Or maybe we should remove the animation example and just recommend using transitions for such animations instead. I also wonder whether it might be an implementation bug,or whether it is like this by design? |
@chrisdavidmills thanks for the quick review and reply, happy to help contribute.
I'm seeing that even when the
Yeah we may want to warn readers that animating the display property by setting
When looking into the various browser support for all the properties required to animate the dialog using a transition I remember there being less browser support when compared to using keyframes. For this reason in my own work I chose to use the keyframes animation method, so it seems worth keeping IMO.
I wonder this as well. I'm not seeing the closing fade out animation in Chrome or Safari on MacOS with the transition animation in the play examples on the MDN dialog page either. |
chiming in because i helped @clhenrick review the example and noted that the fade-in animation shouldn't need display none to block at all. taking that away didn't seem to impact the animation at all (since the dialog is in a display none state by default, it immediately showing and transitioning with the opacity 0 -> seemed to work just fine). But removing that from the keyframes did solve the focus issue. (i can't imagine this focus issue being by design. likely an implementation oversight). (fwiw, @clhenrick - the animation for the fade out works just fine for me with the display block to none. I'm testing on Windows Edge v129. Not sure what platform browser release you're using, but if you're not seeing the animation out then maybe an update is necessary?) the fade-out animation can keep the display block to none to allow the animation to work. since focus is returning to the invoking button element, focus loss is not an issue here. So it can still be used to demonstrate the animation of display - per the intent of this demo. It probably makes sense to add a note to indicate there's no reason for an author to re-declare a display none property for a dialog, since it implicitly is display none by default. And that doing so can result in the browser's focus algorithm for the dialog to not work, since it fires at the same time that the dialog is still considered "display none" due to the author overwriting the UA style. |
@scottaohara I am now seeing the fade out animation when including the I like the way Scott summarizes the issue and agree including this information in the dialog keyframes animation example would be helpful:
On a related note one thing I'm noticing is that focus management is handled correctly when animating the dialog using CSS |
Yup, agreed, thanks @clhenrick. |
Hi all, what's the next steps for this PR? Is it clear what changes need to be applied to the prose? Do you want to come back to this one @clhenrick? Thank you :) |
Changing the display property in the keyframes animation causes focus to be dropped onto the body element when opening or closing the dialog element. This is harmful for accessibility, since a keyboard and/or screen reader user may become confused when focus is not managed correctly for the dialog element when used as a modal dialog. The dialog may still be animated using CSS keyframes without changing the value of the display property.
Description
Removes usage of the
display
property from thedialog
keyframes animation example.Motivation
During testing the dialog for accessibility purposes I saw that focus was being dropped on the body element when animating the dialog using this method. Removing the
display
property solves the issue and allows the dialog to manage focus correctly.Additional details
Tested proposed changes on
Related issues and pull requests