[BITV] 9.4.1.2/3.16 - Custom editing menubar should be implemented using role=toolbar and not role=menubar. (2)

[AndyScherzinger]

Important

For QA, please just check that PRs are merged to stable28

Currently selected styles on selected text in the editing region ("div" with "contenteditable=true") are shown visually (light blue background) but they are not programmatically determinable via aria-selected attribute. aria-activedescendant is not used on toolbar styling elements. Also missing is appropriate scripted focus management for the style toolbar and for its drop-down submenus like headings, insert image, insert emoi).

Details

https://report.bitvtest.de/default-en/d63601ac-cb34-4645-8256-66bec78964a0.html#checkpoint-bfbf07e5c3-v3-n16

• 9.4.1.2/10.16 - https://report.bitvtest.de/default-en/d63601ac-cb34-4645-8256-66bec78964a0.html#checkpoint-bfbf07e5c3-v10-n16

[juliusknorr]

Isn't this already covered by #3863?

[AndyScherzinger]

Isn't this already covered by #3863?

Cant tell @juliushaertl - best to clarify with @michaelnissenbaum

[blizzz]

Any update on the state? @juliushaertl @michaelnissenbaum

[susnux]

Isn't this already covered by #3863?

@juliushaertl yes and no, the title of this issue is misleading. That issue covers the toolbar vs menubar handling.
But this one is about:

Currently selected styles on selected text in the editing region ("div" with "contenteditable=true") are shown visually (light blue background) but they are not programmatically determinable via aria-selected attribute. aria-activedescendant is not used on toolbar styling elements. Also missing is appropriate scripted focus management for the style toolbar and for its drop-down submenus like headings, insert image, insert emoi).

• Adding aria-selected to the currently active menu element (currently only the primary background is set, so only visual information is available)
• Adding aria-activedescendant to the menu item with the content being the ID of the currently active descendant (for submenus)
• "Also missing is appropriate scripted focus management": Part of [BITV] 9.2.4.3/3.9 - Toolbar focus handling #3863

[Pytal]

This issue seems to be the same as #3864 + aria-selected and can be done simultaneously, feel free to unassign me and assign yourself @susnux if you think it's within the same scope :)

[ShGKme]

This issue seems either to be understood incorrectly or initially incorrect.

This is about tool bar in the text app:

> "programmatically determinable via aria-selected attribute"

There are active and non-active buttons that should be annotated indeed. However, according to the specification, aria-selected is for elements with gridcell, row, option and tab roles. Not for buttons. A state of a toggle button is supposed to be annotated by aria-pressed attribute.

See also:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-selected
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-pressed

> aria-activedescendant is not used on toolbar styling elements

aria-activedescendant is needed to determine visually focused element when an actual focus is in another place. For example, in a combobox or autocomplete in a rich text editor, we have the focus and cursor on the text field while moving between options by arrow keys.

But in the text editor, the focus remains on the menu when a user works with the menu. The menu works as a general menu and should not require the aria-activedescendant.

See:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-activedescendant

Toolbar pattern

There is a toolbar example on w3c patters which is almost exactly the same as what we have (also a text editor toolbar). And it also has no aria-selected or aria-activedescendant, but aria-pressed and menus.

https://www.w3.org/WAI/ARIA/apg/patterns/toolbar/examples/toolbar/

---

@michaelnissenbaum Could you please clarify this issue? Have we understood the initial issue in the report correctly? Or am I misunderstanding something?

[michaelnissenbaum]

Firstly, the current implementation is incorrect because even though the "toolbar" role has been used, the elements within the toolbar still have the "menuitem" role. I suggest aligning with the WCAG example and using Button elements with "aria-pressed." "aria-selected" is indeed incorrect in this context.

[ShGKme]

Dear @michaelnissenbaum,

thank you for your reply!

Firstly, the current implementation is incorrect

Yes, this is already being fixed. Actually, we were checking that everything is used correctly here recently when we found that some incorrect, in our opinion, attributes were added intentionally to follow instructions from this issue.

Thank you for clarifying the aria-selected.

What about aria-activedescendant? Is that correct that a menu is not required to have aria-activedescendant if it has actual real focus?

[michaelnissenbaum]

I don't think we need the aria-activedescendant attribute in this case, as we have a toolbar element.