Last Comment Bug 666212 - summary attribute content mapped to accessible name in MSAA
: summary attribute content mapped to accessible name in MSAA
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla7
Assigned To: alexander :surkov
:
Mentors:
http://www.html5accessibility.com/tes...
Depends on:
Blocks: namea11y 670870
  Show dependency treegraph
 
Reported: 2011-06-22 03:45 PDT by steve faulkner
Modified: 2011-07-12 00:54 PDT (History)
2 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (19.53 KB, patch)
2011-06-23 05:48 PDT, alexander :surkov
mzehe: review+
Details | Diff | Review

Description steve faulkner 2011-06-22 03:45:48 PDT
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 Marco Zehe (:MarcoZ) 2011-06-22 05:26:52 PDT
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?
Comment 2 Marco Zehe (:MarcoZ) 2011-06-22 07:05:29 PDT
This bug is confirmed.
Comment 3 Marco Zehe (:MarcoZ) 2011-06-22 07:06:11 PDT
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.
Comment 4 steve faulkner 2011-06-22 07:08:46 PDT
(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?
Comment 5 steve faulkner 2011-06-22 07:17:48 PDT
(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.
Comment 6 steve faulkner 2011-06-22 07:20:59 PDT
Chrome 12 (windows) maps caption to acc name and summary to acc help
doesn't do anything with title.
Comment 7 alexander :surkov 2011-06-22 07:30:02 PDT
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.
Comment 8 steve faulkner 2011-06-22 07:48:27 PDT
(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.
Comment 9 alexander :surkov 2011-06-23 00:57:33 PDT
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 Marco Zehe (:MarcoZ) 2011-06-23 01:13:51 PDT
Additionally, if caption is empty and summary is becoming the name, and title is present, title becomes description.
Comment 11 alexander :surkov 2011-06-23 02:00:27 PDT
(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).
Comment 12 alexander :surkov 2011-06-23 05:48:48 PDT
Created attachment 541349 [details] [diff] [review]
patch
Comment 13 Marco Zehe (:MarcoZ) 2011-06-23 06:07:35 PDT
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.
Comment 14 alexander :surkov 2011-06-23 21:02:25 PDT
sure if you like
Comment 15 alexander :surkov 2011-06-23 21:18:47 PDT
landed - http://hg.mozilla.org/mozilla-central/rev/63ce1a21bbd0

Note You need to log in before you can comment on or make changes to this bug.