Open Bug 548469 Opened 14 years ago Updated 2 years ago

Checkable table cells should not expose accessible name

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

People

(Reporter: Jamie, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100224 Minefield/3.7a2pre
Build Identifier: 

Checkable table cells currently expose an accessible name of "true" when they are checked and "false" when they are not. This is in addition to the checked/checkable state. This is redundant and confusing.

However, removing the cell's name will mean that the row's name will not include information about whether the row is checked or not. There are two possible solutions:
1. When calculating the name for the row, if a checkable cell is encountered, add "on" for checked or "off" for unchecked. Note the use of on/off here instead of true/false; I think this is more user-friendly.
2. For rows which only have one checkbox, make the row itself checkable and expose the checked/checkable states on the row. I think this is the better option, but would require a change to the UI.

See the tree in the "Restore from last session" dialog for an example of the checkable table cells in question.

Reproducible: Always

Actual Results:  
`
Keywords: access
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #0)
> 1. When calculating the name for the row, if a checkable cell is encountered,
> add "on" for checked or "off" for unchecked. Note the use of on/off here
> instead of true/false; I think this is more user-friendly.

This would mean a localizable string. I wonder if there are ever use cases where a row contains more than one checkable cell or if we should assume that option 2 covers 99.9% of all cases.
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
Blocks: tablea11y
(In reply to comment #1)

> This would mean a localizable string.

So it might worth to expose true/false as we do now.
However we could request localization community to localize them. Should we expose "header cell name" off/on? I started to find this idea appeal.
Attached patch wipSplinter Review
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: