Abb attribute or th element should be redone for help assistive technology users

abbr attribute or <th> element should be redone for help asssistive technology users. For now value of this attribute is render of voice synthesizers. But nodoby knows what value the author will use. And now site users must hope for site builder how correctly does it enter the value of abbr attribute. For example if table header cell original name “System of a Down members” ( <th>System of a Down members</th> ) Maybe abbr attribute will choosen by site builder for this case “soad m” or “soad members” or or “soadm”. And maybe it will too differ from the original and no fact what site builder will add original value of abbr attribute “system of a down members” and no fact that assistive user will understand this value.

I think abbr attribute should be remove of HTML specification but browser should voice-render full <th> cell. And so then there will not be different interpretation of <th>header cell name </th> and <th abbr="maybe header cell name"></th>. And if site builder will make a mistake it will mistake for all users same but not for one user one meaning for assistive user other meaning.

If I understand what you’re saying (which is questionable), you’re suggesting abbr and th are used in the same way? That’s absolutely not the case.

I talk about abbr attribute, not element.

Ah, gotcha. MDN has it marked as obsolete in HTML5.

@jhpratt HTML5 specification not obsolete for now. Also MDN is not HTML. I think it must be remove from HTML specification but also specification should have note for browsers like this: “browser should voice-render full <th> cell”

Someone got slightly confused editing MDN previously. The abbr attribute is obsolete on the td element but still active on headers. This mistake on the MDN article has been corrected.

Onto the actual point of removing the abbr attribute from table headers. What is the reason for desiring it get removed? From what I am understanding it comes down to “because some developers may misuse it and make accessibility worse.” Which, isn’t a good enough reason at all.

If that’s the logic then no software should ever be written. Simply having possible misuse isn’t good enough justification for removing something. If that was, then we’d need to remove <div>, <span>, and so many other generic elements. Since, they could be used to create what should actually be button elements. And developers rarely look at setting up keyboard events when they do decide to not use the <button> element.

Doing some testing with this case in particular, ChromeVox itself does not read the abbr attribute at all. And looking at the Chrome DevTools I’m not even seeing it in the accessibility tree for the element. So I don’t think any screen reader software through Chrome would read the attribute’s contents.

Simply because something may be misused is not good enough justification for removing it. However, if someone did some thoughtful research into the actual support in the wild with software around it that could be enough to get a real discussion going.

• What do different browsers do with the abbr attribute?
• How many even put it into the accessibility tree?
• What screen reader software takes advantage of it and how?

If some of these questions could be looked into in detail and brought forward, then there could be a discussion had around getting the specification to reflect the reality that perhaps no one uses it? The spec should in the end reflect what user agents are actually doing. If other browsers are like Chrome’s Blink engine and ignoring this attribute for accessibility, then it may make sense to just obsolete it since no one is properly implementing it.

@Garbee Not always specification should be written after browser support. My proposal is to made web technologies better. What’s the idea to use additional attribute abbr instead render original <th> cell for voice synthesizers? So we could help browser makers if would wrote something additional note in HTML specification about <th> element like this: “recommend for browsers instead render abbr attribute render <th> cell”. It is first step, and second step after realization of the browsers is remove abbr attribute.

This idea good for everybody: for browsers it’s easy problem (relink render from abbr attribute to <th> cell), code will smaller (without abbr content) and for assistive technology peoples it will better. About last case you are not understand me, I meant have one <th> same for everybody what exclude possibility of error (<th> and abbr could too differents) for assistive and non-assistive users.

And they typically aren’t. Ideas get built up and shared around before people start coding. Then as the coding is going on, there is collaboration across vendors on the spec in more detail. However, sometimes that doesn’t happen. Like in this case, it was written but never implemented. When it is all said and done, the specs are only worth what user agents are willing to implement. Therefore, at the very end of it all, the spec should reflect the reality of what is consistently in distribution.

I completely understand what you’re getting at. However, I also know that these things don’t change without data to support it. That is why I gave you a few starting points so you can do research into the needs to move the discussion forward. Nothing can move forward meaningfully without someone doing the research that cares about this happening.

If I understand the original issue here correctly, you’re saying: the abbr attribute should be removed and assistive technologies should ignore it, because authors might put an incorrect value in there and/or users are always better served with getting the full header cell content?

the former (authors getting it wrong) is not sufficient excuse for removing support for something (otherwise we may as well pack up most of the elements/attributes in the spec).

for the latter, there are valid scenarios where an author has decided that the visible header text is overly long, and should instead be presented in a shorter way (as otherwise AT users will hear the entire text every time they get into that particular column). conversely, some authors may do the opposite and have a short visual header text, but a more expanded/humanly understandable abbr. so there are valid scenarios for its presence.

the only valid point i’d say would be to ask that browsers should expose both the header text and, if present, the abbr value, and that assistive technologies should offer users a way of switching (temporarily/on request, or permanently) between them.

@patrick_h_lauke yes, really good idea. ask that browsers should expose both the header text and, if present, the abbr value