<scribe> scribe: Andi

MC: Intro - if read ARIA-PRIMER, know how things work. Should at least summarize concept of ATs

CS: somebody implementing this in a browser would be expected to have read WAI-ARIA spec

MC: Don't want to set up something where people have to keep flipping back and forth in the specs

CS: get some of the relevant information from the PRIMER
... Add more about why someone would do this - goals for user experience
... making something look more like a desktop application than a Web page

Web application that is as rich as a desktop application

CS: to submit text/thoughts in a bug

Section 1.1

MC: first sentence - remove "and behavior"

DB: DOM is just the state of the elements

CS: element name describing what each thing is and the relationship between them

DB: change "behavior" to "state"

CS: there are names for the APIs used to manipulate the DOM

DB: looking up what they are called

MC: everything after the first paragraph seems too detailed for the introduction - move to its own section in the document
... previous comment was about section 1.2
... in section 1.3, add styling information about MUSTs and SHOULDs - copy from WAI-ARIA spec

CS: WAI-ARIA has no support for events and support for actions is pretty light - need to add something after the number bullets in section 1
... browsers don't have to map to API for ATs to work - most use DOM - but to make it work like a desktop app they do
... section 1.1, last paragraph before the bulleted list, last sentence - some HTML elements have semantics built in - don't "have" to have ARIA
... separate MSAA and IA2

UIA is supported on both Windows and Linux

CS: first para, add the accessible tree contains both the chrome of the user agent and the document
... sentence that talks about firing an accessible event, not sure how well that works with ARIA

DB: we do do it

no change

change <span> example to "may not"

CS: section 1.2, second bullet - change to MUST
... only SHOULDs in UAIG should correspond to SHOULDs in WAI-ARIA spec

section 2

MC: shouldn't have specific references to user agents - remove references to IE

CS; seems like author advice - maybe the BP doc should give that kind of information

CS: number of places where there is author information - we need to examine to see if there is something relevant to UAI that we need to include

MC: section 2.1, bullet 3 - remove sub-bullets from HTML spec because this may change
... summarize and then reference the HTML spec
... bullet 5 (focus and blur) - change SHOULD to MUST
... bullet 7 (:focus) seems like a WCAG compliance issue - may not need

CS: may need a section on what the default style sheet should contain for ARIA

add a bug for this

MC: bullet 8 (keydown) - everything after first sentence is product specific

CS: move into a footnote or a FAQ

MC: "where appropriate" needs to be defined

DB: "for any focusable element"?

add a bug to figure out what we mean

CS: section 2, first sentence on the first step is a little strong

add a bug - need a section on activation

CS: section 2.1 - what's being described as not working in HTML 4 has always worked in IE - may confuse people

change to "early versions of browsers"

CS: remove HTML 4 para, remove "essentially" from next paragraph, add sentence to "essentially" para that says this is not supported in older browsers and HTML4
... remove reference to IE 5.5
... section 2.1, bullet 2, example of platform order
... bullet 12, define activation behavior

MC: section 2.2 - bullet 4a - not sure last sentence is right

DB: can't really be sure which elements that are children of an element with aria-activedescendent are actually focusable

CS: could be a <span> with a @tabindex on it?

add a bug to work through the aria-activedescendent scenario

DB: look at BP guide

CS: browser needs to handle when authors have done it incorrectly

MC: bullet 5 should be a MUST

CS: worry about aria-activedescendent focus and how it might not be the same as desktop focus - comment for WAI-ARIA

DB: web developer wants to have all keyboard handling on the container - all keypresses go to the container

CS: last sentence, do we need to say anything about scrollIntoView?
... user agents "may" call scrollIntoView?

DB: found that scrollIntoView is not implemented the same everywhere

add to the bug that scrolling into view of focused active descendent needs to be part of the scenario

MC: section 2.3 - first para - API specifics need to be called out in a table

CS: goes in 3, probably in 3.5

MC; 2nd bullet - what happens if it's unsuccessful

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
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
Inferring ScribeNick: Andi
Default Present: Andi_Snow_Weaver, Cynthia_Shelly, Cooper, David_Bolter, Janina
Present: Andi_Snow_Weaver Cynthia_Shelly Cooper David_Bolter Janina

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 12 Jun 2009
Guessing minutes URL: http://www.w3.org/2009/06/12-aapi-minutes.html
People with action items: 

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