Closed Bug 995888 Opened 10 years ago Closed 1 year ago

When a table's caption is positioned absolutely, Firefox counts it as an extra row

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox113 --- fixed
firefox114 --- fixed
firefox115 --- fixed

People

(Reporter: hans.hillen, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: papercut)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce:

When a table has a caption element that is styled with position:absolute, NVDA will treat it as a row when calculating the total number of rows in the table. A common use case for using absolute positioning is when the caption should be hidden visually but not from assistive technology.

I have attached a ​test case that illustrates this. The page contains two tables with identical content, except that in the second table the caption text is hidden off screen using CSS. When pressing the T key twice, NVDA will correctly announce 4 rows for the first table and incorrectly 5 rows for the second table.

Originally this bug was filed with NVDA (http://community.nvda-project.org/ticket/3813), but they mentioned that it's actually Firefox exposing the tables as having 5 rows. They also suggested that Firefox probably has some logic that normally excludes the caption from the row count, and that this logic breaks when the caption is absolutely positioned. Looking in DOM Inspector I can see that the the absolutely positioned caption is not exposed as an accessible object, while the first one is. This seems to be the cause of this issue. 



Expected results:

The caption should be exposes as an accessible object regardless of how it's positioned, an the correct rowcount should be exposed
Component: Untriaged → Disability Access
Keywords: access
OS: Mac OS X → Windows 7
Blocks: tablea11y
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
Confirmed also in 31 nightly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
Version: 28 Branch → Trunk
HTML caption doesn't get an accessible object. I think bug is similar to bug 996821. Anybody is willing to take it?
Note that when a caption is absolutely positioned it stops being a caption from the point of view of CSS.  Specifically, it is no longer display:table-caption; it's just a block child of the table, and it (or rather its placeholder) does in fact get an anonymous table cell and table row wrapping it.

So it's not quite clear to me what the right way to expose such a "caption" is, exactly...  

Also, what should happen for non-absolutely-positioned captions that have been styled with a display value other than table-caption?
I filed bug #1201795, which is related to this issue, but has the more frustrating side effect of preventing NVDA from being able to continue past the header with row nav. This then forces the user to navigate to a further row before being able to resume using row nav.
These are probably closely related, so NI'ing Surkov here as well.
Flags: needinfo?(surkov.alexander)
we could expose caption accessible but table interface would be 'broken' anyway per Boris's comment.
Flags: needinfo?(surkov.alexander)
This is being tracked by NVDA as well: https://github.com/nvaccess/nvda/issues/3813
There are pings on that issue from time to time.

No movement on this issue? It's a pretty serious one IMO...

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Bugbug is usually right, but in this case, it's wrong. :)

Keywords: regression

Just wanted to add a +1 that we are also running into this issue :/

Is there any chance this can get some work? It seems to be a straight forward bug; <caption> is valid markup and it seems that it's positioning or display characteristics would seem to not be relevant.

(In reply to bossley.5 from comment #13)

It seems to be a straight forward bug

Not straightforward unfortunately. For HTML tables, the a11y engine currently uses layout to calculate coordinates. Since an absolutely positioned caption is not a caption from the perspective of CSS (see comment 3), layout and a11y have different needs here. The solution here is to have a11y handle tables independently and avoid relying on layout at all, which would also fix a bunch of other bugs. The challenge is that this is a pretty massive rewrite of the a11y table code which we're having trouble resourcing at the moment given other priorities.

Severity: normal → S3
Keywords: accesspapercut
Depends on: 1686391

This is resolved by Cache the World, which is enabled by default in Firefox 113.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: