ABBR attribute on TH elements not supported

[nvaccessAuto]

Reported by hhillen on 2013-10-08 18:48
When announcing the associated column header for a cell in a data table, NVDA does not take the abbr attribute into account. It should read the value specified by abbr instead of the text contents of the TH element.

For more information about the abbr attribute, see the HTML5 spec: http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#attr-th-abbr

I've attached a test case which contains two data tables. Each table illustrates a common use of the abbr attribute.

To use the test case:

1. Open the page, press T to move to the either of the tables. Then use table navigation commands (ctrl + alt + arrow keys) to move between cells in the table.
2. The first table is a calendar grid, with two letter day abbreviations as column headers. When announcing column headers, NVDA should be using the expanded day names provided by the abbr attribute rather than the two letter versions (e.g. "Thursday" instead of "TH").
3. The second table contains links with hidden text providing sorting information about the current column. This is useful when the column header itself is announced, but not when the cells below the header are announced. The abbr attribute is used to fix this. For example, for the "John" cell, NVDA should announce "First Name: John". Currently it announces "First name, sorted ascending, click to sort descending: John".

In JAWS this does work correctly. Note that the abbr attribute should also be supported for grids with focusable, keyboard navigable cells, not just static data tables.

[nvaccessAuto]

Attachment testcase_abbr_attribute.html added by hhillen on 2013-10-08 18:49
Description:
Test case for Ticket #3566

[nvaccessAuto]

Comment 2 by jteh on 2015-05-07 01:56
See also MozillaBug:704754.

[andrew-l-d]

Unless I have missed an NVDA setting, it does not recognise the tag anywhere on a page. Both JAWS and Window-Eyes allow abbreviation expansion to be turned on or off (both off by default) and Window-Eyes offers several options for presenting the information.
Andrew

[jcsteh]

The abbr attribute on th elements and the abbr tag are slightly different. As for the tag, NVDA will report it on demand if you use the report navigator object command (desktop: NVDA+numpad5, laptop: NVDA+shift+o). Note that this equivalent to the sighted user's experience, where the expansion shows up only when the mouse is moved over the abbreviation.

[derekriemer]

Oh? this isn't documented I don't think (If it is, I missed it, and have
seen no screen reader user talk about it) so I don't think that fact is
out there. Just trying to highlight a possible lack in the communication
between developers and users.

On 10/27/2016 7:16 PM, James Teh wrote:

The abbr attribute on th elements and the abbr tag are slightly
different. As for the tag, NVDA will report it on demand if you use
the report navigator object command (desktop: NVDA+numpad5, laptop:
NVDA+shift+o). Note that this equivalent to the sighted user's
experience, where the expansion shows up only when the mouse is moved
over the abbreviation.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3566 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivSGKtvBLYbqAIdqPYLfzsBNjTyBiks5q4UzngaJpZM4Ki-7D.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu
Phone: (303) 906-2194

[jcsteh]

It's not a specific feature as such. It works because the report object command, like the report focus command, reports the description (secondary) information for the object. However, I agree this won't be obvious to most users. Perhaps we should document it as a hint in the browse mode section or similar.

[andrew-l-d]

Especially as other screen readers offer it as an option, including it
in documentation seems well warranted. This clutz would never have
thought of using the Report Current Object to expand an abbreviation.

Andrew

On 28/10/2016 12:44 PM, James Teh wrote:

It's not a specific feature as such. It works because the report object
command, like the report focus command, reports the description
(secondary)
information for the object. However, I agree this won't be obvious to most
users. Perhaps we should document it as a hint in the browse mode section
or similar.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3566 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APIMAf6x7FU89Z6hv9ls5bNGDKB5gQ9Mks5q4VNxgaJpZM4Ki-7D.

[jcsteh]

After some research and consideration, it was decided not to expose this in the accessible/name description. See my comment on the Mozilla bug for details. However, it is already exposed as the "abbr" IA2 object attribute.

[Adriani90]

@ehollig could you please upload the attachment with the test case to this issue from the old issue tracker? The link in the description is not working anymore and I am not able to reproduce the issue.

[ehollig]

@Adriani90 the link is now in #3566 (comment). Also, the link provided in the original post still works for me.

[Adriani90]

@jcsteh as far as I understand, at least Firefox exposes the aBBR atribute now as object atribute. But NVDA is still not recognizing it, I am testing with NVDA 2019.1.1 on Firefox 66.0.5 but it is also the case in Chrome 74 and IE11.
While I agree with you that nvda+shif+o is already a good alternative to the feature requested here, the implementation of reporting the ABBR atribute while navigating the cells other than headers is a valid point. Often in complex tables you habe this stuff with "sort descendent", "sort ascendent" etc. This being reported together with the header is much too verbose and makes table navigation really inefficient. I mean if the ABBR element is covered in Spek, why not doing this? It could be compared to the alt text of an image which is also not visible for sighted people but it provides better accessibility for screen reader users.

[hanshillen]

The updated test case link is https://hanshillen.github.io/testcases/bugreports/NVDA/testcase_abbr_attribute.html.

I still think it would be good if this was fixed. JAWS and VO correctly use the abbr attribute value instead of the TH contents when announcing column headers for lower cells. It would really help us developers and consultants to be able to rely on this attribute when column headers contain more text than just the header name.

Expecting the user to manually get the header's abbr text in object review mode would not be a valid workaround for this issue, since they would still have to hear a cluttered, unhelpful column header announcement every time they move to an adjacent cell using table navigation. Nor would it be useful for abbr to be the TH's accessible name.

As @Adriani90 said: abbr is in the spec, so why not have NVDA users benefit from it?

[afercia]

For what is worth, a while ago in WordPress we experimented a bit with the table header abbr attribute and decided to not use it because not supported by NVDA.

There are actual cases where users would greatly benefit from a working abbr attribute though. One of them is tables with sortable columns. In this case, the table headers need to contain some additional information about the sorting mechanism and state. aria-sort can help but it's often necessary to include additional information.

We could argue a data table should not contain that kind of, in a way, "extraneous" info. Ideally, it shouldn't. However, in the real world, it's not uncommon that table headers contain additional text. In a large project like WordPress it's not always possible to implement large refactoring of existing code. Most ot the times we can only try to improve the users experience by using standards that are supposed to work across all assistive technologies. Making NVDA support the abbr attribute would greatly improve the users experience. The excellent test case by @hanshillen proves there are clear advantages for users in both cases, when abbr is used as expansion or abbreviation.

It would really help us developers and consultants to be able to rely on this attribute when column headers contain more text than just the header name.

I'd totally second that. I'd like to add it would really help in spreading accessibility culture and demonstrate that sometimes "fixing accessibility" is relatively simple.

As said by others above, JAWS and VoiceOver provide a better experience for users. How can we help to make NVDA implement support for the table header abbr? :)

[kylane]

The abbr attribute on th elements and the abbr tag are slightly different. As for the tag, NVDA will report it on demand if you use the report navigator object command (desktop: NVDA+numpad5, laptop: NVDA+shift+o). Note that this equivalent to the sighted user's experience, where the expansion shows up only when the mouse is moved over the abbreviation.

Playing devils advocate - without NVDA announcing there is an abbr available, how would a user know to use those hotkeys?

[dotjay]

This still seems to be an issue. When on a TH element with an abbr attribute, NVDA+shift+o does not report the content of the abbt attribute. The TH's abbr content is not reported when inside table cells either. However, it seems this may primarily be an issue of browser support rather than screen reader support: https://adrianroselli.com/2022/08/brief-note-on-calendar-tables.html