704416 - HTML acronym and abbr names should be provided by @title

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

HTML acronym and abbr names should be provided by @title. Actually that how it is. But title attribute that's used as a name is treated as we hadn't name so we used a title. That leads to problems like @title attribute is ignored when these elements participates in recursive name calculation, for example,
<label><acronym title="O A T F">OATF</acronym></label>

Comment 1

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 2

[Marco Zehe (:MarcoZ)]

Comment on attachment 576111 [details] [diff] [review]
patch

1. Nit in the test, it's "world", not "word".
2. So we always substitute the actual inner text with the title now, right? Is there a way to get at the original text of an acronym or abbr still? Do we want to make it the description or otherwise available somehow? Sighted people have both available to them as well.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to Marco Zehe (:MarcoZ) from comment #2)
> Comment on attachment 576111 [details] [diff] [review] [diff] [details] [review]
> patch
> 
> 1. Nit in the test, it's "world", not "word".

ok

> 2. So we always substitute the actual inner text with the title now, right?
> Is there a way to get at the original text of an acronym or abbr still? Do
> we want to make it the description or otherwise available somehow? Sighted
> people have both available to them as well.

right, the text is still available by IAccessibleText, description would be excess I think.

Comment 4

[steve faulkner]

hi all, 
Wouldn't the inner text be the accessible name and the title be the accessible description?

So the inner text screen readers would announced by default and a mechanism provided to query the description?

Also note that the title content is not accessible for sighted keyboard users (but that is another issue).

Comment 5

[alexander :surkov (:asurkov)]

usually name is generated from title if nothing else is provided and description is empty in this case. Acronym and abbr are embedded into text so ATs use text interface to navigate through them. I assume that ATs announce accessible name when users traverse through these elements. If name is empty then ATs tries to repair it, for that they could use description for example. But we need to check that with AT developers. Jamie?

Here's the question was what accessible name should be exposed when element refers to abbr or acronym elements. For example,
<abbr id="abbr" title="World wide web">www</abbr><input aria-labelledby="abbr"/>
should we expose "World wide web" or "www" as a name for input accessible.

Comment 6

[alexander :surkov (:asurkov)]

I've got confirmation from AT vendor that description is not what they want since description is sort of optional thing and making it turned on it gets rid advantages of other option used to expand acronyms.

Comment 7

[steve faulkner]

alex wrote:
"Here's the question was what accessible name should be exposed when element refers to abbr or acronym elements. For example,
<abbr id="abbr" title="World wide web">www</abbr><input aria-labelledby="abbr"/>
should we expose "World wide web" or "www" as a name for input accessible."

I would suggest WWW

Comment 8

[steve faulkner]

"I've got confirmation from AT vendor that description is not what they want since description is sort of optional thing and making it turned on it gets rid advantages of other option used to expand acronyms."

so whats the mechanism AT vendors want to implement?

Comment 9

[alexander :surkov (:asurkov)]

(In reply to steve faulkner from comment #8)
> "I've got confirmation from AT vendor that description is not what they want
> since description is sort of optional thing and making it turned on it gets
> rid advantages of other option used to expand acronyms."
> 
> so whats the mechanism AT vendors want to implement?

that one wants to keep @title exposes as accessible name and if abbr is used to label another element than they want to announce expanded acronyms rather acronyms itself. So in my example above they would like to get "World wide web". I think this sort of makes sense since user can't get an easy access to expanded acronym when it's used as part of name for another element.

Comment 10

[steve faulkner]

OK, so when there is <abbr title="World wide web">www</abbr> without it being used as a label for another element how is the title exposed? 
aside, I can't get NVDA to announce the title content?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to steve faulkner from comment #10)
> OK, so when there is <abbr title="World wide web">www</abbr> without it
> being used as a label for another element how is the title exposed? 

as accessible name

btw, getting back to "World wide web" vs "www".

HTML table th elements may used abbreviations: (http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr) like
<TH><ABBR title="Social Security Number">SS#</ABBR>

Compare to abbr attribute on th
(http://www.w3.org/TR/WCAG10-HTML-TECHS/#data-tables):
"Provide terse substitutes for header labels with the "abbr" attribute
on TH. These will be particularly useful for future speaking
technologies that can read row and column labels for each cell.
Abbreviations cut down on repetition and reading time."

Comment 12

[Marco Zehe (:MarcoZ)]

Comment on attachment 576111 [details] [diff] [review]
patch

r=me. This patch does exactly what is being described as desired behavior in comment #9. The label's accessible name is "world wide web", the virtual buffer contains WWW, derived from iAccessibleText, but when querying the object, the title attribute is being used as the accessible name for both the label and an associated input or textarea.

Comment 13

[alexander :surkov (:asurkov)]

inbound land https://hg.mozilla.org/integration/mozilla-inbound/rev/3f8755f87ccd

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/3f8755f87ccd

Comment 15

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111127 Firefox/11.0a1