RE: Operable Grid Cell

> That’s the problem, when focus is on a Gridcell node, no additional 
roles and states are conveyed within the gridcell.

Conveyed by Firefox? Or by the screen reader? Sounds like a bug.

> How would a state for an embedded toggle button be conveyed while focus 
is on a Gridcell node as part of the naming calculation?
 
State is not part of name, but I am assuming you are asking about how a 
screen reader would convey both the toggle name/state and the grid cell 
name/state?

First, if the focus is on the gridcell, I am assuming that ascreen reader 
will read it just like a table cell that contains a toggle button. For 
example, create a standard table cell that contains a toggle and then use 
the JAWS alt+ctrl+left/right/up/down to navigate to that cell. The way 
that is read is exactly how JAWS should read it if navigating a grid with 
the arrow keys and the cell gets focus.

> How do you prevent the entire contents of an embedded listbox control 
from being announced instead of just the selected option using the same 
calculation while focus is still on the Gridcell node?

It is up to a screen reader to decide how to present a listbox. But, the 
same approach that applies to the button applies to the list box. When a 
gridcell containing a listbox gets focus in grid navigation mode, it 
should  be announced in the same way a listbox in a normal table cell 
would get read with the screen reader table reading commands.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To:     Matthew King/Fishkill/IBM@IBMUS, 
Cc:     Alexander Surkov <asurkov@mozilla.com>, Joseph Scheuhammer 
<clown@alum.mit.edu>, W3C WAI Protocols & Formats <public-pfwg@w3.org>, 
Alexander Surkov <surkov.alexander@gmail.com>, Yura Zenevich 
<yzenevich@mozilla.com>
Date:   09/29/2014 08:22 PM
Subject:        RE: Operable Grid Cell



That’s the problem, when focus is on a Gridcell node, no additional roles 
and states are conveyed within the gridcell.
 
I verified this using JAWS and NVDA.
 
I’m not even sure how that would work from a naming perspective.
 
How would a state for an embedded toggle button be conveyed while focus is 
on a Gridcell node as part of the naming calculation?
 
How do you prevent the entire contents of an embedded listbox control from 
being announced instead of just the selected option using the same 
calculation while focus is still on the Gridcell node?
 
 
 
From: Matthew King [mailto:mattking@us.ibm.com] 
Sent: Monday, September 29, 2014 5:58 PM
To: Bryan Garaventa
Cc: Alexander Surkov; Joseph Scheuhammer; W3C WAI Protocols & Formats; 
Alexander Surkov; Yura Zenevich
Subject: RE: Operable Grid Cell
 
Put those elements inside the gridcell just as you describe them. 
That is all you should have to do in terms of markup. 
The web app JS provides the keyboard navigation per the APG. 

Now, if you are using a screen reader, when you put focus in the grid and 
arrow among cells, the screen reader should read the cell contents, the 
cell coordinates, and cell labels in whatever manner that screen reader 
chooses to present that information. 

If the cell content is a pressed toggle, the screen reader should read it 
as such. If that toggle is the only thing in the cell, then pressing enter 
or space should toggle the state if the web app designer has chosen to 
make the cell actionable in grid navigation mode. 

Further, if the cell content is an input of type text, pressing enter 
should put focus in the edit and announce that is now in an edit field. 
One challenge with some screen readers like JAWS is that when navigating 
the grid, one must already be in forms mode. So, there would not be the 
characteristic beep when the edit becomes editable. VoiceOver would not 
have that problem. 

JAWS doesn't really have a way of distinguishing between the navigation 
mode and the actionable mode of a grid. And, I think there is a general 
cause for questioning the need for a "actionable" mode. This is part of 
the APG that I do not like. It seems to me that an interaction pattern 
more like a typical spreadsheet would be better. That is, you are always 
in navigation mode unless you choose to interact with a specific cell. 
Then, when interacting with that cell, you stay in that cell till you are 
done and jump back into navigation mode to move to another cell. This 
would in effect make a single cell "quasi-modal", meaning you are stuck in 
it from a keyboard perspective until you "leave it". There could be a 
variety of ways of leaving, depending on the type of app. 

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com 



From:        Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> 
To:        Joseph Scheuhammer <clown@alum.mit.edu>, Matthew 
King/Fishkill/IBM@IBMUS, Alexander Surkov <surkov.alexander@gmail.com>, 
Cc:        Alexander Surkov <asurkov@mozilla.com>, W3C WAI Protocols & 
Formats <public-pfwg@w3.org>, Yura Zenevich <yzenevich@mozilla.com> 
Date:        09/29/2014 01:24 PM 
Subject:        RE: Operable Grid Cell 




The problem here though isn't the mode of interaction, but rather, how to 
convey differing types of gridcell types to the user.

Take the following example.

There is an interactive grid, with one row from left to right, that 
contains four gridcell nodes.
The user, in Forms/Application mode using a screen reader, moves focus 
between gridcell nodes using the arrow keys, and focus is moved between 
each gridcell node (element with role=gridcell) specifically.
The leftmost gridcell is a toggle button, with a pressed state that needs 
to be conveyed to the user.
The next gridcell is an editable string that needs to convey that it is 
editable to the user.
The next gridcell is a listbox control that needs to be stepped into in 
order to allow selection, and also has a default value that needs to be 
conveyed to the user while focus is on the gridcell node, and the role of 
listbox needs to be conveyed at the same time to convey the purpose of 
this gridcell.
The next gridcell contains embedded content as well as active elements, 
which is a mixed bag of control types that needs to be stepped into while 
conveying this purpose to the user while focus is still on the gridcell.

So, how do you do all of these things at the same time without having to 
resort to offscreen or explicit label strings like "LabelText Toggle 
Button Pressed" for example?

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu] 
Sent: Monday, September 29, 2014 12:12 PM
To: Matthew King; Alexander Surkov
Cc: Alexander Surkov; Bryan Garaventa; Joseph Scheuhammer; W3C WAI 
Protocols & Formats; Yura Zenevich
Subject: Re: Operable Grid Cell

What Matt said.


I was going to point out that the APG section on grid, although centred on 
keyboard access, does hint at how to treat individual gridcells as 
"actionable" (the APG term) vs. "read-only".

But, Matt beat me to it.

--
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
           - G. Bernhardt -