Fix: CSS to animate popups, dialog for accessibility (fixes #600)

[oliverfoster]

fixes #600

tbc

Fix

• A sentence describing each fix

Update

• A sentence describing each update

New

• A sentence describing each new feature

Breaking

• A sentence describing each breaking change

[kirsty-hames]

This is working great thanks @oliverfoster. I've tested the tabbing and screen reader capability in comparison to the current functionality (master). Drawer dialog seems consistent, but I've noted a couple of differences for Notify dialog. Not sure if these are expected or need further input?

• Notify dialog popup title doesn't display visual focus anymore for Chrome or Safari (Mac). FF (Mac + Win) is intermittent. Chrome and Edge (Win) work as expected.

• For Edge (Win) and FF (Mac), when tabbing through Notify dialog popup, after the close btn, focus is directed to the browser UI. Focus does loop and return to the popup elements e.g. title > prev btn > next btn > close btn > browser UI > title > prev btn etc. For Chrome (Mac + Win) and Safari (Mac), focus is contained to the popup only.

[oliverfoster]

Not sure if these are expected or need further input?

• Notify dialog popup title doesn't display visual focus anymore for Chrome or Safari (Mac). FF (Mac + Win) is intermittent. Chrome and Edge (Win) work as expected.

I have removed the a11y.focusNext call to allow the browser to handle it through the native dialog.showModal function. Adapt therefore no longer tries to focus on the title.

• For Edge (Win) and FF (Mac), when tabbing through Notify dialog popup, after the close btn, focus is directed to the browser UI. Focus does loop and return to the popup elements e.g. title > prev btn > next btn > close btn > browser UI > title > prev btn etc. For Chrome (Mac + Win) and Safari (Mac), focus is contained to the popup only.

I will make sure that the default browser behaviour is utilised for the loop around. We should not stop the focus from looping around into the browser UI if that is expect.

[swashbuck]

I've removed the Drawer easing properties from the schemas in 4e00cad. These reference easing strings that are specific to Velocity JS and are not available as a CSS transition-timing-function value.

These easing methods could be reproduced using cubic-bezier() values, but we would want to set up new variables in the theme (ex. @animation-easing-easeInOutQuart). Currently, I've just switched all the easing functions to use @animation-easing in the Vanilla PR. Not sure that it's worth the effort to support Drawer easing options via config?

[oliverfoster]

I've removed the Drawer easing properties from the schemas [..]
These easing methods could be reproduced using cubic-bezier() values, [..] Not sure that it's worth the effort to support Drawer easing options via config?

On reflection, I'd like this to be as least breaking as possible. I have made a sub pr to reintroduce the easing as the suggested css cubic-bezier functions.

#602

It is not possible to represent the bounce and elastic easing functions using just cubic-bezier functions, so I have gracefully replaced those with their nearest cubic-bezier counter parts, back and quint respectively and have added warnings to the console to say as much.

References:
https://developer.mozilla.org/en-US/docs/Web/CSS/easing-function
https://easings.net/#
https://joshcollinsworth.com/blog/easing-curves