RE: Grid and aria-owns question

Matt,

I wouldn't only focus on FS here, you need to include all screen readers on all platforms. A consistent UI is really required. Some screen readers have a very complex range of commands to a very simple ridget command structure. Different approaches have been adopted to navigate a web page from the Mac method of navigating objects (elements) to the virtual buffer and others.  Other screen readers have a very non-standed keyboard layout which people are used too, and so on.

The fixing of the issue you have outlined will not be fixed any time in the near future due to so many people's different point of view on how you should use a screen reader. This ranges from the novis user to the advance as they all have different requirements. Some users get frustrated if they don't have flexability and others get confused if there are to many choices, and the story goes on. :)

Sean Murphy
Accessibility Software engineer
seanmmur@cisco.com
Tel: +61 2 8446 7751       Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com
 Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Sunday, 30 April 2017 6:34 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,

So far my focus has been on building reference implentations of ARIA patterns using W3C processes to gain broad consensus. Once we have more common understanding of what appropriate use of ARIA is based on the ARIA specification, it will then be possible to have more productive discussions with screen reader developers about how to support those patterns and arrive at good answers to questions like the ones you have raised.

Screen reader developers have quite a bit of work to do when it comes to making operating web pages, and especially composite ARIA widgets, more intuitive and understandable. There are a lot of inconsistencies. I don't yet know if the inconsistencies are primarily a result of bugs, misunderstandings, or a lack of a holistic design strategy. I tend to think it might be all three of these factors, which is another reason why I am so focused on building reference implementations of ARIA widgets.

Specifically you ask:

>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?

This same kind of question needs to be answered for all composites. Consider a tab in a tablist or a link in a treeview.

If I could make this decision for Freedom Scientific, I would advise them to make a whole raft of changes to simplify their user experience. One of my primary objectives would be to dramatically reduce the number of key commands needed to use JAWS productively. As part of that simplification, I would make sure that the key that switches which cursor is active is not the same as the key that emulates a mouse click when the reading cursor is active.

Currently, enter can perform a mouse click on a button or it can make the PC cursor active. Which task it performs is rather unpredictable unless you are a true JAWS expert. The fact that it can do both of these things depending on context has been a source of oodles and oodles of JAWS bugs and a lot of confusion over the years.

If Freedom Scientific someday agrees that their design of enter key behavior for web pages is not well-suited for today's web, I think they will come up with a good answer to your question.

If it was me choosing, when the reading cursor is active, enter would never perform a mouse click but instead always activate the PC cursor, and if the reading cursor were on a focusable element, focus would be placed on that element. Obviously, then, another press of enter would activate that focusable element.

I would choose a different reading mode key for emulating a mouse click at the point of the reading cursor. And, I would make quite a few other changes to JAWS behavior when performing those mouse clicks, especially when the element being clicked is clickable but is not focusable and does not have a widget role.

Matt

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Saturday, April 29, 2017 3:05 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

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<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://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<mailto:bryan.garaventa@ssbbartgroup.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

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>