Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The placement of focus after opening dropdowns #11838

Closed
Comandeer opened this issue May 27, 2022 · 6 comments · Fixed by #12003
Closed

The placement of focus after opening dropdowns #11838

Comandeer opened this issue May 27, 2022 · 6 comments · Fixed by #12003
Assignees
@mlewand @mmotyczynska
Labels
domain:accessibility This issue reports an accessibility problem. squad:features Issue to be handled by the Features team. type:bug This issue reports a buggy (incorrect) behavior.
Milestone
iteration 55 (v35...

Comments

@Comandeer
Copy link
Member

Comandeer commented May 27, 2022 •
edited by mlewand
Loading

📝 Provide detailed reproduction steps (if any)

  1. Open https://ckeditor.com/docs/ckeditor5/latest/examples/builds/document-editor.html
  2. Focus the text alignment button using the keyboard.
  3. Press Space.

✔️ Expected result

The focus is moved to the first child (first focusable element) inside the open dropdown.

❌ Actual result

The focus stays on the pressed button.

However, some dropdowns (e.g. media embed one) moves focus to the first focusable element upon opening.

❓ Possible solution

Make all dropdowns consistent and move focus to the first focusable element. See ARIA Practices for more info.

📃 Other details

  • Browser: all
  • OS: all
  • Installed CKEditor plugins: N/A

See also #2000.

If you'd like to see this fixed sooner, add a 👍 reaction to this post.
@Comandeer Comandeer added type:bug This issue reports a buggy (incorrect) behavior. domain:accessibility This issue reports an accessibility problem. squad:features Issue to be handled by the Features team. labels May 27, 2022
@mlewand
Copy link
Contributor

mlewand commented May 30, 2022

Question: What should get focused after opening the dropdown?

Should it be the first item or should it be the first active option?

  • CKE4 puts the focus on the active/"pressed" option of the dropdown (an example is font size dropdown).
  • Gdocs is inconsistent:
    • Font family is placing the focus in the active option.
    • Font color dropdown and list style places the focus god knows where - only after the first key press it comes into the dropdown content.
  • Other popular WYSIWYG editors place the focus on the first item always.

So unless the best practices doesn't explicitly say what should be focused we can go either way (whatever will be quicker to implement).

@wimleers wimleers mentioned this issue May 31, 2022
Closed
@mmotyczynska mmotyczynska self-assigned this Jun 7, 2022
@CKEditorBot CKEditorBot added the status:in-progress Set automatically when an issue lands in the "In progress" column. We are working on it. label Jun 7, 2022
@mlewand mlewand mentioned this issue Jun 9, 2022
Closed
@Comandeer
Copy link
Member Author

According to ARIA 1.2 specification and ARIA Practices, it depends on the type of the dropdown. For menus (so basically lists of actions), it should be the first element inside them. AFAIK we don't have typical menus in CKE5. For comboboxes, it should generally be the selected element (or, if nothing is selected, the first one). Most of our dropdowns are comboboxes so IMO it's the way to go.

@CKEditorBot CKEditorBot added status:planned Set automatically when an issue lands in the "Sprint backlog" column. We will be working on it soon. and removed status:in-progress Set automatically when an issue lands in the "In progress" column. We are working on it. labels Jun 14, 2022
@wimleers
Copy link

Sounds good!

FYI: tracking this at https://www.drupal.org/project/drupal/issues/3283801 😊

@CKEditorBot CKEditorBot added status:in-progress Set automatically when an issue lands in the "In progress" column. We are working on it. and removed status:planned Set automatically when an issue lands in the "Sprint backlog" column. We will be working on it soon. labels Jun 28, 2022
@mlewand
Copy link
Contributor

mlewand commented Jun 28, 2022

According to ARIA 1.2 specification and ARIA Practices, it depends on the type of the dropdown. For menus (so basically lists of actions), it should be the first element inside them. AFAIK we don't have typical menus in CKE5. For comboboxes, it should generally be the selected element (or, if nothing is selected, the first one). Most of our dropdowns are comboboxes so IMO it's the way to go.

Thanks for summing it up @Comandeer - this sounds reasonable.

@mlewand
Copy link
Contributor

mlewand commented Jun 28, 2022 •
edited
Loading

  • We need to ensure that all the dropdowns work after it (solid QA testing). For example table dropdown will not work.
  • Our solution should not destroy (crash) existing implementation.
    • It would be nice to log some warning if a dropdown doesn't have anything focusable.
  • As for focusing active/selected item we could implement this logic in https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_dropdown_utils.html#function-addListToDropdown
  • Highlight dropdown might require a dedicated handling because it has a toolbar rather a dropdown.

@mlewand
Copy link
Contributor

mlewand commented Jun 28, 2022

Actually this fix could also resolve #5859 🎉 I just checked Chrome and focusing a button that is outside of viewport (overflowed element) will scroll the viewport nicely to center on the focused option.

@mlewand mlewand self-assigned this Jul 1, 2022
This was referenced Jul 1, 2022
Merged
Closed
@Reinmar Reinmar mentioned this issue Jul 4, 2022
Closed
oleq added a commit that referenced this issue Jul 13, 2022
@oleq
Merge pull request #12003 from ckeditor/ck/11838-placement-of-focus-a…
a95ad5c 
…fter-opening-dropdowns

Fix (ui): Opening a dropdown should focus the first item (or the first active item) for easier navigation and accessibility. Closes #11838. Closes #2000. Closes #11568. Closes #3215. Closes #5859.

MINOR BREAKING CHANGE (ui): Until now, `preventDefault()` was called on the `mousedown` event to prevent the [`ButtonView`](https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_button_buttonview-ButtonView.html) from "stealing" the focus from the editing root. Starting from this editor version, to improve the accessibility of the editor, all instances of the [`ButtonView`](https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_button_buttonview-ButtonView.html) class (and child classes) will automatically focus in DOM when clicked. It is recommended that features that use buttons to manage the content call `editor.editing.view.focus()` after the button was [executed](https://ckeditor.com/docs/ckeditor5/latest/api/module_ui_button_buttonview-ButtonView.html#event-execute) in order to bring the DOM focus back to the editing root to allow users type right away. 
@CKEditorBot CKEditorBot removed the status:in-progress Set automatically when an issue lands in the "In progress" column. We are working on it. label Jul 13, 2022
@Reinmar Reinmar added this to the iteration 55 milestone Jul 14, 2022
@oleq oleq mentioned this issue Sep 8, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mlewand mlewand

@mmotyczynska mmotyczynska

Labels
domain:accessibility This issue reports an accessibility problem. squad:features Issue to be handled by the Features team. type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Milestone
iteration 55 (v35.0.0)
Development

Successfully merging a pull request may close this issue.

Implemented focusing first item after opening a dropdown ckeditor/ckeditor5
6 participants
@wimleers @Reinmar @Comandeer @mlewand @CKEditorBot @mmotyczynska