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

[Teresa Monahan]

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.

[Jakub Ś]

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.

[Teresa Monahan]

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

[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.

[Frederico Caldeira Knabben]

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.

[Frederico Caldeira Knabben]

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.

[Olek Nowodziński]

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

[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.

[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!

[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

[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

[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).

[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.

[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.

[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

[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!

[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

[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.