You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When adding a new facet, keyboard users must tab through edit and delete buttons for any and all existing facets before being able to navigate the sidebar. Tabbing away from the Facets field set moves focus to the "Add a column" dropdown, followed by edit and delete buttons for any and all existing columns. These should not be in the focus order after the "Add" button for a facet has been activated and the sidebar has been opened. Instead, focus should, after activation, move directly to the sidebar. Elements outside of the sidebar may need to be deemed inert while the sidebar is open; aria-modal or aria-hidden attributes may otherwise be appropriate here. A visual of the focus order is as follows:
Closing the "Configure facet" sidebar via the "Close" or "Set facet" buttons causes focus to move to the container of the page, followed by the footer elements. This is not a logical order. As per SC 2.4.3, closing the sidebar via the "Close" button, which essentially cancels the operation, should instead move focus back to the original trigger element, the "Add" button. Closing via the "Set facet" button should move focus to the edit button for the newly added facet.
All of the above is also true for configuring and setting columns (less the tabbing stops in the Columns field set).
This pretty much applies to any area that uses the sidebar pattern, especially those where the sidebar is collapsible.
The text was updated successfully, but these errors were encountered:
Initially reported in omeka-s-modules/FacetedBrowse#60.
This pretty much applies to any area that uses the sidebar pattern, especially those where the sidebar is collapsible.
The text was updated successfully, but these errors were encountered: