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

W3C User Agent Accessibility Teleconference 7 October 2004

From: Jim Allan <jimallan@tsb1.tsbvi.edu>
Date: Wed, 13 Oct 2004 08:53:02 -0500
To: W3C WAI-UAWG <w3c-wai-ua@w3.org>
Message-id: <HDEAKIPKOHBCMDILOOPNEEIHNPAA.jimallan@tsbvi.edu>

Jon Gunderson
Jim Allan - scribe
Matt May
David Poehlman
Aaron Leventhal
Cathy Laws
Will

JG: merging the Mozilla Keyboard Model (mozilla, cita)
al: manages mozilla accessibility effort
need to generate a list of things that need to be done
dp: Sun to come out with new version of the keyboard requirements document.
working with Bejing
al: sent Bejing javascript that uses arrow keys to move by element. Add to
mozilla components directory. "keyboard listener" works with every new page
that opens. Would be useful for specific disabilities that need different
keyboard access. could works based on user preference or user profile, or
presence of screen reader.
jg: hard for non-screen reader users to know and use different keyboard
models. Screen readers use keyboard differently
cl: screen reader will have additional keys over standard mozilla keys.
al: dhtml calendar. on page javascript that changes the way arrow keys work.
may conflict with screen readers. user must be able to access keyboard.
should be at most 2 keyboard layers - caret browsing - move cursor, when
hits something that is focusable moves the focus. Review mode. API for focus
is based on caret position. ATK - by Sun.
jg: compatible with Composer? yes. share keyboard code.
al: how about structural and visual navigation.
cl: "line" is relative to what is on the screen. screen readers define
"line" differently. not visual.
jg: what is difference between structural and visual navigation? want to
avoid different function of arrow keys.
al: screen readers, etc. use up and down arrow to move by element. visually
move by onscreen line.
dp: structure nav is something we need to keep. browsing is different from
editing. describes how JAWS reads "lines" in browser. editing is more
granular.
cl: hpr allows user to control the line length.
discussion of display models and how assistive technology interacts with
these.
al: things that everyone needs in standard model, things for screen readers
goes into overlay/add-on to standard model. similar to shift-f10 for context
menu, use f12 for accessibility options.
will: need predefined user models, configure keyboard for them. work vs.
home...higher verbosity at home.
al: need per web page scripts to change keyboard interface for web
applications. this scripting model allows browser to function like jaws
scripting language.
jg: need to keep in mind the average user. they are not going to write
scripts.
al: right. not the intent. have a repository of scripts.
jg: with these scripts could create a hpr model of mozilla.
cl: right.
dp: personal configuration would be useful. may be confusing at the onset,
screen reader users not used to using other browsers.
dp: what does screen reader developer need to do to work with mozilla.
al: mozilla on windows works with window eyes because they use msaa. JAWS
does its own parsing in IE, then syncs with displayed page. Linux/gnome is
different. uses cursor/caret navigation. not sure how to screen readers with
work with mozilla on linux...may make mozilla self-voicing.
dp: JAWS only works for IE (html parsing), will not work with other
browsers. if there is a way for users to access information directly without
having to way to screen reader developers to make an interface.

jg: up/down arrow moves by line (standard model), screen reader model
(keyboard extensions) would move by element unless overridden by user.
al: keyboard api is javascript, and can include c++. there are DOM issues
with screen readers and what is not available in the DOM (such as, specific
item in ordered lists do not contain the actual number of the item in the
list).
differences between windows and linux accessibility. No plans to work on
Tiger (Mac) accessibility.
mm: Mac is using Safari as their browsing solution. and the Self-voicing of
the operating systems and applications. Not Apples priority to work with
other browsers.

Telecon with Bejing next Friday.
issue with document loosing keyboard focus. DOM does not tell you that the
keyboard has left the document. there are other APIs from which to get that
information.
jg: UAAG could develop test suites for testing keyboard models.



1. Mozilla Keyboard Model (guest Peter Korn from SUN)
http://www.mozilla.org/access/unix/keyboardproposal.html
http://cita.rehab.uiuc.edu/mozilla/mozilla-keyboard.html

Some issues:
1. Screen reader users verus sighted users keyboard requirements

2. User configuration of keyboard shortcuts

3. Test for user agent test suite to support the development
of keyboard support

4. Developing a common document, defining editors, and what
should be in the document
Jim Allan, Webmaster & Sta
Received on Wednesday, 13 October 2004 14:18:10 GMT

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