[Accessibility] Minutes of July 25 meeting

John Goldthwaite john.goldthwaite at catea.org
Wed Jul 2 12:50:45 PDT 2003


 I sent the July 25 minutes from the wrong email account - here
they are:

Draft Minutes for Proposed FSG Accessibility Workgroup Meeting
6/25

Doug Beattie
Jonathan Blanford
John Goldthwaite
Bill Haneman
Scott McNeil
Janina Sajka
Sharon Snider
Matthew Wilcox

Action items:
Bill will email his draft of 102 and Sharon will post it to
website.
John will check on requirements for setting up Wicki.

Next meeting July 2, 2003 2 pm.

No current examples of the 102 documents.
Minutes from last meeting approved.

Topics for today: 102 proposal and XKB stack

Road map for 102 document on website is up to date.   Janina will
work on the 102a section and try to get it out by Friday.

Description of problem:
1. AT is not available on Linux platform.
2. From developer point of view, no means of meeting application
accessibility requirements. Need guidance, documentation and
tools that make it easy for developers who are not accessibility
experts.
3. For AT developers- there are heterogeneous toolkits, no AT
API, can't consistently get information needed from OS and
application software.
4. OS exposes inaccessible features to user, e.g. desktop is
multimedia and requires use of a pointing device.

Develop a standard for end-users and developers that provides a
reliable experience for users with disabilities.  Things
enumerated in roadmap- examples
Say we don't take a position on self-voicing.  AT developers will
need to develop screen reader that uses the speech api.  If
developing an on-screen keyboard, can take advantage of
sticky-keys and not defeat it.  Other apps need to know that
sticky keys is there and not to step on it.

Gnome is able to handle a mixture of things that self-voice and
screenreading.  Two ways for speech interface:  screen reader and
build speech in application (Home page reader).   Self-voicing is
well meaning but it makes you learn a new user interface.  The
argument for self-voice is that app would know its context and
would provide a smoother and more complete interface.  But it
would likely not have commands consistent with screenreaders and
other self-voicing apps.  Daisy- reading of content is another
situation.  Mix- talking clock: automatic announce or explicitly
reading the time.

Users and developers need to know what are standard access
features so that don't interfere.

Standards for APIs let you build portable AT and
API - applications could use the AT client features to provide
more information.  Need standard ways to provide more
information.  API needs facilities to get configuration and
time-out information.  If synthesizing keystrokes, app needs to
query the system to see if the user has slow-keys on or only the
first key might be typed.

We need to generate our draft 102 document so this is primary
item on action item list.  See above.

Status of Roadmap.
Should roadmap contain scale able vector graphics?  More of a
content issue; its important for developing applications and
content but there are plenty of efforts underway to implement
SVG.  It is important that it be there but doesn't need to be
part of an API.

Emerging standard for desktop icons:  a number of sizes defined
but not SVG.

Next meeting July 2, 2003 2 pm.

John Goldthwaite, Senior Research Scientist
Center for Assistive Technology and Environmental Access, Georgia
Tech
404 894-0563 (voice)
866 948-8282 (toll free voice/TTY)
john.goldthwaite at catea.org
-------------- next part --------------
Draft Minutes for Proposed FSG Accessibility Workgroup Meeting 6/25 =


Doug Beattie
Jonathan Blanford
John Goldthwaite
Bill Haneman
Scott McNeil
Janina Sajka
Sharon Snider
Matthew Wilcox

Action items:
Bill will email his draft of 102 and Sharon will post it to website.
John will check on requirements for setting up Wicki.  =


Next meeting July 2, 2003 2 pm. =


No current examples of the 102 documents.  =

Minutes from last meeting approved.

Topics for today: 102 proposal and XKB stack

Road map for 102 document on website is up to date.   Janina will work on t=
he 102a section and try to get it out by Friday.   =


Description of problem: =

1. AT is not available on Linux platform. =

2. From developer point of view, no means of meeting application accessibil=
ity requirements. Need guidance, documentation and tools that make it easy =
for developers who are not accessibility experts. =

3. For AT developers- there are heterogeneous toolkits, no AT API, can't co=
nsistently get information needed from OS and application software.
4. OS exposes inaccessible features to user, e.g. desktop is multimedia and=
 requires use of a pointing device.

Develop a standard for end-users and developers that provides a reliable ex=
perience for users with disabilities.  Things enumerated in roadmap- exampl=
es
Say we don't take a position on self-voicing.  AT developers will need to d=
evelop screen reader that uses the speech api.  If developing an on-screen =
keyboard, can take advantage of sticky-keys and not defeat it.  Other apps =
need to know that sticky keys is there and not to step on it.

Gnome is able to handle a mixture of things that self-voice and screenreadi=
ng.  Two ways for speech interface:  screen reader and build speech in appl=
ication (Home page reader).   Self-voicing is well meaning but it makes you=
 learn a new user interface.  The argument for self-voice is that app would=
 know its context and would provide a smoother and more complete interface.=
  But it would likely not have commands consistent with screenreaders and o=
ther self-voicing apps.  Daisy- reading of content is another situation.  M=
ix- talking clock: automatic announce or explicitly reading the time.

Users and developers need to know what are standard access features so that=
 don't interfere.

Standards for APIs let you build portable AT and =

API - applications could use the AT client features to provide more informa=
tion.  Need standard ways to provide more information.  API needs facilitie=
s to get configuration and time-out information.  If synthesizing keystroke=
s, app needs to query the system to see if the user has slow-keys on or onl=
y the first key might be typed.  =


We need to generate our draft 102 document so this is primary item on actio=
n item list.  See above.

Status of Roadmap.
Should roadmap contain scale able vector graphics?  More of a content issue=
; its important for developing applications and content but there are plent=
y of efforts underway to implement SVG.  It is important that it be there b=
ut doesn't need to be part of an API.

Emerging standard for desktop icons:  a number of sizes defined but not SVG.

Next meeting July 2, 2003 2 pm.=20


More information about the Accessibility mailing list