W3C

- DRAFT -

AAPI

18 Oct 2011

See also: IRC log

Attendees

Present
Andi_Snow-Weaver, David_Bolter
Regrets
Cynthia_Shelly, Tim_Boland
Chair
Andi_Snow-Weaver
Scribe
Andi_Snow-Weaver

Contents


<scribe> Scribe: Andi_Snow-Weaver

<scribe> ScribeNick: AndiSnow

bug 13214 http://www.w3.org/Bugs/Public/show_bug.cgi?id=13214

AS: see proposed text in comment 7. MUST or SHOULD?

DB: think we want everyone to do this the same way but we may not be able to make that happen
... when you have <strong> within a sentence, the accessibility tree might just have only the text element, not an element for strong with a child text element for the part that is strong
... text that is marked as strong would be a sibling of the other text in the accessibility tree
... a browser developer may feel strongly that an element with strong has an element in the accessibility tree
... if they do include it in the accessibility tree, wouldn't want to make it a strong requirement that they fire the text change events
... common example in Firefox - don't have an accessible object for <span> elements

"

For text within a paragraph marked in HTML as <strong>, the <strong> element has its own node in the DOM tree but may not have its own element in the accessibility tree.

DB: suppose you have "the quick brown fox" - if "brown" is removed, you have to fire an event

AS: so that's covered in the first table in 5.8.2

DB: example of something that is not covered by the first table is formatting or style changes?

AS: but how do we quantify it? We can't just say that in some cases you fire the events when the element is not in the accessibilty tree without describing how to determine when you need to do that

DB: (thinking out loud) for changes to content that are not captured by structural changes to the accessibility tree, alternate events should be fired such as: (strong element example)
... the accessibility API may or may not provide the events you need

bug 13258

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13258

DB: table 4.1 should go somewhere later in the document

that's the table of mapping of focus states and events to APIs

DB: we may or may not want to absorb it into the other tables
... could have a 5.8.x on focus events
... 4.2 talking about HTML right? hard to keep them separate.
... changing my mind - 4.1 table may be okay here

Remove the text about tablist from the Selection section. This is covered in the "tab" role row of the role mapping table

change "SELECTED state" to STATE_SYSTEM_SELECTED state" for MSAA columns

change "SELECTED state" to "STATE_SELECTED state" for ATK column

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/10/18 18:59:17 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Andi_Snow-Weaver
Found ScribeNick: AndiSnow
Default Present: David_Bolter, Andi_Snow-Weaver
Present: Andi_Snow-Weaver David_Bolter

WARNING: Fewer than 3 people found for Present list!

Regrets: Cynthia_Shelly Tim_Boland
Got date from IRC log name: 18 Oct 2011
Guessing minutes URL: http://www.w3.org/2011/10/18-aapi-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]