Adopting ARIA Grid pattern

Yes, let's look into this and other ARIA patterns too. How about a parent plan issue for discussing the ARIA authoring practices as a whole? I was thinking about updating our vertical tabs to follow these.

Reading through Jesse's article, it seems to follow the ARIA Authoring Practices description fairly closely, so I'm updating the title.

I guess the next steps are:
Consider use cases for Drupal core, and maybe contrib too. Do we currently have any admin pages which would benefit from this?
Look for implementations in the wild, and see what use-cases they try to address. It'll be interesting to see how closely they match the ARIA Authoring Practices.

New parent plan created: #2893640: Modernize ARIA usage, in line with ARIA 1.1 and the ARIA Authoring Practices guide.

The "manage display" interface in Field UI might benefit from this.

It's already a table. Each row has 3 or 4 focusable controls:

• row weight (drag handle),
• label visibility (select),
• formatter (select),
• formatter settings (ajax button, only if settings are available.)

Say a node type has 10 custom fields, and a sighted keyboard-only user wants to change the settings for the last formatter.

• Tabbing through these currently takes 40 tab key presses.
• If arrows controlled focus, reaching the desired button would take 13 key presses (10 down, 3 right).

A quirk: if focus is on a formatter settings button, and the row below does not have a formatter settings button, what happns when the down arrow key is pressed?

The edit-menu form might also benefit from aria grid (e.g. admin/structure/menu/manage/admin).

These rows also have 4 focusable items on each row:

• Row weight (drag handle, or select)
• Menu item name (link to actual destination of menu item)
• enabled (checkbox)
• edit (button)

This interface has nesting too, so it might better suit a Tree View UI.

Yep, so the difficulty will be that Field UI can be nested AND a table, this really depends on what the particular field UI is trying to achieve. When it's merely a "weight" drag and drop, then you can go with ARIA Grid but when you add "nesting" to it with for example field groups it all of a sudden becomes a "tree view". Perhaps we can "auto-detect" this and apply the right semantics.

The proposed layout builder UI may be a good fit for the ARIA Grid pattern. It also involves drag-and-drop. I don't know of any examples of accessible drag/drop layout builders in the wild.

Nested tables present a problem for the pattern. Haven't figured those out yet :)

You can make the UI keyboard manipulable. Check out this tic-tac-toe example: http://oaa-accessibility.org/example/17/

It seems like views tables with focusable inputs such as the one found at admin/content would benefit from ARIA grid

I did some basic screenreader and keyboard navigation testing in admin/content and compared it to the ARIA grid demo here:
https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html#ex...

Being able to navigate through the admin/content table with arrows seems preferable + more efficient than tabbing linearly through each focusable element in a cell. The screenreader interpretation seemed to be a more useful description as well, but I'll need to get further along in my a11y training before I could say that with certainty.

Re. #17: I'm skeptical of the ARIA grid for /admin/content, or other entity listings.

I think ARIA grid is principally aimed at grids where every cell has something to do; spreadsheets are the common example given. But our entity listings are a far cry from that, because there are so many columns without any operable controls in them.

The permissions page could be a better match for ARIA grid. There's a more predictable content model there; 1 cell == 1 checkbox (barring row headers). Site builders aren't going to extend that.

For ARIA grid, it's mandatory to make every cell focusable. Yet our entity listings have several columns which don't contain operable controls. Moreover, they are easily extended by site builders who can add columns for sticky, promoted, comment status, "has translations", etc. I'm worried that making cells focusable which don't have any interactive content inside may be confusing for sighted keyboard users. I don't think we should use it without user testing, or until it has become much more familiar though widespread implemention.

The screenreader interpretation seemed to be a more useful description as well

Can you elaborate on that? Is there a particular feature of ARIA grid which you have in mind.

I don't think it provides any benefit for screen reader users which aren't already available in the table navigation tools that the screen reader provides. There isn't a clear justification for overriding these with custom behaviours. I'd worry that it introduces a severe maintenance or regression risk; if one attribute is mis-handled, the whole structure could have problems.