[aapi] Minutes for June 12th meeting

Posted at http://www.w3.org/2009/06/12-aapi-minutes.html


- DRAFT -
ARIA User Agent Implementation Task Force
12 Jun 2009


See also: IRC log


Attendees
Present
      Andi_Snow_Weaver, Cynthia_Shelly, Cooper, David_Bolter, Janina
Regrets
Chair
      SV_MEETING_CHAIR
Scribe
      Andi
Contents
      Topics
         1. Section 1.1
         2. section 2
      Summary of Action Items









<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


Summary of Action Items
[End of minutes]




Andi