You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
HTML-AAM: @abbr should be part of name calculation #16
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.
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.
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
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?
@cookiecrook Accessibility Inspector with Safari Tech Preview shows value of attr on th exposed in "ExpandedTextValue". And VO seems to read this value to identify the relevant column or row header when navigating cells, but not when reading the name of the th itself. I'm unable to find any documentation about this property. AXExpandedTextValue? Can you help with a steer, or suggestion as to how best to represent this in the HTML-AAM mapping?
For <abbr title> I think it's okay to include this in the language specific labeling attribute, like <img alt>. For <th abbr>, I'm not sure how best to represent in AAM other than to document what the engines currently expose.
For <abbr title> I think it's okay to include this in the language specific labeling attribute, like <img alt>.
Ok. The AAM currently says, rightly or wrongly, to map title on abbr to AXHelp. Chrome maps title to AXDescription on the AXGroup object for abbr. Meanwhile Safari maps it to AXExpandedTextValue on the AXStaticText node.
From your comment, I'm assuming that mapping title on abbr to AXDescription, like alt on img, is preferred.
For <th abbr>, I'm not sure how best to represent in AAM other than to document what the engines currently expose.
Chrome not exposing abbr on th at all from what I can tell, and Safari using AXExpandedTextValue, so I'll propose that as the appropriate mapping.
Ok. The AAM currently says, rightly or wrongly, to map title on abbr to AXHelp. Chrome maps title to AXDescription on the AXGroup object for abbr. Meanwhile Safari maps it to AXExpandedTextValue on the AXStaticText node.
Such is the challenge with normalizing ~ten accessibility APIs into one. 😀 I'd guess the Chrome mapping is just left over from when they forked WebKit into Blink. A lot of the smaller WebKit accessibility fixes since that time never made it to Blink.
Chrome not exposing abbr on th at all from what I can tell, and Safari using AXExpandedTextValue, so I'll propose that as the appropriate mapping. Please use AXExpandedTextValue as the mapping.
Ditto here. Yes, please use AXExpandedTextValue as the mapping.
On Jun 1, 2017, at 10:08 PM, James Craig ***@***.***> wrote:
One last question: Any chance you have a link to publicly available documentation listing/describing AXExpandedTextValue?
No it's not an attribute in the public Accessibility API yet
Activity
jasonkiss commentedon Oct 12, 2016
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.
jasonkiss commentedon Oct 12, 2016
From @jnurthen on March 16, 2016 3:39
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 descedingRegards,
James.
jasonkiss commentedon Oct 12, 2016
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 commentedon May 31, 2017
@cookiecrook Accessibility Inspector with Safari Tech Preview shows value of
attronthexposed in "ExpandedTextValue". And VO seems to read this value to identify the relevant column or row header when navigating cells, but not when reading the name of thethitself. I'm unable to find any documentation about this property. AXExpandedTextValue? Can you help with a steer, or suggestion as to how best to represent this in the HTML-AAM mapping?cookiecrook commentedon May 31, 2017
For
<abbr title>I think it's okay to include this in the language specific labeling attribute, like<img alt>. For<th abbr>, I'm not sure how best to represent in AAM other than to document what the engines currently expose.jasonkiss commentedon May 31, 2017
Thanks.
Ok. The AAM currently says, rightly or wrongly, to map
titleonabbrto AXHelp. Chrome mapstitleto AXDescription on the AXGroup object forabbr. Meanwhile Safari maps it to AXExpandedTextValue on the AXStaticText node.From your comment, I'm assuming that mapping
titleonabbrto AXDescription, likealtonimg, is preferred.Chrome not exposing
abbronthat all from what I can tell, and Safari using AXExpandedTextValue, so I'll propose that as the appropriate mapping.cookiecrook commentedon Jun 2, 2017
Such is the challenge with normalizing ~ten accessibility APIs into one. 😀 I'd guess the Chrome mapping is just left over from when they forked WebKit into Blink. A lot of the smaller WebKit accessibility fixes since that time never made it to Blink.
Ditto here. Yes, please use AXExpandedTextValue as the mapping.
jasonkiss commentedon Jun 2, 2017
@cookiecrook Thanks, as always, for the feedback.
I will update mappings for
titleonabbrto AXDescription, andabbronthto AXExpandedTextValue.One last question: Any chance you have a link to publicly available documentation listing/describing AXExpandedTextValue?
AXAPI mappings for @title on <abbr>, and @abbr on <th> / issue #16
jasonkiss commentedon Jun 2, 2017
Addressed in ef2ad72. Closing.
cookiecrook commentedon Jun 2, 2017
I don't think so. @fleizach?
fleizach commentedon Jun 2, 2017