HTML-AAM: @abbr should be part of name calculation

[cyns]

abbr should replace (or maybe add to?) the inner text of the element, and participate in name calculation.

[jasonkiss]

Interestingly, HTML5.1 defines the abbr attribute as an "alternative label for the header cell" and that it is "typically an abbreviated form of the full header cell, but can also be an expansion, or merely a different phrasing." My experience is the opposite: it's typically an expansion. Either way, it's an interesting question.

In my view, adding the value of the abbr attribute to the header element's contents as accessible name will lead to unnecessary verbosity. And if the abbr can be either an expansion, or an abbreviation, or just some alternative phrasing, how do we decide when or how it should participate in the name calculation? (This is where Steve chimes in with his grep about how abbr is used in the wild ;)

Is it something to leave to ATs, or an AT user preference? What about accessible description? For instance, when browsing an actual header cell whose abbr is an expansion, it might be useful to get that expansion as an accessible description, but when navigating table cells, it might be nicer to just get the shorter header cell's contents.

[jnurthen]

I can tell you how we use it.

When we have sort controls within a table header then we use abbr to provide a version of the table header without the extraneous sorting control information to be used as the table header when reading cells in the table.

For example

Last Name sort ascendingsort desceding

Regards,
James.

On Mar 15, 2016, at 20:30, Jason Kiss notifications@github.com wrote:

Interestingly, HTML5.1 defines the abbr attribute as an "alternative label for the header cell" and that it is "typically an abbreviated form of the full header cell, but can also be an expansion, or merely a different phrasing." My experience is the opposite: it's typically an expansion. Either way, it's an interesting question.

In my view, adding the value of the abbr attribute to the header element's contents as accessible name will lead to unnecessary verbosity. And if the abbr can be either an expansion, or an abbreviation, or just some alternative phrasing, how do we decide when or how it should participate in the name calculation? (This is where Steve chimes in with his grep about how abbr is used in the wild ;)

Is it something to leave to ATs, or an AT user preference? What about accessible description? For instance, when browsing an actual header cell whose abbr is an expansion, it might be useful to get that expansion as an accessible description, but when navigating table cells, it might be nicer to just get the shorter header cell's contents.

―
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[jasonkiss]

Thanks @jnurthen. Looks like VO is using the abbr value when navigating cells, although I can't see how that's mapped using Accessibility Inspector. FF exposes the abbr as object attributes on the header cell. NVDA doesn't seem to read the abbr in FF, but JAWS does in IE and FF when navigating table data cells, but not when reading the actual header cell itself. Seems that preference then is to have abbr replace the header cell contents when navigating cells, but not when calculating name of the header cell itself?

[jasonkiss]

This issue was moved to w3c/html-aam#16