783972 - Don't expose selectable state on table cells that aren't likely to be selected

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Currently, Gecko exposes the selectable state on all table cell accessibles. I don't think this makes sense for non-interactive table cells which can never be selected. The problem is how to determine "non-interactive". For list items, it's clear; <li> or @role="listitem" is non-interactive, whereas <option> or @role="option" is interactive. Unfortunately, there's no such clarity for tables.

The rationale here is that in NVDA (and probably other screen readers), we change the way the selected state is reported based on whether being selected is the more common case. For example, for a selectable list item, we don't report "selected" when it is selected (since that's most common for the focus), but instead report "not selected" when it isn't. However, for a tab control, we speak "selected" for selected tabs because that's the less common case. We'd like to apply the former rule to interactive table cells, but currently, this would cause all non-interactive table cells (e.g. in simple documents) to report "not selected", which is hideous.

One way to determine interactivity of table cells might be to use the focusability of the cell or its parent row. If the cell or row is focusable, the cell is probably selectable. If not, it probably isn't.

I realise this is a bit controversial and confusing. I can only hope it makes some kind of sense. :) If not, I can implement something like the above solution in NVDA, but it'd make more sense for it to be implemented in Gecko if others agree with the idea.

Comment 1

[alexander :surkov (:asurkov)]

HTML table cells are interactive/selectable actually since ctrl+mouse click selects the cell. Perhaps that's not interactivity needed by AT.

We could go with your focusable test as you suggested or do that for ARIA grids only.

Comment 2

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #1)
> HTML table cells are interactive/selectable actually since ctrl+mouse click
> selects the cell. Perhaps that's not interactivity needed by AT.
Tricky. Can this be done for any other type of element? Does selection mean anything in this case other than text selection? Does it look visually different to just selecting all the text in the cell manually?

> We could go with your focusable test as you suggested or do that for ARIA
> grids only.
My concern with the latter idea is that there's probably no reason an author can't make a normal table interactive in terms of focus, rather than using an ARIA grid.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #2)
> (In reply to alexander :surkov from comment #1)
> > HTML table cells are interactive/selectable actually since ctrl+mouse click
> > selects the cell. Perhaps that's not interactivity needed by AT.
> Tricky. Can this be done for any other type of element?

afaik no

> Does selection mean
> anything in this case other than text selection? Does it look visually
> different to just selecting all the text in the cell manually?

yes, it's blue border inside the cell.

> > We could go with your focusable test as you suggested or do that for ARIA
> > grids only.
> My concern with the latter idea is that there's probably no reason an author
> can't make a normal table interactive in terms of focus, rather than using
> an ARIA grid.

I thought interactive table is a grid. Anyway, I'm fine with focus test.

Comment 4

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #3)
> > Does selection mean
> > anything in this case other than text selection? Does it look visually
> > different to just selecting all the text in the cell manually?
> yes, it's blue border inside the cell.
Do you have any idea what this actually means in practice?

> > > We could go with your focusable test as you suggested or do that for ARIA
> > > grids only.
> > My concern with the latter idea is that there's probably no reason an author
> > can't make a normal table interactive in terms of focus, rather than using
> > an ARIA grid.
> I thought interactive table is a grid.
I guess I figure an interactive grid is anything which has focusable row/cells, whether that be an HTML table or other elements with ARIA roles applied to make a grid. Note that this request also applies in XUL tree tables, such as the message list in Thunderbird.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #4)
> (In reply to alexander :surkov from comment #3)
> > > Does selection mean
> > > anything in this case other than text selection? Does it look visually
> > > different to just selecting all the text in the cell manually?
> > yes, it's blue border inside the cell.
> Do you have any idea what this actually means in practice?

I think to copy to clipboard a cells data.

> > I thought interactive table is a grid.
> I guess I figure an interactive grid is anything which has focusable
> row/cells, whether that be an HTML table or other elements with ARIA roles
> applied to make a grid.

it makes sense

> Note that this request also applies in XUL tree
> tables, such as the message list in Thunderbird.

So should XUL tree cells be selectable? Or should it depend whether XUL tree can be selected by rows only or by cells?

Comment 6

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #5)
> So should XUL tree cells be selectable? Or should it depend whether XUL tree
> can be selected by rows only or by cells?
My apologies. The current behaviour should remain for XUL tree tables; i.e. selectable should be exposed because they are interactive. We just need to be sure that any patch doesn't unintentionally regress these.