a11y - edit page - sidebar objectBrowser button - cms ui

[Wagner3UB]

Describe the bug The objectBrowser button to access the "choose target", besides lacking an associated label and a correct role, unexpected open when focused via keyboard pressing Tab or Shift+Tab. The focus disappears, and there is no keyboard-based exit "choose target", is a blocking issue.

To Reproduce Steps to reproduce the behavior:

1- Go to https://demo.plone.org/edit 2- enter in edit mode by clicking on the edit button (top-left) 3- Press inside the right sidebar 5- Navigate using tab key until find a objectBrowser button

Expected behavior

• [ ] The objectBrowser button must have label to identify it correctly
• [ ] The button should only be triggered by user command, not on focus. If not triggered, the focus must move forward inside the sidebar.
• [ ] The focus should be redirected to the new 'choose target' tab and remains there until an action (close button or new path select).

Screenshots If applicable, add screenshots to help explain your problem. https://github.com/plone/volto/assets/60133113/9e21b4a5-833b-4f12-b6b2-18f5e976db92

[ASCE-D]

Hello @Wagner3UB I want to contribute in this project, I looked into the issue and reproduced it, I was going thorough the codebase to solve this issue and I could not find where keyboard handlers are assigned. src/components/manage/Sidebar/ObjectBrowserBody.jsx > toggleSearchInput = () => { // Toggle visibility of the search input this.setState(prevState => ({ showSearchInput: !prevState.showSearchInput, }), () => { if (this.state.showSearchInput) { // If search input is shown, focus on it this.searchInputRef.current.focus(); } });

as we can see here the handler just focus and doesn't opens the menu so Is there anywhere else where this keyboard navigation is handled? If not and you know how can I fix this please help me as I'm new to open source and really want to contribute.

[Wagner3UB]

@ASCE-D please read and follow Contributing to Plone and First-time contributors

[JeffersonBledsoe]

Going to use this comment to think out-loud about the current and potential expected behaviour of the object browser widget:

Current

• The label exists as a label, but is linked to a field that doesn't exist
• The 'value holder' is wrapped in a role="searchbox" tabinxed="0". This role is roughly equivalent to an <input type="search" />
• For the 'value holder':
  • When in multiple mode and allowExternals is disabled and there is no value, a div is shown with "No item selected"
  • When in multiple mode and allowExternals is disabled and there is a value (singular or multiple), each value is represented as a div with text
  • When in multiple mode and allowExternals is enabled and there is no value, a text input is shown with a placeholder value
  • When in multiple mode and allowExternals is enabled and there is a link value, each value is represented as a div with text
  • When in multiple mode and allowExternals is enabled and there is text, the input is used until the 'submit' button is pressed, when it becomes a 'link' value.
  • When in singular mode and allowExternals is enabled and there is no value, a text input is shown with a placeholder value
  • When in singular mode and allowExternals is disabled and there is no value, there is no node
  • When in singular mode and allowExternals is enabled or disabled and there is a value, each value is represented as a div with text
• URLs are validated as requiring the protocol. On submit, this is cleaned off and the original URL saved alongside a title which is used for displaying
• The 'open browser' button is not associated with anything and simply has an 'open object browser' aria-label

Expected

• The input should have a label that is linked with the input
• If the widget is in single select mode, we should always be using an input
• If the widget is in multiple select mode, we should be using a listbox of some kind
• Using a 'calendar widget' as inspiration for how to link the button:
  • The button should have an aria-controls linked to the input or listbox
  • The button should have an aria-describedby linked to the input or listbox
  • The button should have an aria-expanded value to represent the open/ close state of the picker
• The object browser does not need special linking to the input, as the context of the browser should be clear from the interaction with the button
  • The object browser body should focus trap on button press to prevent this loss of context

[JeffersonBledsoe]

I started working on a refresh based on the new semantics I discussed above. Screenshots below of some prototyping (there's obvious things wrong with it but it will help clarifying the semantics by seeing it visually)

However, I think this changes the UX too much so I'm going to raise this in the next Volto meeting and we can discuss the various use cases and how we can accommodate those while improving the accessibility of the widget.