I think it's a valid use case to support different types of coordinates for a grid-like structures. Another example that comes to mind is a chess board, where indices are letter-numeric like in spreadsheets.

@minorninth in your example above, the markup will look like:

<div role="gridcell" aria-rowtext="A" aria-coltext="1">Cell</div>
<div role="gridcell" aria-rowtext="B" aria-coltext="1">Cell</div>

or do you think to support combinations of aria-row/coltext and aria-row/colindex as well? If not, then would it make sense to extend aria-row/colindex definitions to support non numeric coordinates? In some way A, B, C are indices in the letter coordinate system.

or do you think to support combinations of aria-row/coltext and aria-row/colindex as well?

I think that the index should be numeric, and the text should be human-readable, exactly like aria-valuenow and aria-valuetext.

The index is useful for calculations - for example checking if one cell is in a row that's above or below the row for another cell.

Also, I think it'd be a bad idea to extend aria-row/colindex now because that could break existing tools that assume they're numeric.

aria-rowtext and aria-coltext strike me as potentially confusing because it's not the text of the row or column; it's the label (in the generic sense of that word). Would aria-rowlabel and aria-collabel work? Or some other such alternative? Or do you feel remaining parallel with aria-valuetext is easier for authors?

@minorninth, regarding this:

Similarly, for ARIA lists, there should be a way to indicate the text of an ARIA list marker, for example a list that uses a, b, c instead of 1, 2, 3.

Probably a silly question, but wouldn't the indicator text be part of the accessible text?

While I get the use case for the table-related properties you are proposing; I'm afraid I'm totally failing to do so regarding the listitem-related one. Clarification would be greatly appreciated. Thanks!

aria-rowtext and aria-coltext strike me as potentially confusing because it's not the text of the row or column; it's the label

It's analogous to aria-valuenow and aria-valuetext. Suppose you have a slider where you need to choose the size of your popcorn:

<div role="slider" aria-label="Popcorn size"
  aria-valuemin=1 aria-valuemax=3 aria-valuenow=2 aria-valuetext="Medium">
    ...
</div>

In this example, Medium isn't the label, it's the value. There are two ways to express the value - numerically (2 of 3) or with text ("Small", "Medium", "Large").

Same for rows and columns in a spreadsheet. Numerically, the first column index is 1, but its text is "A". Its label isn't A, that's its index. That's an important distinction. The index gives you a way to identify a cell, a label describes what goes in that column, and it's typically found in the column header.

As for lists:

Probably a silly question, but wouldn't the indicator text be part of the accessible text?

On Mac at least, there's a separate AXListMarker role, so when you have an ordered list or unordered list, the index or bullet gets put in a separate accessible node. It's kind of a gap that there's no ARIA equivalent.

Even on Windows and LInux, I believe the accessible name of a

Even on Windows and LInux, I believe the accessible name of a doesn't include the index or bullet character, right?

In terms of HTML list item markers, WebKitGtk and Gecko expose it as part of the accessible text; there's not a separate accessible object. I personally think that's what we would like to see from Blink too.

In terms of ARIA, as you indicated there is no equivalent. We may need to create a property for that during the 1.3 cycle (after role parity, we will be tackling attribute parity). With this in mind, how would you feel about splitting this issue up into two things:

• Solve the spreadsheet problem (which is not a parity issue, but a missing feature)
• Deal with exposing the listitem marker text

Splitting it sounds great. Sounds like we have consensus on the spreadsheet issue.

Nektarios Paisios stated via email:

Initially we were discussing proposing "aria-colindextext" and "aria-rowindextext", but since these were too long, "aria-coltext" and "aria-rowtext" were born.

Speaking just for myself, I prefer the longer versions. They tell me what the properties are for. And the short-property ship has already sailed (e.g. aria-roledescription and aria-keyshortcuts). 😄 I think the Working Group has concluded that a tad longer is acceptable if it brings with it clarity.

Yes, we definitely need this ASAP. It needs to be supported wherever rowindex and colindex are supported. I vote for aria-rowindextext and aria-colindextext for property names to avoid ambiguity in purpose.

FWIW, I just added support in Orca for this. It works with Google Sheets (where it's already being used and exposed, albeit with the shorter and less preferable attribute names).

Yes, we definitely need this ASAP. It needs to be supported wherever rowindex and colindex are supported.

Actually, that won't work. You can put aria-colindex on a row if the the set of columns which is present in the DOM is contiguous, and if there are no cells which span more than one row or column. Then the user agent can calculate the second though the last indices. But aria-colindextext cannot be similarly (reliably) calculated and therefore cannot be supported on row.

Proposal can be found here: #994

Feature landed in Editor's Draft: 55a66bc