summary attribute content mapped to accessible name in MSAA

RESOLVED FIXED in mozilla7

Status

()

Core
Disability Access APIs
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: steve faulkner, Assigned: surkov)

Tracking

(Blocks: 1 bug)

Trunk
mozilla7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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

6 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: 459353

Comment 2

6 years ago
This bug is confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

6 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

6 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

6 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

6 years ago
Chrome 12 (windows) maps caption to acc name and summary to acc help
doesn't do anything with title.
(Assignee)

Comment 7

6 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

6 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

6 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?
Additionally, if caption is empty and summary is becoming the name, and title is present, title becomes description.
(Assignee)

Comment 11

6 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

6 years ago
Created attachment 541349 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #541349 - Flags: review?(marco.zehe)
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

6 years ago
Attachment #541349 - Flags: review?(marco.zehe) → review+
(Assignee)

Comment 14

6 years ago
sure if you like
(Assignee)

Comment 15

6 years ago
landed - http://hg.mozilla.org/mozilla-central/rev/63ce1a21bbd0
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7

Updated

6 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

6 years ago
Assignee: nobody → surkov.alexander
(Assignee)

Updated

6 years ago
OS: Windows Vista → All
Hardware: x86 → All
(Assignee)

Updated

6 years ago
Blocks: 670870
You need to log in before you can comment on or make changes to this bug.