[aapi] Minutes for June 12th meeting

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

ARIA User Agent Implementation Task Force
12 Jun 2009

See also: IRC log

      Andi_Snow_Weaver, Cynthia_Shelly, Cooper, David_Bolter, Janina
         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

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

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

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

add a bug for this

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

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

CS: goes in 3, probably in 3.5

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

Summary of Action Items
[End of minutes]


Received on Friday, 12 June 2009 16:11:15 UTC