Mark grid UI components with semantical markup

[mlewand]

So far we have handled only keyboard interaction for grids in #11851 but in order to make grids accessible we also need to provide proper semantic annotation for it.

Most importantly user needs to have semantic information that this is a two dimensional widget (columns and rows).

We need to ensure that all grid components already existing in the editor gets this improvement.

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[mlewand]

We focused exclusively on keyboard handling so far - but we need to remember that semantical markup is core requirement for this component.

I started a research on markup that we should produce for accessible grid components. The benefit of semantically marked grid is that it will convey information that this is a 2 dimension widget (has rows and columns).

Other editors

• Google Docs - it implements grid/gridcell roles on top of a <table> element - so they went an extra mile ensuring that metadata is conveyed.

Others simply don’t implement it well. They simple are using options.

• CKEditor 4 - grid is conveyed as a linear data set. Also there’s no up / down arrow handling.
• Other js WYSIWYG editor - Also linear data set (but it handles up/down arrows well).

Available options

• Just use a <table> with a grid role and gridcell role on focusable elements.
  • :-1: We need to explicitly know number of items per row.
  • :-1: More markup hassle.
  • :grey_question: Rendering table with a fixed layout could be actually faster than any other approach?
• Use shallow, linear markup for items in grid and use div[role=row] with [aria-owns] to mark relations which row contains which item.
  • Demo https://codepen.io/mlewand/pen/xxWjwaM
  • :+1: It's possible to implement such solution for dynamical number of columns (as long as column number is observable).
  • :-1: We'll have to observe item count and change the number ow div[role=row] at runtime.
  • :-1: Uses more complex WAI-ARIA markup that is not known to everyone.
  • :-1: Requires us to generate id for each item and pass this item to [aria-owns] attribute.

Rejected options

• Using aria-rowcount on grid element and aria-rowindex on gridcell.
  • I made a test at https://codepen.io/mlewand/pen/ZExxqwK
    • Rowless is not read properly on NVDA in chrome :disappointed:
    • Regular with role=row wrappers is read properly.

[Comandeer]

It seems that an example with a dynamic row count is a no go – it's incorrectly handled by both NVDA and VoiceOver. The most promising one is the method with [aria-owns] – it's correctly handled by VO, NVDA, and JAWS and it does not require "tablesque" structure.

But, tbh, the easiest one would be to use table which would provide us with nearly everything out of the box. The biggest issues with tables are probably their issues with responsivity and the fact that we will need to calculate the whole table before displaying it to the user. OTOH, we would probably also need to calculate the whole [aria-owns] grid before rendering – otherwise, it would cause quite a reflow. So… the only real advantage of the [aria-owns] method is the ability to break free from the standard structure of the grid and introduce some additional divs (or omit them) if we want to.

[jmegginson]

The special characters buttons in the CKEditor allow for arrow key navigation, but the markup does not insinuate to users of screen readers that they are navigable with up/down AND left/right arrow keys.

In lieu of the proposed ARIA grid (role) my organization has extended the default special character buttons in CKEditor5 by adding ARIA menu and menuitem roles. This to-date has helped provide our customers the information (direction and cues) that the buttons are navigable through two-dimensional or bi-directional means.

However, our accessibility office agrees with this ticket that ARIA grid along with row and gridcell roles is the optimal markup. The aria-rowindex and aria-colindex properties (permissible on the row role per the ARIA 1.2 specification) would be ideal to (help) convey the bi-directional cues to users of screen readers.