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?

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?

(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.

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.

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.

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

but it has only been 3 years :) This is fine with me if it improves usability overall.

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.

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.

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

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

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.

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

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.