[Sev1] AVT: Keyboard Navigation in dialogs with multiple tabs not following CI 162 instructions or ARIA Authoring practices

[Satya Minnekanti]

To reproduce the defect:

1. Open ​http://nightly.ckeditor.com/15-03-10-07-08/full/samples/replacebyclass.html.

2. Open any dialog that has multiple tabs ( ex: Table Properties)

3. Navigate dialog using keyboard.

Actual Result

1. when a dialog opens focus going in to first field in tab panel that's opened.

2. User has to press Alt + F10 to access tab list from a tab panel.

3. User has to press Enter key to go in to a tab panel from a tab in tablist.

This fails Accessibility Compliance since tabs & tab panels are not coded as per CI guidelines or ARIA Authoring Practices

Expected Result:

1. When dialog opens focus should go to selected tab & when user press tab key focus should go to tab panel.(User should not have to press enter to move focus from selected tab to tabpanel content. That should always be done with tab key.)

2. User should be able to move focus to tablist with tab key. For tabs in a dialog, tablist must be in the dialog's tab ring. Only selected tab should be in the tab ring. User changes which tab is selected with the arrow key once focus is in the tablist.

Please see ​http://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#tabpanel on keyboard interaction in a tab panel

Tab - only active tab is in the tab order. User reaches the tabbed panel component by pressing the tab key until the active tab title receives focus.

Left Arrow - with focus on a tab, pressing the left arrow will move focus to the previous tab in the tab list and activate that tab. Pressing the left arrow when the focus is on the first tab in the tab list will move focus and activate the last tab in the list.

Right Arrow - with focus on a tab, pressing the right arrow will move focus to the next tab in the tab list and activate that tab. Pressing the right arrow when the focus is on the last tab in the tab list will move focus to and activate the first tab in the list.

Up arrow - behaves the same as left arrow in order to support vertical tabs

Down arrow - behaves the same as right arrow in order to support vertical tabs

[Frederico Caldeira Knabben]

Thanks for the detailed report.

I think that changing the keyboard navigation to follow the authoring practices is doable.

My only concern is about the first focus. On many dialog (e.g. link), it doesn't make sense focusing the tab first as there is usually a main focus field to be focused first. I have the impression that, if we keep focusing fields first, we would still be ok, as long as the dialog-tab starts participating on the tab ring. Can you confirm this? Otherwise the usability impact of this change would be extremely impacting.

[Satya Minnekanti]

Replying to fredck:

Thanks for the detailed report.

I think that changing the keyboard navigation to follow the authoring practices is doable.

My only concern is about the first focus. On many dialog (e.g. link), it doesn't make sense focusing the tab first as there is usually a main focus field to be focused first. I have the impression that, if we keep focusing fields first, we would still be ok, as long as the dialog-tab starts participating on the tab ring. Can you confirm this? Otherwise the usability impact of this change would be extremely impacting.

@Fred Thanks a lot for the reply. We are already using dialog_startupFocusTab = true config option to set focus on tab when dialog opens. We would like this fix to be compatible with this setting. This will allow for both types of behavior (as is the case today).

[Frederico Caldeira Knabben]

Ok, true. This is supposed to be compatible with dialog_startupFocusTab. Thanks for the update.

[Marek Lewandowski]

We'll review our current behaviour vs ARIA.

Replying to satya:

@Fred Thanks a lot for the reply. We are already using dialog_startupFocusTab = true config option to set focus on tab when dialog opens. We would like this fix to be compatible with this setting. This will allow for both types of behavior (as is the case today).

Ok, it make sense - we'll make sure that config.dialog_startupFocusTab will benefit from the fix.

[Marek Lewandowski]

Though it's an important UX change we still decided to put it to the closests minor release.

I left current alt + F10 keystroke for a backward compatibility reasons. But we might drop it in near future.

Pushed to ​t/13027 at dev.

[Piotrek Koszuliński]

• Wrong code style - ​https://github.com/cksource/ckeditor-dev/commit/8cb2f86df7cc394ff62acd68dde77f3d0279c507
• Missing version number tag - ​https://github.com/cksource/ckeditor-dev/commit/1b24a1914d7399940d8d5897ae6f27b16583a905

[Marek Lewandowski]

Fixed CSS code style.

As for number tag in startupfocustab.md, this is not a TC coming out directly from this ticket. I just wanted to make sure that we have a test highlighting this config setting.

Do we still want to put current milestone there?

[Piotrek Koszuliński]

As for number tag in startupfocustab.md, this is not a TC coming out directly from this ticket. I just wanted to make sure that we have a test highlighting this config setting.

So don't use the "tc" tag. "tc" tag should always go with a version number - it makes it easier to filter out tests which are not design tests. This one is a design test therefore.

[Marek Lewandowski]

Done with ​git:41d5ebf.

[Piotrek Koszuliński]

R- because this behaviour wasn't implemented:

Up arrow - behaves the same as left arrow in order to support vertical tabs

Down arrow - behaves the same as right arrow in order to support vertical tabs

The rest seem to work fine, but I will continue testing because there's a lot of situations to consider.

[Piotrek Koszuliński]

BTW. Could focused tab has the same border as focused input? The monolithic bg which is used now doesn't look very well.

[Marek Lewandowski]

During implementation, initially I thought about outline: 1px dashed #whatever but it might result with street riots. :)

Honestly speaking I'm for adding some sort of stronger highlight for focused tab. But it needs to do well with mono skin.

[Piotrek Koszuliński]

Another issue:

1. Open ​http://ckeditor.dev/plugins/image2/samples/image2.html
2. Place caret in an image caption.
3. Open link dialog.
4. Focus tab (the only enabled).
5. Using left/right keys you can reach the disabled tabs, but you can't leave them then.

I would expect that I cannot reach the disabled tabs at all, although there may be a11y reasons for letting user do so. In such case the focus shouldn't stuck there.

[Piotrek Koszuliński]

Replying to m.lewandowski:

During implementation, initially I thought about outline: 1px dashed #whatever but it might result with street riots. :)

Honestly speaking I'm for adding some sort of stronger highlight for focused tab. But it needs to do well with mono skin.

I meant a nice blueish border like I have on MacOS and Windows:

On MacOS the same outline is used in richcombos, but on Windows it's a different styling. I think though, that since inputs on Windows and MacOS are styled in the same way, then we can style tabs in this way too.

[Piotrek Koszuliński]

With:

input.cke_dialog_ui_input_text:focus,
input.cke_dialog_ui_input_password:focus,
textarea.cke_dialog_ui_input_textarea:focus,
select.cke_dialog_ui_input_select:focus,
a.cke_dialog_tab:focus
{
	outline: none;
	border: 1px solid #139ff7;
	border-top-color: #1392e9;
}

(I've only added the last selector to this list)

I've got:

Which... doesn't look that great. @a.nowodzinski, help! :D

[Olek Nowodziński]

/cc

[Marek Lewandowski]

Disabled Tabs

Replying to Reinmar:

Another issue:

1. Open ​http://ckeditor.dev/plugins/image2/samples/image2.html
2. Place caret in an image caption.
3. Open link dialog.
4. Focus tab (the only enabled).
5. Using left/right keys you can reach the disabled tabs, but you can't leave them then.

I would expect that I cannot reach the disabled tabs at all, although there may be a11y reasons for letting user do so. In such case the focus shouldn't stuck there.

It's actually a separate issue, it was already there but we didn't saw that since there was no focus highlight at all, so we didn't see what's happening. :)

In fact disabled tabs should be perceivable but it shouldn't be operable. I'm going to create an issue for that.

In fact I didn't know that tabs can be disabled. :D

Reported in #13044.

Focused Tab Styling

Yeah, blue border doesn't do the job, I find it not significant enough. Keep in mind that blue border thing is not a OS related stuff, but it comes straight from our CSS, so it's a custom thing.

[Marek Lewandowski]

I've fixed tab up/down arrows handling and added a minor fixes to CSS.

[Piotrek Koszuliński]

I was close to R- this ticket, because Chrome was crashing when running dialog automated tests, but after restart it's ok.

Fixed on master with ​git:2599ba1.

One follow-up ticket in #13044.

[Piotrek Koszuliński]

Regression: #13114.

[Satya Minnekanti]

Can you please update Help for Editor Dialog in Accessibility Instructions dialog based on this fix.

This is the current info that we have in Accessibility Instructions dialog

Editor Dialog

Inside a dialog, press TAB to navigate to next dialog field, press SHIFT + TAB to move to previous field, press ENTER to submit dialog, press ESC to cancel dialog.

For dialogs that have multiple tab pages, press ALT + F10 to navigate to tab-list. Then move to next tab with TAB OR RIGTH ARROW. Move to previous tab with SHIFT + TAB or LEFT ARROW. Press SPACE or ENTER to select the tab page.

We don't need that info as user does not need any special keys to access dialog tabs they are part of tabbing order

[Piotrek Koszuliński]

I reported #13252 for that - we'll fix this in 4.4.8.