Table cell accessibles not exposed for CSS table without table-row

VERIFIED FIXED in Firefox 20

Status

()

Core
Disability Access APIs
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla21
x86_64
Windows 7
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox20 fixed, firefox21 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 705710 [details]
Test case.

Str:
1. Open the attached test case.
2. Examine the accessibility hierarchy.
Expected: There should be table cell accessibles for "c1" and "c2".
Actual: There are no table cell accessibles.

I realise table-row is missing here, but this shouldn't cause the table cell accessibles to disappear.

This works as expected in Firefox 18, but does not work in 21pre. I'm not sure about 19 or 20 yet.

This is causing NVDA to break in some cases.
(Assignee)

Comment 1

5 years ago
(In reply to James Teh [:Jamie] from comment #0)

> This is causing NVDA to break in some cases.

can you give details please? I think the change was intentional: we reject to create cells if the row was missed.
(Assignee)

Updated

5 years ago
Blocks: 540399
(Reporter)

Comment 2

5 years ago
(In reply to alexander :surkov from comment #1)
> > This is causing NVDA to break in some cases.
> can you give details please?
Sorry. I didn't explain this initially because it's pretty complicated to explain. :)

The problem is that NVDA (rightly or wrongly) assumes that a table will always contain table cells. Therefore, as an optimisation, it doesn't bother to check for a new table interface when processing table descendants unless a table cell is encountered. This means that if you have a real table inside one of these CSS tables without rows, NVDA's representation of the inner table breaks.

> I think the change was intentional: we reject
> to create cells if the row was missed.
Fair enough. However, it probably doesn't make sense to expose the table interface at all if there are no table cells.

I can fix this in NVDA, but this does seem a bit counter-intuitive.
(Reporter)

Comment 3

5 years ago
(In reply to alexander :surkov from comment #1)
> I think the change was intentional: we reject
> to create cells if the row was missed.
Out of curiosity, why? The rows aren't particularly important; you can access all the info you need with just table and cell accessibles. You just assume 1 row if there's no row accessible (which Gecko already seems to do).
(Reporter)

Comment 4

5 years ago
Any further thoughts on this? I do believe one of two fixes is needed here, but if it's going to be wontfix, I'll need to work around it in NVDA.
(Reporter)

Comment 5

5 years ago
This actually causes another issue as well. Because there are no table cell accessibles and tables don't expose IAccessibleText, the text is only accessible via the text leaf nodes. NVDA handles this, but it's not an ideal situation; text attributes are lost, etc.
(Assignee)

Comment 6

5 years ago
Sorry for being slow on this.

(In reply to James Teh [:Jamie] from comment #2)
> (In reply to alexander :surkov from comment #1)
> 
> The problem is that NVDA (rightly or wrongly) assumes that a table will
> always contain table cells.

what about empty tables like
<table><caption>It's empty table but it will have rows one day</caption</table>

> Therefore, as an optimisation, it doesn't bother
> to check for a new table interface when processing table descendants unless
> a table cell is encountered. This means that if you have a real table inside
> one of these CSS tables without rows, NVDA's representation of the inner
> table breaks.

is it something like

<div style="display:table;">
  <div style="display:cell;">
    <table><tr><td>a real table cell</td></tr></table>
  </div>
</div>

(In reply to James Teh [:Jamie] from comment #3)
> (In reply to alexander :surkov from comment #1)
> > I think the change was intentional: we reject
> > to create cells if the row was missed.
> Out of curiosity, why? The rows aren't particularly important; you can
> access all the info you need with just table and cell accessibles. You just
> assume 1 row if there's no row accessible (which Gecko already seems to do).

I would depend on what gecko thinks about these tables, i.e. does it behave as table or not. I tried

<div style="width: 100%; border: 1px solid red; display:table;">
  <div style="display:table-cell;">cell1</div>
  <div style="display:table-cell;">cell2</div>
</div>

<div style="width: 100%; border: 1px solid blue; display:table;">
  <div style="display:table-row;">
    <div style="display:table-cell;">cell1</div>
    <div style="display:table-cell;">cell2</div>
  </div>
</div>

and they look the same so it seems gecko recognize cells only table as normal table.

(In reply to James Teh [:Jamie] from comment #5)
> This actually causes another issue as well. Because there are no table cell
> accessibles and tables don't expose IAccessibleText, the text is only
> accessible via the text leaf nodes. NVDA handles this, but it's not an ideal
> situation; text attributes are lost, etc.

this problem might be different, you should get the same situation for
<div style="display:table">hello, I'm inaccessible text</div>
(Reporter)

Comment 7

5 years ago
(In reply to alexander :surkov from comment #6)
> > The problem is that NVDA (rightly or wrongly) assumes that a table will
> > always contain table cells.
> what about empty tables like
> <table><caption>It's empty table but it will have rows one
> day</caption</table>
Sorry for the confusion. I mean that NVDA assumes that if there is a table inside a table, the inner table will be inside a table cell.

> > Therefore, as an optimisation, it doesn't bother
> > to check for a new table interface when processing table descendants unless
> > a table cell is encountered.
> <div style="display:table;">
>   <div style="display:cell;">
>     <table><tr><td>a real table cell</td></tr></table>
Correct.

> > > I think the change was intentional: we reject
> > > to create cells if the row was missed.
> I would depend on what gecko thinks about these tables, i.e. does it behave
> as table or not. I tried
> <div style="width: 100%; border: 1px solid red; display:table;">
>   <div style="display:table-cell;">cell1</div>
>   <div style="display:table-cell;">cell2</div>
> </div>
> so it seems gecko recognize cells only table as
> normal table.
Right, but Gecko accessibility doesn't. The code above doesn't generate cell accessibles.

> > This actually causes another issue as well. Because there are no table cell
> > accessibles and tables don't expose IAccessibleText, the text is only
> > accessible via the text leaf nodes.
> this problem might be different, you should get the same situation for
> <div style="display:table">hello, I'm inaccessible text</div>
Yes and I think there's a separate bug for this. However, this didn't happen before for CSS tables with cells but no rows because cells were previously exposed regardless.
(Assignee)

Comment 8

5 years ago
Created attachment 714222 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #714222 - Flags: review?(trev.saunders)
(Assignee)

Updated

5 years ago
Attachment #714222 - Attachment is patch: true
Comment on attachment 714222 [details] [diff] [review]
patch

>+      // Accessible HTML table cell should be a child of accessible HTML table
>+      // or its row (CSS HTML tables are polite to the used markup at
>+      // certain degree).

I'm not sure what your trying to say here.  Maybe something like "we allow css tables to not use table rows"?
Attachment #714222 - Flags: review?(trev.saunders) → review+
(Assignee)

Comment 10

5 years ago
(In reply to Trevor Saunders (:tbsaunde) from comment #9)
> >+      // Accessible HTML table cell should be a child of accessible HTML table
> >+      // or its row (CSS HTML tables are polite to the used markup at
> >+      // certain degree).
> 
> I'm not sure what your trying to say here.  Maybe something like "we allow
> css tables to not use table rows"?

accepted

http://hg.mozilla.org/integration/mozilla-inbound/rev/0246938e17e3
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/0246938e17e3
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
(Assignee)

Comment 12

5 years ago
Comment on attachment 714222 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 804461
User impact if declined: number of inaccessible web pages for NVDA users
Testing completed (on m-c, etc.): m-c, testsuite+
Risk to taking this patch (and alternatives if risky): no risk, rolling back to the behavior we had
String or UUID changes made by this patch: no
Attachment #714222 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

5 years ago
Blocks: 804461
Attachment #714222 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox20: --- → affected
status-firefox21: --- → fixed
https://hg.mozilla.org/releases/mozilla-aurora/rev/1a977d7f1004
status-firefox20: affected → fixed
Following STR from Comment 0 results that this issue is not fixed yet! No table cell is displayed for atributes "c1 and c2" mentioned in Comment 0.

Verification done on FF22b1 on Windows 7 x64

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0(20130514181517)
(Assignee)

Comment 15

4 years ago
In Firefox 22 I see hierarchy
table (DIV)
  cell (DIV)
    text leaf (c1)
  cell (DIV)
    text leaf (c2)

the bug is definitely fixed for me
 (In reply to alexander :surkov from comment #15)
> In Firefox 22 I see hierarchy
> table (DIV)
>   cell (DIV)
>     text leaf (c1)
>   cell (DIV)
>     text leaf (c2)
> 
> the bug is definitely fixed for me

I can see in Page Source table and cell implemented, but why they are not displayed?
(Assignee)

Comment 17

4 years ago
(In reply to MarioMi (:MarioMi) from comment #16)

> I can see in Page Source table and cell implemented, but why they are not
> displayed?

If you mean a look of cells on the screen then this is out of scope of this bug. This bug is about accessibility hierarchy.
(In reply to alexander :surkov from comment #17)
> If you mean a look of cells on the screen then this is out of scope of this
> bug. This bug is about accessibility hierarchy.

In this case I can confirm the fix is verified.
Verified Fixed on FF 23b3.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.