RE: Grid and aria-owns question

Sean,

 

I am less pesamistic. Someday we will have screen readers with user
interfaces that are much easier to learn and understand and their behaviors
with ARIA widgets will be much more reliable. 

 

But, again, before we can help the screen reader developers get there, we
need broader consensus on what is and is not good ARIA practice. That is
where I am focused at this moment.

 

As such consensus starts forming, I will start putting more energy into
promoting higher quality support of ARIA across all screen readers. The only
reason I mentioned JAWS in my post was because Bryan specifically asked for
my opinion about JAWS behavior. 

 

Matt

 

From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com] 
Sent: Sunday, April 30, 2017 5:58 PM
To: Matt King <a11ythinker@gmail.com>; '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

 

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. J

 

Sean Murphy

Accessibility Software engineer 

seanmmur@cisco.com <mailto: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
<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,

 

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%20Gri
d%20(Dynamic)/demo.htm

2.	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.
3.	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.
4.	Exit Applications Mode, and then check the Editable radio button to
now make the Grid configurable.
5.	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. 
6.	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>; '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%20Gri
d%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> 

 <https://www.youtube.com/watch?v=CM9lgzNBvZA>