Marco Zehe (:MarcoZ) Reporter
	Description • 13 years ago

The abbr attribute on html:th elements is, like the summary attribute on html:table elements, hidden meta data for screen readers to provide users with shorter header cell information than what is written on the screen. A use case brought to my attention is a hierarchical table used in an Intranet app by a government agency where these header cell contents can be several paragraphs long.

Articles on the subject include:

http://www.ferg.org/section508/accessible_tables.html#contents_item_5.3
This contains tables similar to the ones in play where the request for this new feature came from.

http://www.usability.com.au/resources/tables.cfm#abbreviation
This article actually describes the abbr attribute, albait vaguely.

http://www.jimthatcher.com/webcourse9.htm#wc9.3
gives some very useful pointers on how to use the headers attribute and also is on the subject.

My suggestion:
1. If the abbr attribute is present, use it as the primary source for the name (after ARIA has been gone through). At the same time, turn the on-screen text (or inner text of the th element) into the accDescription, so users can still get to it if they need it.
2. if the abbr attribute is not present, do as we're doing now.

Thoughts?

	Marco Zehe (:MarcoZ) Reporter
	Comment 1 • 13 years ago

In HTML5, the abbr attribute is no longer specified:
http://www.w3.org/TR/2011/WD-html5-20110525/tabular-data.html#attributes-common-to-td-and-th-elements

Should we then even consider implementing this or WONTFIX the bug?

	alexander :surkov (:asurkov)
	Comment 2 • 13 years ago

(In reply to comment #1)

> Should we then even consider implementing this or WONTFIX the bug?

sounds so, it was removed intentionally, see http://www.w3.org/TR/html5-diff/#absent-attributes.

Also http://www.w3.org/TR/html5/obsolete.html#non-conforming-features states:

abbr on td and th elements
    Use text that begins in an unambiguous and terse manner, and include any more elaborate text after that. The title attribute can also be useful in including more detailed text, so that the cell's contents can be made terse.

	alexander :surkov (:asurkov)
	Comment 3 • 13 years ago

On the another hand maybe it's not good idea to make the web less accessible intentionally even if it's web page author uses something deprecated (maybe not validated document is enough on this way). Is there any best practice how to proceed similar cases? Victor, any thoughts?

Reopen bug for now.

	James Teh [:Jamie]
	Comment 4 • 10 years ago

Related NVDA issue ticket: http://community.nvda-project.org/ticket/3566

Current HTML 5 spec seems to have reinstated abbr on th elements. See references above.

I agree with Marco's implementation suggestion.

	Marco Zehe (:MarcoZ) Reporter
	Comment 5 • 10 years ago

David, Alex, can we get this implemented in a timely manner?

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 6 • 10 years ago

but it has only been 3 years :)

This is fine with me if it improves usability overall.

	alexander :surkov (:asurkov)
	Comment 7 • 10 years ago

I bet we expose it as object attribute, see bug 704754. If abbr doesn't need to be handled special way then name/description sounds reasonable but that's something that should be discussed with HTML a11y group (Marco, wanna file email?)

Note, there's abbr element for same proposes.

	Marco Zehe (:MarcoZ) Reporter
	Comment 8 • 9 years ago

Is there any current status on this, whether this attribute is in HTML5, 5.1 or whatever the next version is called, or how to proceed here? I have absolutely no idea.

	Joe Dolson
	Comment 9 • 9 years ago

We're looking at implementing this in the WordPress admin, and it would be much preferable (obviously) it it offered support in Firefox/NVDA. 

For reference: http://www.w3.org/TR/html51/semantics.html#attr-th-abbr

	Marco Zehe (:MarcoZ) Reporter
	Comment 10 • 6 years ago

That link no longer brings up any useful info. Joe, is this even still a topic for WordPress nowadays?

	Joe Dolson
	Comment 11 • 6 years ago

Well, I could certainly wish I'd referenced the relevant tickets in WordPress trac in my previous comment. However, having done some research to try and remember what this was about, I can say that I believe the relevant issue is still present, but it's unlikely that using the abbr attribute is a path we'd choose to take on it at this time, since we generally feel that exposing information only via attributes is mostly inadequate for a well-rounded accessible experience. 

If it was supported, we'd possibly consider it, but it's not a priority.

	Marco Zehe (:MarcoZ) Reporter
	Comment 12 • 6 years ago

Thanks, Joe! Jamie, do we re-WONTFIX this one?

	James Teh [:Jamie]
	Comment 13 • 6 years ago

I assume that was an unintentional close as "fixed". :)

TL;DR: Yes, I think we should won't fix this.

While (in comment 4) I originally agreed with the suggestion of exposing abbr as the name for the header, with further research and thought, I don't agree any more. It seems that the purpose of the abbr attribute is to be read only when reading as a header while navigating other cells, not when reading the header itself. Exposing the abbr as the name suggests it is "primary" content, which would suggest it should be read as primary content when reading the header itself. That contradicts the intent of the spec. Other implementations (JAWS DOM, VoiceOver on mac) seem to agree with this. Also, this was discussed already in HTML-AAM and it was agreed not to include this in name/description computation:
https://github.com/w3c/html-aam/issues/16

We already expose this as the abbr object attribute, which, while a bit obscure, satisfies the requirements here.