RE: Grid and aria-owns question

Matt,
I see what you mean, unfortunately it appears that even basic support for interactive Grid constructs is still flaky based on the expected user interaction for navigating these.

I'll show you an example of this, which highlights the conflicts between what different users expect to happen as opposed to what does happen.

This implementation uses that method I was telling you about earlier where focus is set on the role=gridcell node but aria-activedescendant on the same element points to the embedded button role, which causes the accessibility tree to see the embedded element as having focus. This works very well since all of the supporting states are correctly conveyed when this is done, such as the role of button, the state of pressed or not pressed, as well as disabled when applicable, which does not occur reliably otherwise when browsing the Grid in Applications Mode using the arrow keys.

The issue occurs however when the screen reader tries to predict what type of user interaction is needed, and in the case of JAWS, ends up doing nothing at all.

So to reproduce this, using JAWS18, try the following in IE11 or Firefox:

  1.  Open the test page at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20(Dynamic)/demo.htm

  1.  Using the table navigation commands in Virtual Cursor Mode, navigate into one of the cells that is not a row or column header or a toggle button, and press Enter to activate Applications Mode.
  2.  Now press Home or End to jump to the right and left of the current row, Up or Down to navigate by row, Left or Right to navigate by cell, PageUp or PageDown to navigate by page, and Ctrl+Home or Ctrl+End to jump to the first or last pagination page.
  3.  Exit Applications Mode, and then check the Editable radio button to now make the Grid configurable.
  4.  Navigate back into the Grid in Virtual Cursor Mode by pressing T to jump to the Grid table, then using the table navigation commands, navigate to one of the 'Editable' buttons within the Grid page cells.
  5.  Now press Enter to perform the desired action.

What you will notice on step #6, JAWS will neither activate the button nor enter Applications Mode to allow for Grid navigation as it did in step #3, regardless that the scripting is exactly the same and the Grid is coded with precise focus handling and ARIA role usage.

So what do you think the desired interaction should be, should JAWS enter Applications Mode to allow for Grid navigation, or should it stay in Virtual Cursor Mode and instead activate the embedded button?

What if the user wants to use the Grid navigation methods and does not actually want to activate the button, how do they then do so if JAWS ignores Application Mode and only activates the button?

Which combination of interactions is correct, and what do users expect to happen?

If you run these same tests using NVDA in Firefox for example, you will notice that you can't activate Application Mode at all by interacting with the Grid, making it extremely non-intuitive from a usage perspective if you want to use the pagination keystrokes. Is this important?

In this Grid implementation, none of the buttons are focusable, only the Gridcell node is, which is used to handle all event interactions that relate to the embedded active element role. The use of aria-activedescendant just makes it sound like you are interacting with the embedded button role instead.

Interestingly enough, this implementation works perfectly in iOS using VoiceOver for touch device support.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com

From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Friday, April 28, 2017 4:20 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; 'Lars Holm Sørensen' <lhs@diversa.dk>; w3c-wai-ig@w3.org
Subject: RE: Grid and aria-owns question

Bryan,

In your final suggestion, you have it right. The aria-readonly attribute is most useful in  a grid in a spreadsheet-like application where there is a mix of editable cells and read-only cells. Then you might want to consider using aria-readonly as the way of distinguishing among them.

But, aria-readonly is not the only way you can communicate a distinction between editable and non-editable content.

For instance, if most of the grid is static text and links, instead of marking all the static text readonly, which would be super annoying, in the few cells where text is editable, you could put a button in that cell where the button label is the cell text. Activating the button places the user in an edit field. You can see this technique demonstrated in the second example on this page:
http://w3c.github.io/aria-practices/examples/grid/dataGrids.html

On the other hand, if you are making something that is more like a spreadsheet, then you probably want to put aria-readonly on cells where the user cannot change the content.

The purpose of aria-readonly is not to make the affordances of the grid itself perceivable. Generally speaking, there are many aspects of the design of an application that tell users what capabilities are present.  So, users will know from various aspects of the design and context whether or not they are using something that is like a spreadsheet where they should be able to change the content of any cell.

Basically, putting aria-readonly on the grid is a short cut for propagation to cells for situations where all cells need to have a value for aria-readonly specified. Such grids are rare.

The aria-readonly attribute, when applied to the grid,  says nothing about the grid itself. So, one of the things I am hoping we get away from is screen readers calling the grid itself editable or readonly.

This is an issue I have been hoping the new 1.1 spec text as well as the authoring practices design pattern and examples will clear up.

Matt

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Friday, April 28, 2017 3:06 PM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; 'Lars Holm Sørensen' <lhs@diversa.dk<mailto:lhs@diversa.dk>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: RE: Grid and aria-owns question

"Also, you do not need aria-readonly."

Hi Matt,
When would you use aria-readonly on a grid?

It was my understanding that when you have an interactive grid, if the cells are not meant to do anything when activated it is readonly, but if they are meant to do something when activated, then it is not.

E.G The following landing page shows a readonly interactive Grid:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20(Dynamic)/demo.htm

To make this actionable, check the Selectable checkbox and if you wish toggle aria-selected to checked as well, then focus back on the Grid and use the Spacebar to toggle selection.

I guess it can be argued that this still doesn't need aria-readonly, but what about the case when you have a row that includes some cells that are editable and others that are not, which is the case in this Grid if you check the Editable checkbox, where the row header cells are not editable wheras some of the others are.


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://www.SSBBartGroup.com>

From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Thursday, April 27, 2017 10:50 AM
To: 'Lars Holm Sørensen' <lhs@diversa.dk<mailto:lhs@diversa.dk>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: RE: Grid and aria-owns question

Lars,

This is a creative structure- very interesting.

Your use of aria-owns is correct. You have found a Firefox bug that you should report to Mozilla.

It is not likely this will ever work in IE unless you can get screen reader devs to make it a priority.

Note that you should have role="presentation" on the `ul` elements.

Also, you do not need aria-readonly.

We now have a complete ARIA grid pattern and multiple functional examples in the ARIA Authoring Practices that I recommend you read:
http://w3c.github.io/aria-practices/#grid

Matt King

From: Lars Holm Sørensen [mailto:lhs@diversa.dk]
Sent: Thursday, April 27, 2017 7:40 AM
To: w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: Grid and aria-owns question

Hello WAI list

I am trying to construct a simple data table, from some list data by applying role="grid", role="row", role="columnheader", role="gridcell" and aria-owns.

In my simple example I try to construct a grid with 2 columns and 3 rows. Column 1 for fruits and column 2 for vegetables.
The first row is a header row and then follows two rows with data.


When testing with Jaws I get the expected result in Chrome. A grid with 2 columns and 3 rows and I can navigate it using the Jaws table navigation keys.

However in IE and FF I get different results.

They both show the header row perfectly.

Then follows two rows where each row only has a single column, but still in that single column it reads the data from both column 1 and column 2.

Then follows four columns, each showing data from one of the four gridcells.

Here comes the Jaws output from going through the grid by just pressing down arrow IN ff:

grid with 2 columns and 5 rows
Fruits
Vegetables
Apple Potato
row
Banana Cucumber
row
Apple
Banana
Potato
Cucumber
grid end


Here comes the code:

<div role="grid" aria-readonly="true">

<!-- The header row. -->
<div role="row">
<ul>
<li role="columnheader">Fruits</li>
<li role="columnheader">Vegetables</li>
</ul>
</div>
<!-- eof header row-->


<!-- Add content to row one in the accessibility tree by using aria-owns.-->
<div role="row" id="row1" aria-owns="row1_col1 row1_col2"></div>

<!-- Add content to row to in the accessibility tree by using aria-owns.-->
<div role="row" id="row2" aria-owns="row2_col1 row2_col2"></div>



<!-- The two lists with the data we want to go into the grid.-->
<ul   id="col1">
<li role="gridcell" id="row1_col1">Apple</li>
<li role="gridcell" id="row2_col1">Banana</li>
</ul>

<ul  id="col2">
<li role="gridcell" id="row1_col2">Potato</li>
<li role="gridcell"  id="row2_col2" >Cucumber</li>
</ul>

</div>
<!-- eof grid-->


Do you have any ideas why it doesn't  work the way I expect it to in IE and FF?

Am I using aria-owns in an inappropriate way?


Best regards:
Lars Holm Sørensen



De bedste hilsner
Lars Holm Sørensen
Diversa ApS
Tlf: 25 21 17 41
www.Diversa.dk<http://www.diversa.dk/>

Udelukker du 10% - 20% af brugerne fra din hjemmeside? Se videoen!<https://www.youtube.com/watch?v=CM9lgzNBvZA>
[se videoen her]<https://www.youtube.com/watch?v=CM9lgzNBvZA>