(ARIA) Focusable rows break table header announcement
Hans Hillen
I'm currently working on an email application that has email messages listed in a table. It's a web 2.0 application
geared towards ARIA, and therefore targeted at screen readers running in non-virtual mode. The application itself is
therefore marked up with a role of application, and the message table is marked up with a role of grid. The cells are
either gridcells, columnheaders or rowheaders. The application allows cell based or row based navigation. Initially the
whole row is selected. The user can then use the left / right arrow keys to move through the row one cell at a time,
allowing individual cells to be announced separately. If the user goes all the way to the left (beyond the first column)
the whole row will be selected again. When using the up and down arrow keys, focus is moved to the row or cell above
or below the current selection, depending on whether the whole row was focused or just one column.
Initially, I didn't allow the whole row to be focused, only the cells (using tabindex=-1). When testing with WindowEyes
6.1, it correctly announced both column and row headers whenever a cell was selected (even with browse mode turned off).
JAWS didn't announce the headers without virtual mode, but that's a different issue (if you know how to get JAWS to
announce table header information with virtual mode turned off, please let me know).
The current problem is that the moment I made the grid rows focusable as well (again using tabindex=-1), Window Eyes
stops announcing the header info whenever a gridcell is selected ( it now just says 'cell' after the cell's text). When
I look how the MSAA of the table is exposed, it appears that making the row focusable now places the TR element as a
direct parent of the cell in MSAA. If the row is NOT focusable, the MSAA parent is the tbody element. Also, it appears
that Firefox is exposing the role of the TR element as '"tr" [ BUG? State/Role should not be a string ]' (both FF2 and
the latest FF 3 nightly). I'm assuming that this is why WindowEyes is not announcing those headers anymore. I've tried
overriding the row's role, by giving it a role of 'presentation' (hoping the Tbody element would be considered as the
cell's parent again) or 'row', but this didn't work.
To illustrate: here's a simple example of a table with focusable cells as well as rows. To keep the code simple I made
the cells and rows focusable by adding a tabindex value of 0, to you can tab through both rows and cells. To see how it
SHOULD work, remove the tabindex attributes from the row elements (just search and replace '<tr tabindex="0">' with
'<tr>'). Now load WindowEyes, and press ctrl + shift + H (this rotates through table header announcement options) until
you hear 'column and row'. Now whenever you tab to a cell, WindowEyes will speak its headers. But as I said, when you
leave the tabindex values on the rows, it will not.
<table role="wairole:grid">
<thead>
<tr>
<th role="wairole:columnheader">name</th>
<th role="wairole:columnheader">location</th>
<th role="wairole:columnheader">age</th>
</tr>
</thead>
<tbody>
<tr tabindex="0">
<th tabindex="0" role="wairole:rowheader">Mary</th>
<td tabindex="0" role="wairole:gridcell">San Francisco</td>
<td tabindex="0" role="wairole:gridcell">34</td>
</tr>
<tr tabindex="0">
<th tabindex="0" role="wairole:rowheader">John</th>
<td tabindex="0" role="wairole:gridcell">New York</td>
<td tabindex="0" role="wairole:gridcell">27</td>
</tr>
<tr tabindex="0">
<th tabindex="0" role="wairole:rowheader">Dan</th>
<td tabindex="0" role="wairole:gridcell">Los Angeles</td>
<td tabindex="0" role="wairole:gridcell">30</td>
</tr>
</tbody>
</table>
Does anyone know why making a row focusable would break the table header announcement, and more importantly, how to work
around this? On a side note, I've been seeing these '[ BUG? State/Role should not be a string ]' role values a lot, is
this something I can solve as a web developer, and / or should I file this as a bug?
Regards,
Hans Hillen
Aaron Leventhal
https://bugzilla.mozilla.org/show_bug.cgi?id=400539
There's nothing we can do on the Firefox side about this. We'll need
assistive technologies to accept that some rows may have objects.
We need an object for a focusable row, to fire the focus event on. So
Firefox really must expose that object, and that confuses screen readers
that expect only cells in the table.
If you want a given column header to be read as the user navigates to a
particular cell, you could put aria-labelledby on each cell and have it
point to the appropriate columnheader.
- Aaron
Jon Gunderson
Here is a demo of an e-mail list using ARIA markup:
http://test.cita.uiuc.edu/aria/grid/grid1.php
Jon
>_______________________________________________
>dev-accessibility mailing list
>dev-acce...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-accessibility
Jon Gunderson, Ph.D.
Coordinator of Assistive Communication and Information Technology (DRES)
WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/
Hans Hillen
as cells. How would you implement cell by cell navigation in this design?
Initially, before using columnheaders, I tried labelledby and describedby properties to associate each cell with its
header as well. I wasn't too happy with the results though: Labelledby caused the screen reader to only read the label,
not the cells actual text. Describedby worked better, but WindowEyes would read the description after the value and
role: 'Hans, cell, from'.
I would rather have this to be spoken the way it should, meaning:
- navigating sideways (cell by cell within a row) will say the column header first, like this: 'from: Hans' ->
'subject: ARIA question' -> 'date: 04-13-2007'.
- navigating up and down will say the row header first (let's say the row header is the 'from:' cell, and we're
navigating down the 'subject' column), like this: 'Hans: ARIA question' -> 'Jon: ARIA answer'.
I guess the biggest issue that prevents this is the AT support, as Aaron said. Maybe I should be hassling Doug about this.
Regards,
Hans Hillen
Al Gilman
>Thanks Aaron and Jon, this is very helpful. I like the approach
>taken in the UIUC example, where the rows are marked up
>as cells. How would you implement cell by cell navigation in this design?
Hans,
I haven't worked through the details, so YMMV. But I think that the
'treegrid' role
will be desirable for email applications. For example, in a thread
view, it will be
very convenient to be able to collapse threads or sub-threads of a given long
discussion. Even when viewing by author it would be very helpful to be able
to compress motormouths so as to get the whole thing collapsed to just a list
of people and expand to individual messages from one or more of these
as desired.
The 'treegrid' is a structure where we worked to ensure that row-by-row and
cell-by-cell navigation motions were both supported.
http://www.w3.org/TR/aria-role/#treegrid
Compare with Earl's use cases for an 'accordion.' One of my untested
hypotheses
is that 'accordion' could be built with 'treegrid' and we don't know if we need
one role or two until all the keystrokes are mapped out and it is
either natural
for both or weird for one and natural for the other.
Al