W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2004

UAAG Minutes for 9/30 teleconference

From: Catherine Laws <claws@us.ibm.com>
Date: Thu, 30 Sep 2004 19:13:40 -0500
To: w3c-wai-ua@w3.org
Message-ID: <OF183FB16B.C2190F24-ON86256F1F.007BC06B-86256F20.00014241@us.ibm.com>





Present:
Jon Gunderson (JG)
Peter Korn (PK)
Cathy Laws (CL)
Aaron Leventhal (AL)
Will Pearson (Web researcher at Sheffield Hallam University in the UK - WP)
Earl Johnson (EJ)
David Pohlman (DP)
Jim Allen (JA)
Al Gilman (AG)
Other IBM visitors: Susan Crayne, Sam Detweiler, Allen Wilson

JG: Will, what is your interest related to UAAG?
WP: I'm interested in the accessibility of graphics and SVG.
JG: We're working on test suites for SVG. Sun is working on developing a
better keyboard model for Mozilla. I see 2 main proposals - the one from
Peter and mine.
PK: We had 2 motivations for doing the keyboard proposal. First, our
interpretation of Section 508 1194-21 A - all functions must be accessible
using the keyboard, and using the keyboard for selecting and copying text
to the clipboard is part of that. Screen reader use is important. For
example, the model with IE and JAWS accessing the IE proprietary DOM.
Mozilla can also provide reasonable navigation for the screen reader.
There's been a number of public discussions on the mozilla-accessibility
list, and some private ones as well. Some draw from IBM Home Page Reader
experiences. We wish to incorporate some of the responses from Cathy Laws
at IBM related to HPR as well.
Two main things from my review of UAAG. It fails to articulate that one
must interact, select, and copy from any Web content or plug-in (Flash,
PDF, etc).
We (at Sun) are interested in any thoughts on our, Cathy's, or Jon's
proposal. Also, we welcome help with implementation. It will be
cross-platform. Sun has taken leadership role in proposal and
implementation, but invites others to join in.
JG: UAAG Checkpoint 1.1.1 says all function must be allowed through
keyboard, so it covers selection.
PK: It doesn't seem clear. Need more explanation to clarify. From posting
of the Mozilla keyboard proposal to ITAAC, some were surprised this was a
508 and UAAG requirement.
AL: Also, browsers shouldn't allow color alone to convey information.
JG: UAAG Checkpoint 1.3
AL: For example, whether links are visited or not.
JG: User agents need to require styling.
WP: Just need to convey somehow that links were visited.
PK: In 508, where do we draw the line between the application out of the
box versus an application with a screen reader? We could decide we only
need keyboard selection with a screen reader, but then what about a
paraplegic? Should they be required to use a screen reader?
AL: If the user can change things with a style sheet, but it's over their
heads.
JG: UAAG addresses these issues through our test suites. Requirements for
an AT versus user agent. Some user agents/ATs stepped over the line (i.e.
are really both UA and AT). We would like the user agent  to conform to
UAAG without add-ons. If you can do something with a mouse, you must also
be able to do it with the keyboard. Tests and implementation reports can
show what works in IE versus IE + screen reader, for example. UA group
doesn't try to make a conformance statement for a company but we try to
provide feedback.
PK: We need to get back to keyboard proposals.
WP: I read the proposal and participated in the mozilla-accessiblity forum.
AG: I have two high level comments from Protocols and Format group. I only
looked at Jon's proposal. It has 2 switches being thrown at the same time -
how fine or limited space nav stops for character and active element, and
does focus follow - in caret mode it doesn't and in standard mode it does.
Not clear that screen reader should have separate modes and controls to
unhitch. Other - Jon's proposals separates from actions bound to specific
keys but they can be rebound. How is Mozilla going to integrate XML and
XPL? Important that author should propose key binding but user can change
the bindings.
XPL is a way for the author to set view-specific layer on the DOM. XHTML
which tries to be specific. Example - Does an access key event just move
focus or move focus and fire.
AL: XPL to implement XUL. Allows attachment of behaviors and events to
tags. Attach context to buttons.
AG: Might be able to query DOM to see it.
AL: Ordinary scripts would just see one element.
JG: DOM would have description.
AL: Can extend Mozilla with XPL. Like create a slider with 2 sliders.
AG: How to repair conflicts? Maybe between optimization. In earlier
discussions, AT vendors said that they weren't implementing W3C DOM because
it doesn't match the screen. View-specific shows bounding rectangles. There
is desire to have better info of the view programmatically. One mode to get
view, the other to get content.
PK: DOM doesn't provide info about final rendering. We supplemented this in
IAccessible.
JG: In your proposal, not clear for caret mode versus standard mode for
focus. If navigating a table cell, where is the header info or label info
for a control?
PK: We're serving 2 masters - screen reader user and user without AT.
Evolving discussion. May need additional keyboard bindings beyond proposal
for screen reader user. JavaScript is a good way to do that. Implement
Gnome accessibility for ATK. AccessibleTable object has a table with
children. Ask what is your row extent or column and headers. Sun has not
yet implemented AccessibleTable for HTML tables. But it should be nice for
AT.
JG: Accessing row and column headers is more complex than that . What about
the headers attribute?
PK: The algorithm is not yet implemented. Need mappings
AG: The data model is not there.
JG: Example in WCAG guidelines I will send you.
CL: I'll send a complex table example from the IBM Accessibility
Guidelines.
PK: Another tool in Gnome - AccessibleRelation - extensible.
JG: These relationships should be exposed to all users, not just through an
AT.
PK: How do you expose them?
JG: UAAG has conditional content techniques. Like for alt text, offer
option to not display the images.  For headers, could be exposed as tool
tip when mouse moves over a table cell. For keyboard model, if caret focus
moves into table cell, put headers on the status line. Could have table
view with headers put in front of each table cell content.
PK: Reasonable additions to Mozilla. Don't see how it's about
accessibility.
JG: If not using magnifier or screen reader but you zoom the text, when
viewing the table cell, you can't see the headers. Also, accessible
authoring - people never see alternative content. If there's a headers
view, they wouldn't need an AT.
PK: Good proposals.
AG: Was a description? in content model for table.
DP: Talking about moving focus with navigation. I need info about item, not
just content for item.
AG: Example: On TV, use a layout driver navigation bound in style sheet - 2
dimensional. Daisy - 2 dimensional but navigates differently. Need cursor
quad in both modes.
PK: Cursor keys in Gecko would be in fine, caret mode. Extensions would
override these keys in another mode, like table navigation. Would move from
visual-based to content-based.
AG: Is that best done in event processing interaction with AT? Is it an API
to capture the event?
PK: Screen reader in Unix is largely reacting as caret moves. Screen reader
knows where it has gone or been. If Mozilla extension, Down arrow in table
might go to cell below. Screen reader knows where it was and now where it
is.
AG: Continue work with Aaron and Rich.
PK: Early work about scripting in Mozilla in our screen reader or in Orca.
While we have a DOM, we don't have standard programmatic DOM interface
across browsers. We don't have standard API for screen readers.
JG: How do you handle transitions in fine mode? Like between frames and
iframes - window areas (frames) versus inline frames.
PK: xembed protocol. We haven't considered iframes. Send request to Mozilla
accessibility list.
JG: WebCt plus Blackboard use frames to create UIs for education. Course
list and grading lists scroll while name list stays constant. Fine mode
with frames impacts. JAWS treats frameset as one big page.
PK: Need to think about this more.
JG: Continue next week?
PK: Bulk of work from Sun Bejing but I'm coordinating. Sun Bejing on
vacation through Oct 7. Haven't updated proposal.
JG: October 12 or 13 work?
CL: Not for me. What about the 14th?
AL: Want to talk about resources with Peter.
PK: 14th works. Will have comprehensive proposal but  can't implement it
all at once. Fine caret mode first. Basic table navigation as extension.
We'll see how schedules work for that. Caret navigation into and out of a
form is important to decide, too. Jon's idea of exposing and remapping this
as scriptable Mozilla.
AL: Problem in Mozilla because original developers didn't think about
accessibility.
HG: Meet next Thursday (Oct 7) at 2 PM EST and then on the 14th with
Beijing team.









Cathy Laws

IBM Accessibility Center, WW Strategic Platform Enablement
11501 Burnet Road,  Bldg 904 Office 5F017, Austin, Texas 78758
Phone: (512) 838-4595, FAX: (512) 838-9367, E-mail: claws@us.ibm.com, Web:
http://www.ibm.com/able

Whatever you do, work at it with all your heart.
Received on Friday, 1 October 2004 00:14:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:27 GMT