1007975 - div with display:table exposes table semantics

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Nurthen]

Attachment: tablecells.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36

Steps to reproduce:

Run the attached testcase which is from a tab renderer in a product. 


Actual results:

Note that the Accessibility APIs expose this as a table, despite the fact that there is no table present and this gets communicated via JAWS saying row1, column 1 when you tab to the first tab page.


Expected results:

There is no table here so this should not be communicated as a table. I tried adding role="presentation" (which I shouldn't have to as this is a DIV not a table) but this did not resolve the issue.

Comment 1

[Marco Zehe (:MarcoZ)]

Opposite of bug 1005271, same reason I guess. Layout deduces this as a table and tells accessibility so.

Comment 2

[steve faulkner]

I took a quick look at some pages from http://www.webdevdata.org searching for display:table. From a limited search I could find no examples of use of display:table for styling tabular data. Admittedly I only looked at about a dozen pages.

Comment 3

[alexander :surkov (:asurkov)]

this one is rather wontfix because the behavior is intentional, we expose this kind of tables as layout tables.

Comment 4

[Julien Wajsberg [:julienw]]

Alexander, maybe that means the intentional behavior needs to be changed?

Comment 5

[Ilya]

IMO, this behavior definitely needs to be changed. The almost only use of CSS table properties for non-table elements is to place some logically independent blocks next to each other, visually. The same visual placement of the blocks can often be achieved with different styles (flexboxes/floats/inline-blocks etc.). And when the same logical markup results in the same visual structure on the screen, it shouldn't expose different semantics just because of the implementation details.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to Julien Wajsberg [:julienw] from comment #4)
> Alexander, maybe that means the intentional behavior needs to be changed?

sure as long as it's reasonable

(In reply to Ilya from comment #5)
> IMO, this behavior definitely needs to be changed. The almost only use of
> CSS table properties for non-table elements is to place some logically
> independent blocks next to each other, visually.

right, also people use HTML tables to achieve the same. Firefox exposes these tables as layout tables, we do the same for display:table stuff.

> The same visual placement
> of the blocks can often be achieved with different styles
> (flexboxes/floats/inline-blocks etc.). 

true, the web author has many ways to make certain appearance, but we cannot handle each case properly and probably don't need to

> And when the same logical markup
> results in the same visual structure on the screen, it shouldn't expose
> different semantics just because of the implementation details.

I wouldn't say that something exposed as accessibility table has table semantics (data table)

Comment 7

[alexander :surkov (:asurkov)]

I'd love to hear Jamie's thinking (cc'ing)

Comment 8

[James Teh [:Jamie]]

Just in case anyone isn't already aware, Firefox does expose data tables and layout tables differently. Layout tables get an object attribute of layout-guess:true.

There are two questions that need to be addressed here:
1. Firefox does distinguish between layout and data tables. It could be argued that screen readers should respect this. (NVDA does, for example.) The problem is that layout-guess:true is not a standard object attribute. It's documented, but it's Mozilla specific.
2. Should CSS tables be any different to HTML layout tables? In both cases, Firefox exposes them as layout tables. The reason for exposing layout tables is that the user *may* care about this if there is poor authoring and a data table actually became a layout table. It could be argued that this doesn't apply to CSS tables and that no one would ever be silly enough to use a CSS table for a data table, since a CSS table is clearly for layout.

Comment 9

[alexander :surkov (:asurkov)]

concerning to original report I've been told that JAWS has an option to ignore layout tables which should be turned on by default.

I'm curious if AT need a table interface ever for non data tables?

Comment 10

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #9)
> concerning to original report I've been told that JAWS has an option to
> ignore layout tables which should be turned on by default.
I suspect they use their own algorithm rather than using Firefox's layaout-guess attribute.

> I'm curious if AT need a table interface ever for non data tables?
Sometimes, either due to author error or guessing error, a data table gets reported by Firefox as a layout table. In this case, the user might tell the AT to treat layout tables as data tables, which requires the table interface. However, as I noted above, it could be argued that this should never happen for CSS tables because CSS tables are *always* layout; i.e. there is no guessing involved.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #10)
> (In reply to alexander :surkov from comment #9)
> > concerning to original report I've been told that JAWS has an option to
> > ignore layout tables which should be turned on by default.
> I suspect they use their own algorithm rather than using Firefox's
> layaout-guess attribute.

good point

> > I'm curious if AT need a table interface ever for non data tables?
> Sometimes, either due to author error or guessing error, a data table gets
> reported by Firefox as a layout table. In this case, the user might tell the
> AT to treat layout tables as data tables, which requires the table
> interface. However, as I noted above, it could be argued that this should
> never happen for CSS tables because CSS tables are *always* layout; i.e.
> there is no guessing involved.

agree, refining my question, can you think of any example where you need table interface for pure layout table (zero chance of data table)? after all the layout table has rows, columns, cells and AT may want to navigate them corresponding to table structure rather than tree hierarchy.

Comment 12

[Ilya]

(In reply to alexander :surkov from comment #6)
> (In reply to Ilya from comment #5)
> 
> right, also people use HTML tables to achieve the same. Firefox exposes
> these tables as layout tables, we do the same for display:table stuff.
> 

Using HTML table for layout and creating the table-like layout with CSS table-* properties are different things from the author's perspective. When the author uses HTML table for layout, she either doesn't think of the consequences (due to lack of experience etc.) or considers them acceptable for some reason (e.g. for compatibility with pre-CSS2 UAs). CSS tables, on the contrary, are used usually along with semantic markup and aren't meant to affect anything except visual presentation.

Both W3C HTML5.0 and WHATWG HTML Living Standard specs clearly state that CSS tables are *alternative* to layout tables, not a sort of them (http://www.w3.org/TR/html5/tabular-data.html#the-table-element, http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-table-element). Authors don't expect the HTML code that follows the good practices to 'confuse the ATs' the same way that 'bad' legacy HTML code.

(In reply to alexander :surkov from comment #11)
> after all
> the layout table has rows, columns, cells and AT may want to navigate them
> corresponding to table structure rather than tree hierarchy.

Is there really a big difference? Unlike HTML tables, CSS tables have no colspans or rowspans, and the order of cells always corresponds their tree order (respecting the `direction` property). I guess that the most popular use case for CSS tables is 1-row horisontal list, and even in multi-row layouts rarely there is any logical connection between vertically neighbour cells. Also, some layouts may have CSS tables with only one cell (e.g. to create a separate block formatting context), and to annotate these as tables seems to be not reasonable at all.

Comment 13

[Dylan Barrell]

It would appear to me that this code is legacy code that should probably be changed to reflect the fact that

1) Nobody really creates CSS tables but many people mis-use HTML tables for layout, and
2) We have all moved on to acknowledge that semantic HTML is the right way to do things

I propose that we simply modify the algorithm to not factor the existence or non-existence of the display:table property at all in determining whether something is to be considered a table.

This will at least solve the problem that the current algorithm creates when trying to do responsive data tables.

Comment 14

[alexander :surkov (:asurkov)]

Some summary

1) there's no evidence that people use CSS tables for data
2) there's no evidence that AT needs an access to table interface for 100% non data tables
3) layout-guess is not standard attribute and not used by all ATs what reveals original bug problem 
4) no other browsers creates table accessible for other CSS tables

If all items above are true then I'd say to not expose table interface for CSS tables. Any objections?

Comment 15

[alexander :surkov (:asurkov)]

(In reply to James Nurthen from comment #0)

> There is no table here so this should not be communicated as a table. I
> tried adding role="presentation" (which I shouldn't have to as this is a DIV
> not a table) but this did not resolve the issue.

btw <div style="display:table" role="presentation"> doesn't create table accessible for me

Comment 16

[Dylan Barrell]

(In reply to alexander :surkov from comment #14)
> Some summary
> 
> 1) there's no evidence that people use CSS tables for data
> 2) there's no evidence that AT needs an access to table interface for 100%
> non data tables
> 3) layout-guess is not standard attribute and not used by all ATs what
> reveals original bug problem 
> 4) no other browsers creates table accessible for other CSS tables
> 
> If all items above are true then I'd say to not expose table interface for
> CSS tables. Any objections?

If this also means not excluding <table> elements that do not have display:table then I am totally in favor of this

Comment 17

[alexander :surkov (:asurkov)]

(In reply to Dylan Barrell from comment #16)
> > If all items above are true then I'd say to not expose table interface for
> > CSS tables. Any objections?
> 
> If this also means not excluding <table> elements that do not have
> display:table then I am totally in favor of this

I'd say it's different issue, we have bug 1005271 on this

Comment 18

[Ilya]

(In reply to alexander :surkov from comment #14)
> If all items above are true then I'd say to not expose table interface for
> CSS tables. Any objections?

It looks that there are no objections. Why is this bug still open?

Comment 19

[alexander :surkov (:asurkov)]

(In reply to Ilya from comment #18)
> (In reply to alexander :surkov from comment #14)
> > If all items above are true then I'd say to not expose table interface for
> > CSS tables. Any objections?
> 
> It looks that there are no objections. Why is this bug still open?

I think it needs assignee.

Comment 21

[Takeshi Kurosawa :takenspc]

Attachment: MozReview Request: Bug 1007975 div with display:table exposes table semantics r?surkov

Bug 1007975 div with display:table exposes table semantics r?surkov

- Construct a table accessible object if a content in question is HTML <table>
- Drop checking whether a table accessible object is built by CSS display:table from HTMLTableAccessbile::IsProbablyLayoutTable

Comment 22

[alexander :surkov (:asurkov)]

Comment on attachment 8675655 [details]
MozReview Request: Bug 1007975 div with display:table exposes table semantics r?surkov

https://reviewboard.mozilla.org/r/22411/#review20007

it works, it allows weird combos like <table><div style="display:row"><div style="display:cell"></div></div> though, but it shouldn't be big deal and can be fixed later.

Comment 23

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2e52638cab7c

Comment 24

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2e52638cab7c