See also: IRC log
AJAX - what is it? What are the accessibility issues? What are the
implications for UAAG?
Attendees from SUN today: Peter Korn, Will Walker, Dan Labrecque
<scribe> Scribe: JR
Possible regrets from Cathy Laws
JA: UA might develop document
about how UAAG should relate to AJAX
... PF is looking at DHTML - which will relate to AJAX
EJ: AJAX is an approach ...- introduces same challenges as DHTML.
DL: In SUN, AJAX being used to replace large junks of page - prob for screen readers, etc.
JA: Prob. for DHTML as well - all comes back to things are dynamically changes...how are users supposed to finf out.
PK: User Agents will need to
implement platform accessibility API...
... User agents would need to pick up annotations...
... Info from DHTML to UA to platform accessibility API to
Assisitive tech.
... That seems to be appropriate place for UAAG to address
this.
... Issue is that platform dependent issues come to
forefront.
DL: In talking to Aaron from IBM,
they seem to be identifying various approaches (roles,
etc.)
... Aaron had info on which things are working already (Window
Eyes + Firefox)
... Approach: start focussing on stop gap places...
... Then there are the support issues...
PK: Thinks that in uaag there would be specific checkpoint realted to all of the DHTML abilities - then state that the platform API's are the way to deal with them - then specific guidance plat-by-plat in the appendix.
JA: Yes hoping to do that in
techniques.
... We do want to review new techs as they come out - if we
find a hole then we may have to open up uaag. If no hole, then
we'lll add more to uaag techs.
PK: Any holes found?
JA: No holes found during DHTML review.
PK: Convinced there are
holes...
... In semantic area - no way to convey semantic meanings
without API specifics
... Not enough to just say there's a DOM event and assume AT
knows about it.
... Because people are using AJAX to put apps inside browsers
that look remarkably like desktop apps.
... More work then is needed to bring these across to the
uyser.
JA: But semantics in the code...
PK: But in IBM work, "this thing is a menu role" - in flash, etc, etc. but as long as it is annotated appropriately and right events are fired then it should be handled as a menu.
DL: That is the course that has been defined...
PK: L But not given PF blessing.
DL: IBM using unsupported techs
(eg. XHTML 2.0) to do some of this stuff.
... Where do we start now?
PK: We are talking about bring in
section 508 (desktop applications 1194.21) into UA.
... To some extent this is in WCAG -e.g. if you use Java etc. -
but now its not extra content that is passed off, its done with
content that the browser itself parses
DL: There's also Section 508 .22 that falls on the content writer.
PK: More concretely: In http://www.gregphoto.net/sortable/index.php
... Once I focus, i need to move it with keyboard PLUS i need
labels...
... All this needs to be exposed out through platform API
... UAAG shouldtalk about how we expect roles etc to be used,
including examples.
... We should also reference, as examples, good examples of
annotated content.
JA: Right - in test suites
... Let's look at Google suggest
JA; JAWS does read some of it - what goes into form field.
JK: But JAWS FAILS because there is more to the menu item than suggested text, there is also the number of results which JAWS did not read
JA: Playing devils advocate: is it the author who does it?
PK: Ideally it is the author of
the AJAX GUI toolkits.
... Would already be done.
... AJAX authoring tool would also have accessibility
validation for this stuff.
... Basically this is the desktop coming to the browsert.
... DHTML and AJAX are coming along REALLy fast.
... We would really like pf and ua to push out some guidance
asap.
... Fortunately roles, etc don' affect rendering so if they
change it shouldn't be a big deal
... Main starting point is Firefox existence proof.
JA: Don't want to rush opening uuag.
JR: Could be a W3C Note
PK: Not suggesting complete overhaul - it would be a new section.
JA: Thinking about changing techs note and point to PF work.
JR: Note also gives better flexibility to say platform epecific things.
PK: This approach seems to make
sense - though want to make sure we go into enough
detail.
... e.g. menu is a role from PF, this is what the expected
behaviour is
... then further in test suites
<jallan> discussion of Authoring tool
<jallan> inviting sun folks to speak at authoring tools meeting
JR: AUWG and WCAG-Gl should be informed about this as they go towards last call.
<jallan> how to get DHTML concerns into wcag
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: JR Inferring ScribeNick: JR Default Present: +1.781.442.aaaa, Jan_Richards, Peter_Korn, +1.877.625.aabb, Jim_Allan, Earl_Johnson Present: +1.781.442.aaaa Jan_Richards Peter_Korn +1.877.625.aabb Jim_Allan Earl_Johnson Got date from IRC log name: 16 Feb 2006 Guessing minutes URL: http://www.w3.org/2006/02/16-ua-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]