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,
... 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
... 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
... 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
... 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]