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

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Attachment: 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.

Comment 1

[alexander :surkov (:asurkov)]

(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.

Comment 2

[James Teh [:Jamie]]

(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.

Comment 3

[James Teh [:Jamie]]

(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).

Comment 4

[James Teh [:Jamie]]

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.

Comment 5

[James Teh [:Jamie]]

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.

Comment 6

[alexander :surkov (:asurkov)]

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>

Comment 7

[James Teh [:Jamie]]

(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.

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 9

[Trevor Saunders (:tbsaunde)]

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"?

Comment 10

[alexander :surkov (:asurkov)]

(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

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0246938e17e3

Comment 12

[alexander :surkov (:asurkov)]

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

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1a977d7f1004

Comment 14

[Mihai Morar, (:MihaiMorar)]

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)

Comment 15

[alexander :surkov (:asurkov)]

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

Comment 16

[Mihai Morar, (:MihaiMorar)]

 (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?

Comment 17

[alexander :surkov (:asurkov)]

(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.

Comment 18

[Mihai Morar, (:MihaiMorar)]

(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.

Comment 19

[Mihai Morar, (:MihaiMorar)]

Verified Fixed on FF 23b3.