Closed
Bug 704754
Opened 13 years ago
Closed 13 years ago
expose abbr object attribute on header cells
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, dev-doc-needed)
Attachments
(1 file)
(deleted),
patch
|
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
the idea was suggested by AT vendor. Some background on this.
header cell abbreviation can be specified by two ways:
# <th><abbr title="Social Security Number">SS#</abbr></th>
# <th abbr="SS#">Social Security Number"</th>
abbr element has accessible name picked up from @title attribute so th element name will be build from abbr element starting from bug 704416. It's quite suitable when user navigates through header cells and hears full name. However when user navigates through data cells and associated header cells are announced then it's more convince for the user to hear short names. That's abbr object attribute is supposed for.
references:
http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr
http://www.w3.org/TR/WCAG10-HTML-TECHS/#data-tables
Assignee | ||
Comment 1•13 years ago
|
||
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #576415 -
Flags: review?(marco.zehe)
Comment 2•13 years ago
|
||
Comment on attachment 576415 [details] [diff] [review]
patch
r=me thanks!
Attachment #576415 -
Flags: review?(marco.zehe) → review+
Comment 3•13 years ago
|
||
note the abbr attribute and other related table accessibility attributes have been dropped in HTML5 http://dev.w3.org/html5/html4-differences/#absent-attributes
Comment 4•13 years ago
|
||
Yes, but screen readers of the commercial flavour have been using them for years, I remember seeing use of the axis attribute in JaWS almost 10 years ago, for example. If there are equivalent HTML5 techniques to accomplish the same, we'd be happy to entertain them. If they were dropped just for the sake of dropping them, I think supporting them is valid.
Comment 5•13 years ago
|
||
Hi Marco, I was not suggesting to not support the feature(s), just pointing out that they have been dropped. I would encourage them to be supported for backwards comaptibility at least. What I would say is that as they are dropped their usage and promotion (via WCAG techniques for example) as useful methods will decrease over time.
Assignee | ||
Comment 6•13 years ago
|
||
(In reply to steve faulkner from comment #3)
> note the abbr attribute and other related table accessibility attributes
> have been dropped in HTML5
> http://dev.w3.org/html5/html4-differences/#absent-attributes
Steve, you know a reason why abbr and axis were dropped? I don't see equivalent for them.
from: http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#non-conforming-features
abbr on td and th elements
Use text that begins in an unambiguous and terse manner, and include any more elaborate text after that. The title attribute can also be useful in including more detailed text, so that the cell's contents can be made terse.
the text beginning in an unambiguous and terse manner doesn't help AT to get short name in general. If the text is supposed to be short like that one that was provided by abbr attribute in HTML4 and title attribute should return normal description (like expanded abbr) then users sees short text when table allows to show more text (see bug 298199) and title attribute can't be used to provide description.
axis on td and th elements
Use the scope attribute on the relevant th.
scope is alternative to @headers attribute, to say this header cell is for datacells in row, col, rowgroup, colgroup. axis was used to provide some semantics for cells in row, col and etc (if used in conjunction with scope attribute). AT could use it provide advanced table navigation.
Comment 7•13 years ago
|
||
I think that they were dropped because they were considered as not being used or being used correctly when they were used. Also maybe because they were not implemented in any main stream user agents. I don't think accessibility support in browsers counts as an implementation of a feature.
Comment 8•13 years ago
|
||
(In reply to Marco Zehe (:MarcoZ) from comment #4)
> Yes, but screen readers of the commercial flavour have been using them for
> years, I remember seeing use of the axis attribute in JaWS almost 10 years
> ago, for example. If there are equivalent HTML5 techniques to accomplish the
> same, we'd be happy to entertain them. If they were dropped just for the
> sake of dropping them, I think supporting them is valid.
They were not dropped just for the sake of dropping them. The following messages provide some of the rationale for why they were not made part of HTML5
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-March/014245.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015867.html
In particular, see Hixie's comment about axis in the first message about: "I haven't added axis, mostly because nobody seems to understand it, so it would likely not be used well even if supported."
And in the same message, see this comment about the summary and abbr attributes: "I don't really see that these attributes actually help anyone."
And in the second message, see the comment, "I agree entirely that abbreviating long headers is something that should happen. But it should happen for _all_ tables, not just those written by conscientious authors.W
As far as their usage in public Web content, see the data here:
http://dev.opera.com/articles/view/mama-tables/#tdth
That shows that the axis attribute is used on the td element in only 0.01% of pages sampled, and on the th element in only 0.08%.
That shows that the abbr attribute is used on the td element in only 0.10% of pages sample, and on the th element in 3.47%.
So the figure for abbr on th is high enough to make it worth looking at the documents that do use it and seeing if they use it correctly. I suspect that most of those documents do not use it correctly, because that's what we've found in the past for other cases of markup features that are not widely used, not well understood by developers, and whose content is not displayed in visual browsers.
All that said, I think as with any other language feature, browser projects and implementors should be basing their implementation decisions about a particular feature on whether there are clear use cases for that feature, and whether the feature does (or will in practice) actually solve the problem it was meant to solve. Whether the feature is part of the current spec or not (or was part of a previous spec) should not carry nearly as much weight as whether it has clear use cases and clearly solves a problem in practice, not just in theory.
Assignee | ||
Comment 9•13 years ago
|
||
Hi, Michael. Thank you for commenting. I would add that accessibility is special area, it's often about conscientious authors and evangelism. If particular feature can be useful to make the web more accessible then it's worth to care about it.
Assignee | ||
Comment 10•13 years ago
|
||
Comment 11•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
Assignee | ||
Updated•13 years ago
|
Keywords: dev-doc-needed
Comment 12•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
•