Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#13027 closed Bug (fixed)

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

Reported by: Satya Minnekanti Owned by: Marek Lewandowski
Priority: Must have (possibly next milestone) Milestone: CKEditor 4.4.8
Component: Accessibility Version:
Keywords: IBM Cc: Damian, Irina

Description

To reproduce the defect:

  1. Open http://nightly.ckeditor.com/15-03-10-07-08/full/samples/replacebyclass.html.
  1. Open any dialog that has multiple tabs ( ex: Table Properties)
  1. Navigate dialog using keyboard.

Actual Result

  1. when a dialog opens focus going in to first field in tab panel that's opened.
  1. User has to press Alt + F10 to access tab list from a tab panel.
  1. 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.)
  1. 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

Attachments (2)

focus.png (14.5 KB) - added by Piotrek Koszuliński 3 years ago.
focus2.png (19.2 KB) - added by Piotrek Koszuliński 3 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 Changed 3 years ago by 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.

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

comment:3 Changed 3 years ago by Frederico Caldeira Knabben

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

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

comment:5 Changed 3 years ago by Marek Lewandowski

Owner: set to Marek Lewandowski
Status: newassigned

comment:6 Changed 3 years ago by Marek Lewandowski

Status: assignedreview

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.

comment:8 Changed 3 years ago by 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?

comment:9 Changed 3 years ago by 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.

comment:10 Changed 3 years ago by Marek Lewandowski

Done with git:41d5ebf.

comment:11 Changed 3 years ago by Christophe Guillou

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

comment:12 Changed 3 years ago by Frederico Caldeira Knabben

Priority: NormalHigh

comment:13 Changed 3 years ago by Piotrek Koszuliński

Status: reviewreview_failed

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.

comment:14 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by 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.

Last edited 3 years ago by Marek Lewandowski (previous) (diff)

comment:16 Changed 3 years ago by 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.

comment:17 in reply to:  15 Changed 3 years ago by 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.

Changed 3 years ago by Piotrek Koszuliński

Attachment: focus.png added

Changed 3 years ago by Piotrek Koszuliński

Attachment: focus2.png added

comment:18 Changed 3 years ago by 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

comment:19 Changed 3 years ago by Olek Nowodziński

/cc

comment:20 Changed 3 years ago by 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.

Last edited 3 years ago by Marek Lewandowski (previous) (diff)

comment:21 Changed 3 years ago by Marek Lewandowski

Status: review_failedreview

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

comment:22 Changed 3 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.4.8
Resolution: fixed
Status: reviewclosed

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.

comment:23 Changed 3 years ago by Piotrek Koszuliński

Regression: #13114.

comment:24 Changed 3 years ago by 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

comment:25 Changed 3 years ago by Piotrek Koszuliński

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

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