[EuiDataGrid] Toolbars should be ARIA toolbars

[myasonik]

Proposal

Both the over and under toolbars should probably become ARIA toolbars. Other than getting a special role, they get some special tab management (they are also 1 tab stop), and they can be better described (to tie them to the grid).

References

• https://www.w3.org/TR/wai-aria-1.1/#toolbar
• https://www.w3.org/TR/wai-aria-practices/#toolbar
• https://www.w3.org/TR/wai-aria-practices/examples/toolbar/toolbar.html

Alternatives

• Nothing. Could do nothing but that leaves the problem of there being nothing tying the controls to the grid they influence
• An ad hoc solution we make up. It could be something like wrapping the whole thing in a role=group or role=region and adding a lot of descriptive text all over the place. This could work but would require lots more explaining.
• Some combination. This might not actually be a bad idea but maybe better to think about after implementing the the current proposal. Because the whole widget is so large defining it as a standalone group or region might still be helpful. I think, also, a strong argument could be made for the bottom toolbar becoming more confusing for visual, keyboard users with roving focus management so maybe ultimately the top one becomes a proper toolbar and the bottom one stays as is with some ad hoc ARIA labeling where needed but this will require some experimentation.
• Using menu or menubar. Two very related roles that either/both "toolbars" could become but they're harder to implement with lateral gains so I see no reason to.

[chandlerprall]

If we update the bottom bar (which is now only pagination) to be a toolbar we should probably do the same for EuiInMemoryTable, if not other places. I'm particularly worried about having multiple tabbing/keyboard patterns that we'd need to track and their affect on users.

[myasonik]

+1 to updating our table implementation. I had been thinking about that too but wasn't focusing on that right now. Is it worth a separate ticket?

I could be unaware, but I haven't heard of us doing any user testing before. Until we do, I'm usually on the side of try to conform to standards as much as possible because otherwise we're just guessing at what users want.

From a technical perspective, I think we could abstract the two other focus management systems that I can think of (but I'd suggest doing this after we have a couple of examples built into EUI):
0. Normal, default focus (no abstraction needed)

1. Roving focus (setting tabIndex to -1 to everything inside a widget, using arrow keys or something other than tab to move browser focus - like what we do in DataGrid)
2. Active descendant (using aria-activedescendant instead of browser focus which you're supposed to do for things like typeaheads and a few other things)

[chandlerprall]

+1 to updating our table implementation. I had been thinking about that too but wasn't focusing on that right now. Is it worth a separate ticket?

I'd prefer seeing that change happen in both places at the same time, instead of having a split in functionality between the two components for any amount of time.

I could be unaware, but I haven't heard of us doing any user testing before.

@ryankeairns can fill you in on our efforts there

I'm usually on the side of try to conform to standards as much as possible

👍

[snide]

I took a "quick" stab at this yesterday and decided to push this past our initial v1 release. Agree a toolbar is the way to do, but it'll require wiring up a lot of keydown events. For now, everything in the "toolbar" is accessible, just not optimally so.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[github-actions]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[github-actions]

❌ Per our previous message, this issue is auto-closing after having been open and inactive for a year. If you strongly feel this is still a high-priority issue, or are interested in contributing, please leave a comment or open a new issue linking to this one for context.