Closed
Bug 666212
Opened 13 years ago
Closed 13 years ago
summary attribute content mapped to accessible name in MSAA
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
RESOLVED
FIXED
mozilla7
People
(Reporter: faulkner.steve, Assigned: surkov)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
(deleted),
patch
|
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
If a table has a non empty summary attribute, the content of the attribute is used as the accessible name for the table.
Reproducible: Always
Steps to Reproduce:
1. go to http://www.html5accessibility.com/tests/table-thead-tfoot.html
2.use an inspect tool to view the acc name and acc description values for the 2 tables
Actual Results:
table 1:
acc name is summary attribute content
acc description is title attribute content
table 2
acc name is summary attribute content
Expected Results:
table 1:
acc name is caption element content
acc description is summary attribute content
table 2
acc name is caption element content
acc description is summary attribute content
may be that acc name should be concatenated text from title+caption for table 1 or only caption and title attribute content is discarded if both caption and summary present.
Comment 1•13 years ago
|
||
I do not believe that any screen reader currently does anything with the title attribute on table elements, not even those that parse the HTML rather than using the accessible tree. So I think if both caption and summary are present, we should discard the title.
Questions: 1. If caption is NOT present, but summary is, is it OK then to use summary as the accessible name?
2. If caption is present, summary isn't, and title is, should we then use title as the source for accDescription?
Blocks: namea11y
Comment 3•13 years ago
|
||
I'm just worried that we might be rendering the caption twice, since the caption is a true element that gets its own accessible with its own accessibleName.
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to comment #1)
> I do not believe that any screen reader currently does anything with the
> title attribute on table elements, not even those that parse the HTML rather
> than using the accessible tree. So I think if both caption and summary are
> present, we should discard the title.
>
> Questions: 1. If caption is NOT present, but summary is, is it OK then to
> use summary as the accessible name?
> 2. If caption is present, summary isn't, and title is, should we then use
> title as the source for accDescription?
answer to question 1: that's what JAWS does.
answer to question 2: seems consistent with other acc name/description calculations no?
Reporter | ||
Comment 5•13 years ago
|
||
(In reply to comment #3)
> I'm just worried that we might be rendering the caption twice, since the
> caption is a true element that gets its own accessible with its own
> accessibleName.
IE 9 maps the the title (if present) to acc name and the caption to acc description.
If no title is present, caption is sued for the acc name.
doesn't do anything with summary.
Reporter | ||
Comment 6•13 years ago
|
||
Chrome 12 (windows) maps caption to acc name and summary to acc help
doesn't do anything with title.
Assignee | ||
Comment 7•13 years ago
|
||
Steve, there's no spec or recommendations?
We keep this behavior for years, we should be absolutely sure the new behaviour is a right thing.
Reporter | ||
Comment 8•13 years ago
|
||
(In reply to comment #7)
> Steve, there's no spec or recommendations?
>
much of the implementation to the acc layer is not specced or agreed upon, this issue highlights the problem.
> We keep this behavior for years, we should be absolutely sure the new
> behaviour is a right thing.
I wouldn't rush to chnage it.
Assignee | ||
Comment 9•13 years ago
|
||
1) caption as a name (bug 111284), compatibility with IE
2) summary as a name (bug 295715), caption is preferred over summary, Aaron's suggestion
3) summary as a name, caption as a description (bug 377783), Aaron's change, no motivation/discussion/objections
I suggest to use
# caption as a name;
# use summary if caption is empty
# use summary as description if not used as a name
this logic is similar to title attribute processing. Sounds reasonable?
Comment 10•13 years ago
|
||
Additionally, if caption is empty and summary is becoming the name, and title is present, title becomes description.
Assignee | ||
Comment 11•13 years ago
|
||
(In reply to comment #10)
> Additionally, if caption is empty and summary is becoming the name, and
> title is present, title becomes description.
sure it is (this is guaranteed by implementation).
Assignee | ||
Comment 12•13 years ago
|
||
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #541349 -
Flags: review?(marco.zehe)
Comment 13•13 years ago
|
||
Comment on attachment 541349 [details] [diff] [review]
patch
r=me thanks! Please test also that, if summary and title are present, but no caption, that title actually gets mapped to the accDescription. I'm missing that test part and would like to see it covered.
Updated•13 years ago
|
Attachment #541349 -
Flags: review?(marco.zehe) → review+
Assignee | ||
Comment 14•13 years ago
|
||
sure if you like
Assignee | ||
Comment 15•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
Updated•13 years ago
|
Assignee: surkov.alexander → nobody
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Target Milestone: Firefox 7 → mozilla7
Version: unspecified → Trunk
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → surkov.alexander
Assignee | ||
Updated•13 years ago
|
OS: Windows Vista → All
Hardware: x86 → All
You need to log in
before you can comment on or make changes to this bug.
Description
•