Last Comment Bug 834120 - Table cell accessibles not exposed for CSS table without table-row
: Table cell accessibles not exposed for CSS table without table-row
Status: VERIFIED FIXED
: regression
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: mozilla21
Assigned To: alexander :surkov
:
Mentors:
Depends on:
Blocks: treea11y 804461
  Show dependency treegraph
 
Reported: 2013-01-23 19:57 PST by James Teh [:Jamie]
Modified: 2013-07-12 00:53 PDT (History)
4 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed


Attachments
Test case. (234 bytes, text/html)
2013-01-23 19:57 PST, James Teh [:Jamie]
no flags Details
patch (6.00 KB, patch)
2013-02-14 18:10 PST, alexander :surkov
tbsaunde+mozbugs: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description James Teh [:Jamie] 2013-01-23 19:57:35 PST
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.
Comment 1 alexander :surkov 2013-01-23 23:31:18 PST
(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] 2013-01-24 01:07:26 PST
(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] 2013-01-24 17:58:47 PST
(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] 2013-02-06 19:05:55 PST
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] 2013-02-06 19:12:57 PST
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 2013-02-07 00:38:58 PST
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] 2013-02-07 17:47:23 PST
(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 2013-02-14 18:10:18 PST
Created attachment 714222 [details] [diff] [review]
patch
Comment 9 Trevor Saunders (:tbsaunde) 2013-02-15 01:15:58 PST
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 2013-02-15 21:41:05 PST
(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] 2013-02-16 06:57:33 PST
https://hg.mozilla.org/mozilla-central/rev/0246938e17e3
Comment 12 alexander :surkov 2013-02-16 19:33:48 PST
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] 2013-02-19 02:38:42 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/1a977d7f1004
Comment 14 Mihai Morar, (:MihaiMorar) 2013-05-22 04:34:12 PDT
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 2013-05-22 05:45:27 PDT
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) 2013-05-22 05:52:29 PDT
 (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 2013-05-22 06:47:10 PDT
(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) 2013-05-22 06:49:19 PDT
(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) 2013-07-12 00:53:32 PDT
Verified Fixed on FF 23b3.

Note You need to log in before you can comment on or make changes to this bug.