Closed
Bug 704416
Opened 13 years ago
Closed 13 years ago
HTML acronym and abbr names should be provided by @title
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
VERIFIED
FIXED
mozilla11
People
(Reporter: surkov, Assigned: surkov)
References
(Blocks 2 open bugs)
Details
(Keywords: access)
Attachments
(1 file)
(deleted),
patch
|
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
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>
Assignee | ||
Comment 1•13 years ago
|
||
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #576111 -
Flags: review?(marco.zehe)
Comment 2•13 years ago
|
||
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.
Assignee | ||
Comment 3•13 years ago
|
||
(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•13 years ago
|
||
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).
Assignee | ||
Comment 5•13 years ago
|
||
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.
Assignee | ||
Comment 6•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
"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?
Assignee | ||
Comment 9•13 years ago
|
||
(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•13 years ago
|
||
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?
Assignee | ||
Comment 11•13 years ago
|
||
(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•13 years ago
|
||
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.
Attachment #576111 -
Flags: review?(marco.zehe) → review+
Assignee | ||
Comment 13•13 years ago
|
||
Comment 14•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Comment 15•13 years ago
|
||
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111127 Firefox/11.0a1
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•