Opened 5 years ago

Closed 5 years ago

#11331 closed Bug (fixed)

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

Reported by: Teresa Monahan Owned by: Marek Lewandowski
Priority: Normal Milestone: CKEditor 4.3.2
Component: Accessibility Version: 4.3
Keywords: IBM Cc: Satya Minnekanti, Irina, peter


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.

Change History (11)

comment:1 Changed 5 years ago by 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?

comment:2 in reply to:  1 ; Changed 5 years ago by 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?

comment:3 in reply to:  2 Changed 5 years ago by 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

comment:4 Changed 5 years ago by Jakub Ś

Component: GeneralAccessibility
Status: newconfirmed
Version: 4.3.2 (GitHub - master)4.3

comment:5 Changed 5 years ago by Marek Lewandowski

Owner: set to Marek Lewandowski
Status: confirmedassigned

comment:6 Changed 5 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.3.2

comment:7 Changed 5 years ago by Marek Lewandowski

Status: assignedreview

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.

comment:8 Changed 5 years ago by Frederico Caldeira Knabben

Status: reviewreview_failed
  • 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.

comment:9 Changed 5 years ago by Marek Lewandowski

Status: review_failedreview

Requested changes pushed to t/11331b.

comment:10 Changed 5 years ago by Piotrek Koszuliński

Status: reviewreview_passed

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

comment:11 Changed 5 years ago by Marek Lewandowski

Resolution: fixed
Status: review_passedclosed

Merged to master with git:1bc859e08d3b72098.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy