[Accessibility] Meeting minutes 4/30/2003

[Sharon D Snider]

Draft minutes for the proposed FSG Accessibility Workgroup April 30, 2003

A meeting of the proposed FSG Accessibility Workgroup was held by
teleconference on Wednesday, April 30, 2003, at 1:00pm U.S. CST.

Wednesday,  April 30,  18:00 GMT
--   20:00 CET  (Berlin)
--   19:00 WET (London)
--   14:00 EDT  (New York)
--   13:00 CDT  (Chicago)
--   12:00 MDT  (Salt Lake City)
--   11:00 PDT  (San Francisco)
--   04:00 JST  (Tokyo) (03/21/03)

Duration: The meeting started a few minutes late and we concluded at about
 5 minutes past the hour.

Attendees:
----------------
Doug Beattie
Jonathan Blanford
Bill Haneman
Janina Sajka
Sharon Snider
Matthew Wilcox -

Action Items:
Bill, Janina - Work on rewrite of item 2 with input from other members of
the group.
Bill - Work on a short list of XKB/AccessX  specific features.
Doug -  Sent out updated Roadmap (v0.2 sent out after meeting).
Janina - Contact people we haven't heard from in a while.
Janina - Confirm licensing issues for SMIL (if any).
Sharon - Confirmed approved mission statement is correct on the Web site.

Agenda:
1. Welcome and review of minutes from our last meeting

2. Ask for a volunteer scribe to minute this meeting.
Sharon volunteered to take the minutes.

3. Old Business
a.)  Finalize Mission Statement
The following mission statement approved by those present.
Our mission is to develop, apply and promote free and open accessibility
standards to enable comprehensive universal access to computer systems,
applications, and services.

b.)  Proposed "Road Map" Document -- What's missing? What needs restating?
Are the timelines and priorities appropriate? This discussion was deferred
from our earliest meetings while we examined opportunities arising from
AT-SPI;

Roadmap discussion:

Item 1. AT-SPI/Section 508
Bill  mentioned that the AT-SPI and section 508 relationship are not as
intimate as implied in the roadmap. There are regulatory and conformance
issues. Maybe we should work towards an FSG conformance suite, along with
international standards as one aspect.

Further discussion concluded that Doug will work on rewording item 1. He
also stated that the group can not claim that if a developer meets the
standards that they are compliant.

Item 2. Develop the guidelines...
Bill asked if this is an interface standard for hardware devices?

Janina said that it was about software and hardware working together as
Kirk discussed at the last meeting.

Bill  stated that there is no protocol standards for speech hardware
devices. This could be hidden if using a common API for communicating with
the hardware and software services. It would be nice for Braille to be plug
and play. Suggest  candidates for standards for input devices (ie., text
IO)

Doug asked Bill if he would like  to rewrite item 2.

Bill accepted, with the help of Janina and others.

Janina stated that it would be good to get input from other members of the
group that are familar with the kernel as well. She also mentioned
including user requirements for device interfacing. For example, speech
requirements while using multiply applications simultaneously.

Bill stated that technologies are available for mising audio streams when
there are one or more TTS services that need to be shared or clients
contending for it. It should be possible to que up, so they are not talking
at the sametime.

In conclusion it was determined that the group needs to be careful when we
talk about drivers, and picking drivers that need to be present.
and to try and determine what the immediate needs are and ways to deal with
it. As well as get an understanding of where they fit together.
It was decided that the item would be re-worded using the work framework
rather than guideline.

Item 3. AccessX standards
Bill stated that the Linux 386 world is XKB which includes AccessX
capabilities, implemented by Trace, Sun and others. Maybe we could point to
XKB documentation.

Janina wanted to know if we ask for behaviour accessibility compliant
systems?

Bill  responded that  XKB can be turned on by default in the server.

Doug  asked Jonathan, if this is hard for the distributions to do?

Jonathan replied that turning it on by default makes a good amount of
sense, but he's not familar with all the AccessX components.

Bill stated that he could work a short list of items on the specific
features that the group might call out.

Doug agreed that we need to be specific on the group should look at.

Bill gave a few  reasons for  using XKB, which  are binary standards/
specs, function test, accessibility implementation which are all dependent
on XKB server side APIs that are important to assistive technologies.

Jonathan  asked if we has a list of AccessX and XKB requirements and for
what specific reasons?

Doug  mentioned Behaviorial specifications.

Jonathan asked if in the case of AccessX,  would we say this is the
required behavior and how the developer does it is up to them?


Bill gave  3 aspects to item 3 that need to be considered.
      1) User behavior
      2) Ability for the user to configure the behavior
      3) Important API support for keyboard accessibility

Jonathan - User keyboard "expectations" that require specific behavior,
such as keyboard navigation?

It was concluded that we need to address this further,  be more specific,
and reword the item. It appears that this line item may need to be broken
down.


Item 4. SMIL libraries
Janina  opened the dicsussion and stated that we need SMIL support. It
sounds like it will happen in GNOME but she hasn't heard from KDE.

Bill stated that support for SMIL is one thing, that it is  a functional
criteria. It could say that we have to bless an implementation and
libraries.

Doug said that sometimes we have to reference a certain library or base.

Janina  expects that there will be a lot of implementations of SMIL. A lot
of applications could find it useful.

The discussion continued with regard to syncrhonizing the media. What code
to render SMIL? Syncrhonized delivery of multimedia that is not a self
contained componet to display or output information. How does the platform
sync? types, streams, CODECs, video? A question arose if SMIL should be a
year one problem? Should we say a functional requirement is that a viewer
is available?


Janina would like to see a functional requirement and that it should be
included in the stack where ever appropriate. Presentations on servers can
vary widely. Syncrhronization should be managed and provided in
applications. To get it included in the future, we need as much as we can
deliver.

Bill brought up the question of  licensing issues with SMIL and  Janina
stated  that W3's new policy did not have any licensing issues. Janina will
confirm this.

c.) Web page progress -- The page is up but not linked. Do we need a policy
regarding sites we point to?
Delayed for next discussion.

4. New Business
None discussed.

5. Confirm our next meeting is Wednesday, May 7.
Meeting closed by Janina at the end of year one, of the roadmap. Next
meeting confirmed for May 7.