Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#10361 closed Bug (fixed)

role="application" should not be used for floating panels

Reported by: Teresa Monahan Owned by: Frederico Caldeira Knabben
Priority: Normal Milestone: CKEditor 4.1.2
Component: General Version: 4.0.1
Keywords: IBM Cc: Damian, Satya Minnekanti, Irina

Description

The fix for ticket #9543 applies role="application" on all floating panels used in the editor. This was added to "enable" JAWS forms/application mode. However this is not the purpose of the application role as it is intended to be a landmark region encompassing a whole application.

Floating panels have other WAI-ARIA container roles (menu and listbox) which implicitly support keyboard interaction once that container or an element within it has focus. Therefore the application role should not be required to explicitly change to forms mode.

The issue raised in ticket #9543 is likely due to the fact that focus is not being placed on the container or an element within it when a menu or listbox element is opened. Focus should be placed directly on an element with the menu/listbox role or on a child element with the menuitem/option role.

Change History (19)

comment:1 Changed 7 years ago by Jakub Ś

Status: newconfirmed

I haven't found any tickets asking not to put visible focus on first context-menu item so perhaps this isn't such a bad idea.

comment:2 Changed 7 years ago by Teresa Monahan

This is a high priority ticket for us - can you please target it for the upcoming 4.1.2 release?

comment:3 Changed 7 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.1.2
Owner: set to Frederico Caldeira Knabben
Status: confirmedassigned

comment:4 Changed 7 years ago by Frederico Caldeira Knabben

We have two issues here:

  • As described, we should not use the application role for this purpose.
  • Still, it looks like that fix is not any more working.

Because of the above I've reverted the #9543 fix with git:06e8a9e.

comment:5 Changed 7 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.1.2

I've just pushed t/10361, with a change to select the first available item in the combo when opening it.

I still have strong doubts about this solution, because now the selected item looks like the "active" value for the editor selection, which is not true. Because of this, I'm removing the milestone from this ticket so we can dedicated more time to this to find the proper solution. In any case, the application role is not any more used.

comment:6 Changed 7 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.1.2
Status: assignedreview

I've pushed t/10361b with a different way for this. It moves the focus to the list holder element, which seems to solve the problem without changing the current editor behavior.

comment:7 Changed 7 years ago by Olek Nowodziński

Status: reviewreview_passed

comment:8 Changed 7 years ago by Olek Nowodziński

Resolution: fixed
Status: review_passedclosed

Merged fix into master, dev (​git:1d781e4).

comment:9 in reply to:  8 ; Changed 7 years ago by Teresa Monahan

Replying to a.nowodzinski:

Merged fix into master, dev (​git:1d781e4).

Replying to a.nowodzinski:

Merged fix into master, dev (​git:1d781e4).

With this fix JAWS does not read out that the font or size menus are list boxes. To reproduce,
-Use JAWS in FF17 ESR
-Navigate to the Font dropdown on the toolbar using the keyboard.
-Press Enter to open the combo box.
Problem: JAWS does not alert the user that this is a listbox. It should read 'Font Name list box, to move to an item use arrow keys'.

It looks like focus is being placed on an element with role=presentation rather than the iframe with role=listbox or a list item with role=option. JAWS correctly reads out listbox information for the paragraph format field but focus is placed on an option in this case.

This worked correctly in 3.6.x and 4.0.

comment:10 in reply to:  9 ; Changed 7 years ago by Frederico Caldeira Knabben

Replying to tmonahan:

In fact I was able to confirm that the issue happens, but not aways. It's intermittent and I couldn't find a reasonable pattern for this.

I did some further research and just pushed git:f48fc5c, which should finally stabilize the results now.

Thanks for the feedback, Teresa!

comment:11 in reply to:  10 ; Changed 7 years ago by Teresa Monahan

Replying to fredck:

Replying to tmonahan:

In fact I was able to confirm that the issue happens, but not aways. It's intermittent and I couldn't find a reasonable pattern for this.

I did some further research and just pushed git:f48fc5c, which should finally stabilize the results now.

Thanks for the feedback, Teresa!

Hi Fred,

Thanks for looking into this further.

The behavior now is better. However the incorrect title is read out for the combo boxes now. Instead of "Font Name", "Font Size" etc, the url for the entire page is read out when the combo box is opened e.g. http://nightly.ckeditor.com/13-06-03-13-06/full/samples/replacebyclass.html.

I tried reverting the changes on lines 282-291 in panel/plugin.js from your latest changeset and it then works as expected. JAWS correctly identifies the panels as listboxes and reads out the correct title with this change. Can you please deliver this change?

Thanks, Teresa

comment:12 Changed 7 years ago by Teresa Monahan

Hi, is there still time to include this latest proposed change in 4.1.2? This should be the final change required to fully address the issue raised in this ticket. Thanks, Teresa

comment:13 in reply to:  11 ; Changed 7 years ago by Frederico Caldeira Knabben

Replying to tmonahan:

The behavior now is better. However the incorrect title is read out for the combo boxes now. Instead of "Font Name", "Font Size" etc, the url for the entire page is read out when the combo box is opened e.g. http://nightly.ckeditor.com/13-06-03-13-06/full/samples/replacebyclass.html.

I'm not able to reproduce it in any way. It works just perfect for me. When I open the font name combo I have:

"Font name listbox. To move to an item press the arrow keys."

But if you're reporting it, it means that somehow you're seeing it wrong there. So, I'm investigating it further.

I tried reverting the changes on lines 282-291 in panel/plugin.js from your latest changeset and it then works as expected. JAWS correctly identifies the panels as listboxes and reads out the correct title with this change. Can you please deliver this change?

I have tried it and actually this is a trick that makes things look like right, but there is a small change in the speech:

"Font name. Listbox. To move to an item press the arrow keys."

Note that now "Font name" and "Listbox" are announced separately. This doesn't look like the right way for it.

So, I tried something else. I've reverted only lines 290 and 291 of that change (removing them). Then I had this:

"Font name. Font name listbox. To move to an item press the arrow keys."

Which doesn't look good as well.

Still, for me, the behavior we have in master right now is the best possible one. Are you sure we need to change this? I'm testing it with latest FF (21.0) and JAWS (14.0.3005).

comment:14 in reply to:  13 ; Changed 7 years ago by Teresa Monahan

Replying to fredck:

I'm testing it with latest FF (21.0) and JAWS (14.0.3005).

Hi Fred, I'm using the same JAWS version as you but am testing in FF17 ESR. I see the same behavior as you in FF21. Ideally we would find a good solution for both FF versions but I haven't figured out what that is yet.

In the meantime I noticed another issue with this fix though. This applies role=listbox to the cke_panel_block div, however the parent iframe also has this role. Nesting listbox roles is not valid according to the wai-aria specification - http://www.w3.org/TR/wai-aria/roles#listbox. Therefore we will have to find an alternative solution.

Is it possible to set focus directly on the iframe with role=listbox? Alternatively removing role=listbox and aria-label from the iframe might be a solution provided focus goes to the cke_panel_block div which has the listbox role and appropriate aria-label.

comment:15 in reply to:  14 ; Changed 7 years ago by Frederico Caldeira Knabben

Replying to tmonahan:

Unfortunately none of your suggestions bring good results. I also figured out that we have nested listboxes, but there is not better way to support it for now with latest JAWS.

We may talk with the FS guys to see if they have any better idea. We don't have enough time for this for the 4.1.2 any more as it is getting public on monday. We may investigate it further after release.

comment:16 in reply to:  15 Changed 7 years ago by Teresa Monahan

Replying to fredck:

Replying to tmonahan:

Unfortunately none of your suggestions bring good results. I also figured out that we have nested listboxes, but there is not better way to support it for now with latest JAWS.

We may talk with the FS guys to see if they have any better idea. We don't have enough >time for this for the 4.1.2 any more as it is getting public on monday. We may investigate >it further after release.

Hi Fred, OK I know we have run out of time for 4.1.2. Can you revert all these changes for the 4.1.2 release then? The nested listbox roles is a compliancy failure for us. Therefore we would prefer to revert back to the behavior before the fix for ticket #9543. The implementation at that time works well in FF 17 ESR which is the main browser we need to support. This does break in later versions of FF, but perhaps this is a FF issue rather than a CKEditor one. We can investigate further post 4.1.2.
Thanks, Teresa

comment:17 Changed 6 years ago by Frederico Caldeira Knabben

Unfortunately we didn't make it, to remove this fix. Still, in practical terms, we have better results now and I doubt the nested listbox will ever bring a practical issue to users. We're certainly hitting our goal to provide *usable* accessibility in this way.

Still, it would be correct to fix the DOM structure to avoid such nesting. Ideally, it should be enough to set the iframe role to "presentation", but then JAWS should not announce it as "frame".

Some guidance from FS would certainly be useful here. Thanks!

comment:18 in reply to:  17 ; Changed 6 years ago by Teresa Monahan

Replying to fredck:

Still, it would be correct to fix the DOM structure to avoid such nesting. Ideally, it should be enough to set the iframe role to "presentation", but then JAWS should not announce it as "frame".

Some guidance from FS would certainly be useful here. Thanks!

Hi Fred,

Setting the iframe role to "presentation" is the right approach here.

We asked FS for feedback on why JAWS announces "frame" for iframes with role=presentation. It seems that Firefox assigns the IA2 frame role to the iframe in this case and JAWS just announces it, so technically this is a defect in Firefox. However Mozilla cannot fix this so JAWS will ignore frames with role=presentation from JAWS 15 onwards.

Can you please include this change in the upcoming 4.2.2 release?

Thanks,
Teresa

comment:19 in reply to:  18 Changed 6 years ago by Frederico Caldeira Knabben

Replying to tmonahan:

We asked FS for feedback on why JAWS announces "frame" for iframes with role=presentation. It seems that Firefox assigns the IA2 frame role to the iframe in this case and JAWS just announces it, so technically this is a defect in Firefox. However Mozilla cannot fix this so JAWS will ignore frames with role=presentation from JAWS 15 onwards.

Can you please include this change in the upcoming 4.2.2 release?

I've included this change in #10951.

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