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
As noted in #558, the buttons in the inline toolbars behave as a toggle. Not just the alignment ones, also bold, italic, etc. and all the ones that need to be toggled to change a state.
Visually, their state is communicated with a color inversion. Semantically, there's nothing to communicate their state. This kind of toggle buttons need an aria-pressed attribute with true/false value. This way, assistive technologies can communicate the buttons state.
As they work now:
Compare for example to what TinyMCE does:
TinyMCE uses divs for the buttons and then "resets" the real buttons semantic with role=ppresentation, but that's not the point, the necessary semantics is all there on the divs.
The editor toolbar would need further a11y improvements that should go in separate issues:
first of all, a simple, easily discoverable way to focus them using only the keyboard 🙂
As noted in #558, the buttons in the inline toolbars behave as a toggle. Not just the alignment ones, also bold, italic, etc. and all the ones that need to be toggled to change a state.
Visually, their state is communicated with a color inversion. Semantically, there's nothing to communicate their state. This kind of toggle buttons need an
aria-pressed
attribute withtrue/false
value. This way, assistive technologies can communicate the buttons state.As they work now:
Compare for example to what TinyMCE does:
TinyMCE uses divs for the buttons and then "resets" the real buttons semantic with
role=ppresentation
, but that's not the point, the necessary semantics is all there on the divs.The editor toolbar would need further a11y improvements that should go in separate issues:
The text was updated successfully, but these errors were encountered: