RE: Operable Grid Cell

I’ve attached a working demo with various types of content, and others can be added within the framework for testing different ATs.

Keep in mind with the country listbox, it may contain hundreds of options as well as with tabular data within the mixed content on the right including accordions, etc.

From: Matthew King [mailto:mattking@us.ibm.com]
Sent: Tuesday, September 30, 2014 6:08 AM
To: Bryan Garaventa
Cc: Alexander Surkov; Joseph Scheuhammer; W3C WAI Protocols & Formats; Alexander Surkov; Yura Zenevich
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.

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<mailto:mattking@us.ibm.com>



From:        Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
To:        Matthew King/Fishkill/IBM@IBMUS,
Cc:        Alexander Surkov <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>, Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>, W3C WAI Protocols & Formats <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, Alexander Surkov <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>, Yura Zenevich <yzenevich@mozilla.com<mailto: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<mailto:mattking@us.ibm.com>



From:        Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
To:        Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>, Matthew King/Fishkill/IBM@IBMUS, Alexander Surkov <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>,
Cc:        Alexander Surkov <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>, W3C WAI Protocols & Formats <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, Yura Zenevich <yzenevich@mozilla.com<mailto: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 -