664384 - Deprecate the concatenation of all cell children to a table and tree table row's accessible name

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

Following a discussion and the filing of bug 664376, we should evangelize for screen readers to better deal with tree tables in the future so that we can deprecate hacking together the strings of all cell children and give that string to the tree row or table row parent as its accessible name. When arrowing up and down, all screen readers on Windows including NVDA rely on the item/table row having that accessible name so they read it automatically. Like Orca on Linux, they should traverse the cell children themselves and give proper info to the users.

Possible targets: July 1, 2013 or January 1, 2014. This should give all commercials enough time to deal with this, and get enough of the user base migrated to a more current version of screen readers so that deprecating this won't break tons of them.

Additionally, we should make it possible to navigate left and right through individual cells of tree tables (e. g. in Thunderbird or Firefox about:config or Bookmarks Manager) so that individual cells can be queried easily.

Comment 1

[James Teh [:Jamie]]

Can you elaborate on how Orca behaves when a row gets focus?

One issue is performance. Having to fetch the content and other info for every cell in the row individually is likely to be incredibly slow if there are quite a few cells. This is basically O(n^2) due to multiple calls for each cell, which is incredibly ugly out-of-process.

Also, I'm concerned about backwards compatibility issues here. Even if we do this, I figure we should still use the name if the row provides it, so we won't actually use the new functionality until the name concatenation is removed.

Comment 2

[Trevor Saunders (:tbsaunde)]

> One issue is performance. Having to fetch the content and other info for
> every cell in the row individually is likely to be incredibly slow if there
> are quite a few cells. This is basically O(n^2) due to multiple calls for
> each cell, which is incredibly ugly out-of-process.

hm, why? you need to make  some number of calls for each cell that is >= 1, but I doubt the number of calls you'll make on each cell is linear in the number of cels, so I think this would be O(n) where n is almost always under  10, atleast  I'm not aware of any xul tree grid's with a large number of columns.

> 
> Also, I'm concerned about backwards compatibility issues here. Even if we do
> this, I figure we should still use the name if the row provides it, so we
> won't actually use the new functionality until the name concatenation is
> removed.

hm, why? you could do this the other way around no?  either way I'll leave that up to you :)

Comment 3

[Trevor Saunders (:tbsaunde)]

Joanie  can you answer part 1 of comment 1?

Comment 4

[James Teh [:Jamie]]

(In reply to comment #2)
> > One issue is performance. Having to fetch the content and other info for
> > every cell in the row individually is likely to be incredibly slow if there
> > are quite a few cells. This is basically O(n^2) due to multiple calls for
> > each cell, which is incredibly ugly out-of-process.
> hm, why? you need to make  some number of calls for each cell that is >= 1,
> but I doubt the number of calls you'll make on each cell is linear in the
> number of cels,
One example is if the cells themselves don't contain content, but we instead have to descend into their children to get content. Maybe this isn't a valid use case; I'm not sure.

> > Even if we do
> > this, I figure we should still use the name if the row provides it,
> hm, why? you could do this the other way around no?  either way I'll leave
> that up to you :)
I feel it's bad to ignore something that is present. What if the author wanted to intentionally override the "name" of the row? We shouldn't just ignore that.

Comment 5

[Trevor Saunders (:tbsaunde)]

(In reply to comment #4)
> (In reply to comment #2)
> > > One issue is performance. Having to fetch the content and other info for
> > > every cell in the row individually is likely to be incredibly slow if there
> > > are quite a few cells. This is basically O(n^2) due to multiple calls for
> > > each cell, which is incredibly ugly out-of-process.
> > hm, why? you need to make  some number of calls for each cell that is >= 1,
> > but I doubt the number of calls you'll make on each cell is linear in the
> > number of cels,
> One example is if the cells themselves don't contain content, but we instead
> have to descend into their children to get content. Maybe this isn't a valid
> use case; I'm not sure.

It seems like that sort of situation would be a bit odd.

> > > Even if we do
> > > this, I figure we should still use the name if the row provides it,
> > hm, why? you could do this the other way around no?  either way I'll leave
> > that up to you :)
> I feel it's bad to ignore something that is present. What if the author
> wanted to intentionally override the "name" of the row? We shouldn't just
> ignore that.

well, you currently ignore the name of the cell itself which causes bug 664376 to be a problem no?  so  I think this is a question of what you ignore in prefernece to what.  There's also the question of what the user expects to hear when they move down a rwo in the table.  For example in about:config I'd just expect to hear about the cell I moved into not the entire row.  That way I'd hear the name of the option, and could arrow over to hear the value or change it.    On the other hand in thunderbird I'd expect though I'm not sure that the from and subject would be different accessibles in the same row, and I'd want to hear both when I changed rows.  So it seems to me like looking at the cells themselves for there names is generically more useful / contains more sumantic information than looking at our concatonation of them.

Comment 6

[Trevor Saunders (:tbsaunde)]

Attachment: irc discussion

Comment 7

[James Teh [:Jamie]]

(In reply to comment #5)
> > One example is if the cells themselves don't contain content, but we instead
> > have to descend into their children to get content. Maybe this isn't a valid
> > use case; I'm not sure.
> It seems like that sort of situation would be a bit odd.
Not if the cells contain interactive controls.

> > I feel it's bad to ignore something that is present. What if the author
> > wanted to intentionally override the "name" of the row? We shouldn't just
> > ignore that.
> well, you currently ignore the name of the cell itself
That's because the cell doesn't get focus; the row does. We only report information about the object that gets focus, not its descendants. If you use object navigation to review the cell, you will hear its name.
> so  I think this is a question of what you
> ignore in prefernece to what.
We don't "ignore" anything. This is a matter of what gets focus. If the cell got focus, we'd speak the cell's info. In this case, the row gets focus. Unfortunately, there's no way to get focus to the cell using the keyboard in Windows at present (covered by bug 664384).

> There's also the question of what the user
> expects to hear when they move down a rwo in the table.  For example in
> about:config I'd just expect to hear about the cell I moved into not the
> entire row.  That way I'd hear the name of the option, and could arrow over
> to hear the value or change it.  
Fair enough. In that case, 1) the row should not concatenate the name, 2) the cell should get focus (not the row) and 3) you should be able to arrow over to the other cell in the row. Unfortunately, neither 2) or 3) are implemented by Mozilla in Windows.

> On the other hand in thunderbird I'd
> expect though I'm not sure that the from and subject would be different
> accessibles in the same row, and I'd want to hear both when I changed rows. 
> So it seems to me like looking at the cells themselves for there names is
> generically more useful / contains more sumantic information than looking at
> our concatonation of them.
That's true, and aside from the performance implications, I agree. However, there are cases when the author might have a better idea of what the row should be "named", and in that case, we shouldn't ignore the name, hence my last statement in comment #1.

Comment 8

[alexander :surkov (:asurkov)]

marking as a11ynext, we shouldn't put it at the bottom of the in-box and figure out right behavior sooner than later.

Comment 9

[Marco Zehe (:MarcoZ)]

I have a feeling this issue has not only slipped, but should also not be left to ATs for performance and other reasons. Jamie, what do you think of this nowadays? I am no longer convinced of my original arguments in comment #0.

Comment 10

[James Teh [:Jamie]]

I don't think we should deprecate this:

1. The ARIA spec says the "row" role should allow name from contents:
https://www.w3.org/TR/wai-aria-1.1/#row
So if we did change this, we'd also have to get this changed in the spec in order to be compliant.
2. Chrome does name from contents too. (Interestingly, it only does this when the row is focusable, which is the only time it matters. If there were some advantage to doing that in Firefox, I think that would be a valid bug, but I'm not convinced there is an advantage.)
3. We'd have to get all ATs on board.
4. There are unresolved backwards compatibility concerns as outlined in comment 1 and comment 7.
5. There are potential performance problems as outlined in comment 1 (and discussed in later comments).
6. We have far bigger fish to fry.

Closing as won't fix.

Comment 11

[James Teh [:Jamie]]

Also, in contradiction to this statement in comment 0:

> Like Orca on Linux, they should traverse the cell children themselves and give proper info to the users.

bug 664376 comment 4 notes that:

> I couldn't check that the fix for bug 659018  actually worked because orca nolonger reads anything in the message view in thunderbird.

That suggests Orca *doesn't* traverse the cells when there's no name.