JAWS users are not informed that the language button has a menu when a language is already applied

[Teresa Monahan]

To Reproduce:

• Open any 4.3 sample with JAWS turned on.
• Press Alt+F10 in the editor to move focus to the toolbar and navigate to the language button.

Note: JAWS will read 'Set Language button menu'.

• Open the menu and select an option e.g. French. Focus will return to the editor.
• Press ALT+F10 to place focus in the toolbar again and navigate back to the language button as before.

Problem: JAWS now reads 'Set language toggle button pressed' and it does not tell the user that this button has a menu.

This is caused by the addition of the aria-pressed attribute when an option is selected on the language menu. The aria-pressed attribute is used exclusively for toggle buttons so the addition of this attribute means that JAWS will no longer consider this a menu button even though aria-haspopup="true" is also set. aria-haspopup="true" creates a menu button while the aria-pressed attribute creates a toggle button. Therefore these 2 attributes cannot be valid on the same element at the same time.

We realize that the reason aria-pressed was used in this case was to style the language button so that users would know that a language has been applied to the current selection. Unfortunately this is not a compliant solution for JAWS users.

The only alternative we can see at present is to implement the language menu as a rich combo control instead, similar to the font and font size fields. That way JAWS users will always be aware of the language listbox and all users will be able to see the currently selected language on the toolbar.

[Frederico Caldeira Knabben]

Interesting issue. It brings to light a small hole in ARIA as it allows both attributes at the same time, but they're in fact incompatible in terms of expected behavior.

We would like to avoid transforming it into a rich-combo because it would take way to much space in the toolbar, for a feature that fits well in a button. But, as a matter of fact, that buttons acts just like a combo.

If we want to match UX and a11y, we don't need to look at the visual representation of the UI element and forcedly match it to a "visual" role. This means that, if we understand that the button acts like a listbox, we can and should set role="listbox" (or "combobox") to it.

How does it look like?

[Teresa Monahan]

Replying to fredck:

Hi Fred, I'm afraid I fail to see how changing the button to have a role of listbox or combobox would help in this scenario. The button itself doesn't really act as a listbox - rather the menu that it opens is the listbox/combo like control. Even the font and font size toolbar elements which look more like conventional combo boxes have role=button.

Anyway even if a role of listbox was applied to the language button, this doesn't help to indicate to the user that an option is selected on the inner menu. That really was the advantage of using the aria-pressed attribute. Would it be possible to just add the cke_button_on class to the menu button when an option is selected, without applying the aria-pressed attribute? That way the button can be styled as active without using the conflicting aria attributes. For JAWS users, could the aria-label be updated to indicate that a selection was made?

Alternatively would it be possible to somehow provide an option of how this menu is rendered i.e decouple the available options from any particular style of UI, or even just provide an option to render it as either a richcombo or a menu button?

[Teresa Monahan]

Hi, Is there any update on this ticket? Will it be possible to use one of the suggestions from comment:2 to address this issue? Can this please be targeted for the 4.3.2 release? It is a critical issue for us. Thanks, Teresa

[Marek Lewandowski]

Pushed to ​t/11331 at dev.
I've extended setState method in order to change label as a reaction for status change, since render is executed once.

While it can be reviewed i will focus on automated tests for that.

[Frederico Caldeira Knabben]

• Instead of the instanceof check, we're already doing it in a different way, with this.hasArrow.

• We already have that checking logic in the button plugin. Considering that, why not simply doing the label trick in the button plugin itself (using the hasArrow check)? This would avoid the overriding complication and would keep the whole logic together, instead of having part here and part there.

• I'm very afraid about the suffix idea. It's hard to guarantee that simply merging strings with spaces will work on all languages. Therefore, better to have it like "%1 (Selected)", replacing then %1 with the button label.

[Marek Lewandowski]

Requested changes pushed to ​t/11331b.

[Piotrek Koszuliński]

The code looks good, DOM looks good, solution works in build mode and Marek confirms that JAWS correctly announces button.

[Marek Lewandowski]

Merged to master with ​git:1bc859e08d3b72098.