You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently I've been working on an accessibility feature and I found that CSS lacks an attribute to describe the focusable of elements, in other words, the semantics is incomplete.
For the non-visually impaired people, hiding multi-level submenus in navigation maybe help to improve the user experience. For example:
In the case above, the only way to reach the submenus is hover on the item MENU A. We can't focus the submenus by press the tab key. Obviousily it's unfriendly with visual impaired people.
I tried several ways, finally I found that I could only solve this problem by hacking CSS. If we want an element to be both focusable and invisible, we should set its opacity to zero instead of setting visibility to hidden. If we want an element to be focusable without flow and hot areas, we should set its transform to scale(0) and position to fixed instead of setting display to none.
I also refered to the implementation of Bootstrap, one of the most famous UI framework in the world. It uses the class sr-only to hide an element while keeping it accessible. To my regret, it's a hacking too.
This kind of practices destroys the original semantics. I can't correctly express that an element is currently invisible or non-existent but accessible. So I have a proposal: Add an attribute or option to CSS standard to describe at least scenes below to keep semantic integrity.
An element is invisible but focusable. (visibility: hidden & focusable)
An element is non-exists but focusable. (display: none & focusable)
An element is visible and focusable. (without html element attribute tabIndex)
An element is visible but unfocusable. (without html element attribute tabIndex="-1")
When a focusable but visually unreachable element is about to be focused, the :focus and :focus-within pseudo class should be triggered, but still remain its invisible visually.
The text was updated successfully, but these errors were encountered:
There is already an issue about potentially standardizing the .sr-only/.visually-hidden hack in #560.
Managing focus(ability) was raised in #3379 and #1748.
Additionally, the <details> element is used to create a disclosure widget so there's already a way to build a submenu without JS, or CSS hacks. Perhaps the proposed <popup> may be viable too for such use cases in the future.
Recently I've been working on an accessibility feature and I found that CSS lacks an attribute to describe the focusable of elements, in other words, the semantics is incomplete.
For the non-visually impaired people, hiding multi-level submenus in navigation maybe help to improve the user experience. For example:
In the case above, the only way to reach the submenus is hover on the item
MENU A
. We can't focus the submenus by press the tab key. Obviousily it's unfriendly with visual impaired people.I tried several ways, finally I found that I could only solve this problem by hacking CSS. If we want an element to be both focusable and invisible, we should set its
opacity
to zero instead of settingvisibility
tohidden
. If we want an element to be focusable without flow and hot areas, we should set itstransform
toscale(0)
andposition
tofixed
instead of settingdisplay
tonone
.I also refered to the implementation of Bootstrap, one of the most famous UI framework in the world. It uses the class
sr-only
to hide an element while keeping it accessible. To my regret, it's a hacking too.This kind of practices destroys the original semantics. I can't correctly express that an element is currently invisible or non-existent but accessible. So I have a proposal: Add an attribute or option to CSS standard to describe at least scenes below to keep semantic integrity.
visibility: hidden
& focusable)display: none
& focusable)tabIndex
)tabIndex="-1"
)When a focusable but visually unreachable element is about to be focused, the
:focus
and:focus-within
pseudo class should be triggered, but still remain its invisible visually.The text was updated successfully, but these errors were encountered: