Closed cole-sanderson closed 6 years ago
I argue in #99 that we should implement some default, basic and fool-proof measures to avoid a situation where a screen reader user may become permanently (or mostly permanently) trapped in a modal.
Basically, all instances of Pinny are required to have either an escape button (added automatically, not by the implementer, although maybe overridable) OR a message with instructions on what must be done to escape (it's possible that escaping a modal could be a worse UX).
We are going to have to make the decision on whether or not these a11y enhancements should be part of the backfilled Zepto-compatible release alongside #99 (++: These fixes can come into the release without compatibility issues; --: This would delay the release) or just only work to get these into the latest jQuery-based Pinny (++: Legacy release would go out a lot quicker and we can focus all efforts into the latest codebase; --: These changes feel like they should come along with the fixes from #99)
@jeffkamo @cole-sanderson thoughts?
We are missing two features to allow user to close Pinny.
To do:
pinny__wrapper
to allow screenreader to close Pinny after reading content in Pinny.Current structure:
Proposal structure:
Additional note: We should be using
<button>
element instead of<a>
since its behaviour button not linking to new page.