W3C

- DRAFT -

WAI UA

16 Feb 2006

See also: IRC log

Attendees

Present
+1.781.442.aaaa, Jan_Richards, Peter_Korn, +1.877.625.aabb, Jim_Allan, Earl_Johnson
Regrets
Chair
jallan
Scribe
JR

Contents


 

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

AJAX - what is it? What are the accessibility issues? What are the implications for UAAG?

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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/02/16 20:05:37 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]