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.

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

DataViews: Improve keyboard accessibility in grid layout #56330

Open
andrewhayward opened this issue Nov 20, 2023 · 0 comments
Open

DataViews: Improve keyboard accessibility in grid layout #56330

andrewhayward opened this issue Nov 20, 2023 · 0 comments
Labels
[Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Enhancement A suggestion for improvement.

Comments

@andrewhayward
Copy link
Contributor

Related: #55083

What problem does this address?

Currently every focusable element (or "widget") in a list layout (header action buttons, linked items, etc) presents as its own tab stop. This can make it difficult and tedious for a non-mouse user to move across content.

The Data Views grid layout, showing the tab flow across the cards.

What is your proposed solution?

We should utilise an interactive grid to reduce the number of tab stops on the page, and allow users to more efficiently navigate the data:

The grid pattern can be used to group a set of interactive elements, such as links, buttons, or checkboxes. Since only one element in the entire grid is included in the tab sequence, grouping with a grid can dramatically reduce the number of tab stops on a page. 1

We will have to be careful however how we implement this pattern. At first glance, we might say that each card is a cell within the grid, and directional navigation keys could be used to jump from card to card:

The Data Views grid layout, showing a card circled in red, with arrows indicating potential navigation directions to other cards.

This makes it hard to navigate the interactive elements within each card though, as they should not have their own tab stops.

Instead, we could conceptualise each card as a row in a table, with each interactive element within it a cell. This would mean that users could navigate between each card using the up/down arrow keys, and left/right to move between elements within each card. "Horizontal" navigation could either loop within each card, or jump to the first/last interactive element of the next/previous card.

The Data Views grid layout, showing a single card circled in red, with arrows indicating internal and external focus flow.

Alternatively, each navigable element could be a cell within a larger grid, with the card wrappers entirely presentational from a navigation perspective:

The Data Views grid layout, with the component parts of a single card broken into a sub-grid. Navigation between these sub-cells is indicated with arrows.

Without some experimentation, it is hard to say which of these flows would feel more natural. The third option, of breaking down the entire layout into a sub-grid, is probably the most intuitive, particularly if we appropriately mark each card as a group, and implement access keys such as Home, End, Page Up and Page Down to navigate within and between cards.

Footnotes

  1. W3 Grid Pattern: Layout Grids

@andrewhayward andrewhayward added [Type] Enhancement A suggestion for improvement. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond labels Nov 20, 2023
@oandregal oandregal changed the title [Data Views] Improve keyboard accessibility in grid layout DataViews: Improve keyboard accessibility in grid layout Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

1 participant