TD with SCOPE passes test, but is obsolete in HTML 5

[awkawk]

Item Number: F91
Part of Item: Tests
Comment Type: technical
Summary of Issue: TD with SCOPE passes test, but is obsolete in HTML 5
Comment (Including rationale for any proposed change):
HTML 5 obsoleted TD SCOPE attribute, and says use TH SCOPE instead:
http://www.w3.org/TR/html-markup/td.html

Some common AT ignores scope, so treat this as a plain TD:
http://www.powermapper.com/tests/screen-readers/tables/table-th-scope/

Using TD SCOPE in HTML 5 triggers the following error in the W3 validator
The scope attribute on the td element is obsolete. Use the scope attribute on a th element instead.

Proposed Change:
Remove
5. headers marked up as td elements with the scope attribute

[DavidMacDonald]

Perhaps we should revisit the whole issue using scope at all in any techniques ... I've almost never seen it add value in modern browsers and AT.

Seems AT has figured out what to do with to figure out the scope themselves.

[dd8]

scope works in JAWS 13 thru 16 and Window-Eyes 9+, but not in NVDA or VoiceOver:
http://www.powermapper.com/tests/screen-readers/tables/table-th-scope/

JAWS 15 onwards can repair the H63 example when scope is missing, but other screen readers can't:
http://www.powermapper.com/tests/screen-readers/tables/table-th-no-scope/

The TD headers attribute is marginally better supported, but much harder to code correctly:
http://www.powermapper.com/tests/screen-readers/tables/table-td-headers/

Would lobbying two AT vendors to support scope be easier than changing the table markup used on millions of pages? Both NVDA and VoiceOver auto update so interop with old versions is much less of a concern.

[jcsteh]

scope works in JAWS 13 thru 16 and Window-Eyes 9+, but not in NVDA

That's not entirely correct. Here's the situation for NVDA.

For IE/MSHTML, we scour the DOM like every other AT, so we have to implement scope ourselves. The way it is currently implemented, a scope="row" header is associated correctly for cells after the row header (i.e. column 3 and after), but not before. So, if you move to column 3 and then move down by row, you'll notice the row headers do get read correctly. Also, note that we currently only implement scope for th, not td.

For Firefox/Mozilla, we use accessibility APIs, which means Firefox is responsible for giving us table info (including headers). It seems they've made the same assumption; i.e. a scope="row" header is associated for cells after the header, but not before.

For Chrome/Chromium/Edge, we also use accessibility APIs, but I don't know what they implement and what they don't regarding header scope.

Regarding the association of scope="row" headers before the cursor, we definitely never want to associate a row header with itself; i.e. row 2 column 2 shouldn't have row 2 column 2 as a row header. There's probably a good argument for associating it for cells before (column 1 in this example), though.

[awkawk]

Thanks @jcsteh for the information. In your view are there cases where if a plain TH is provided that the headings are not correctly identified and having scope assigned makes the difference? I'm not sure whether the browser does the guessing for what cell is the header for the data cells or if NVDA does some work to try to figure it out.

[joshueoconnor]

This failure is still useful for legacy websites/applications. We could update the failures test procedure to state:

• [For < HTML5 codebase] headers marked up as td elements with the scope attribute

The rest of the procedure would still be fine. Would that do it?

[dd8]

Hi Joshue

I’ve been looking at how the NVDA / Firefox / WebKit / Blink accessibility API layers calculate table headers, and how SCOPE affects this. I’m hoping to write up the behaviour this weekend and post it to the GitHub issue.

There’s not much agreement on the table header calculation between implementations, so that’s probably going to have a bearing on resolving this.

Is it possible to hold off deciding this till I’ve written up the behaviour?

Cheers
Mark

Mark Rogers - mark.rogers@powermapper.com
PowerMapper Software Ltd - www.powermapper.com
Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL

From: joshueoconnor [mailto:notifications@github.com]
Sent: 05 February 2016 14:01
To: w3c/wcag
Cc: Mark Rogers
Subject: Re: [wcag] TD with SCOPE passes test, but is obsolete in HTML 5 (#127)

This failure is still useful for legacy websites/applications. We could update the failures test procedure to state:

• [For < HTML5 codebase] headers marked up as td elements with the scope attribute

The rest of the procedure would still be fine. Would that do it?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/127#issuecomment-180371241.

[joshueoconnor]

@dd8 No problem Mark - that's great. I look forward to hearing your feedback.

[dd8]

I've done a fair bit of investigation of the code supporting SCOPE and table cell header calculations. It turns out to be quite complex, with limited interop between implementations (partly as a result of a spec issue - see below).

http://www.powermapper.com/blog/table-headers-and-scope/

• Most accessibility APIs expose a pair of properties for cell headers: RowHeaders and ColumnHeaders (that lets screen readers provide separate commands for speak row header and speak column header)
• Without SCOPE the accessibility layer uses heuristics to guess whether a TH is a row header or column header. These vary a lot between implementations and usually only produce the same results when headers are in first row or first column (even then the cell at position 1,1 can be problematic)
• TH SCOPE is much better supported than TD SCOPE
• There seems to be a spec issue in both the HTML 4 and 5 recommendations: both have algorithms that produce a single list of headers for a cell, instead of the RowHeaders and ColumnHeaders lists exposed by accessibility APIs
• The same issue affects the TD HEADERS attribute: the accessibility APIs need to know how to assign referenced headers to the RowHeaders and ColumnHeaders properties, but the attribute doesn't provide these semantics (e.g. Safari just assigns all TD HEADERS cells to the ColumnHeaders property, whereas NVDA uses complex heuristics to assign cells listed in HEADERS to RowHeaders or ColumnHeaders)
• Arguably the cells in the first column in H63, Example 1 fail SC 4.1.2 since they don't have any headers as defined by the HTML 4/5 header calculation algorithms (i.e. they have value and role, but no name)

I only looked at implementations with public source code, so not JAWS or WindowEyes.

PS @jcsteh - I've tried to document the NVDA with MSAA behaviour as simply as possible, but please correct me if I got anything wrong.

[awkawk]

Mark, this is a huge help. I'll have to digest it more but it is great to have the data to work off of. Thanks!

[awkawk]

Preparing to mark as deferred due to inactivity and group resource constraints (https://www.w3.org/WAI/GL/wiki/Handling_Issues).