[Accessibility] Minutes from 08/27/03 meeting

Doug Beattie dbb at linkexplorer.com
Thu Aug 28 08:26:50 PDT 2003

John was having problems getting the minutes to the list from his new
office, so he asked I send them for him.

See attached text file of minutes.

Thanks John for doing this.

Doug Beattie
dbb at linkexplorer.com
-------------- next part --------------
Meeting minutes 8/27/03
A meeting of the Accessibility Working Group was held by teleconference on Wednesday, August 27,2003, at 2:00 PM U.S. Eastern Time.

Doug Beattie 
John Goldthwaite
Bill Haneman
Janina Sajka 
Sharon Snider 
Matthew Wilcox

Action Items:
3. Xkb - Janina will look at Bill's xkb proposal and see if we can reuse it.
4. Text-only accessible booting - Janina with Matthew Wilcox, Kirk
5. Guidelines for Sys admins - Janina with help from Doug  
7. Text-to-speech - Janina will talk to Mark Mulkayhe
8. V2 - Janina
9. Sys Admin - Janina 
10. Installation - Janina 
11. Braille - Janina has written to Mario.
12. Structured navigation - Janina

2. AT device handling 

Jonathan & Bill-
1. AT-SPI - work with Peter Korn on this.
6. Service API Support for Magnification  - Jonathan will talk to Peter. 

13. Voice I/O


Minutes for last week approved.

Next board meeting is Sept. 22 so we need to complete our proposal.  Sept. 15 is the due date for the proposal to be considered during that meeting, only two meetings before then. Bill will be at the AAATE meeting in Dublin next week giving a paper and is the plenary speaker.

Bill: In 102 Section A- everything in A is in the context of assistive technologies, later we allude to other things such as navigation.  We are giving the message that the project involves just the assistive technology platform.  We're leaving out things- solution is cooperation between OS developers, application developers and AT developers.  Janina will add this to section A.

Scope for each section of B:
What is the problem.
What work needs to be done
Who has the problem; who benefits from the solution.
Who will work on the standard for this section.

Outline for the proposal can be found on website:

Related technology that will not be included:  discussion of areas that will not be covered, e.g. instances of AT clients.  Talking about API discussions not applications.  Limit to things we have discussed and definitely decided that they are out of scope.  List approaches that we have determined to be bad strategies.  Emacspeak is a related technology- someone might argue that it should be included in distributions but we have not listed in our technical solutions because it is an application.  

Doug- can say that the distribution should include a product of this type but not name a specific product.  
Brltty - have some libraries for Braille translation and drivers which are also being used by Gnopericus.  Should we include the libraries and drivers but not explicitly require brltty?  We need to talk about this but after we do the proposal.  There have to be things like printer drivers that have a product life span.  When do you drop them out of a distribution when they are no longer widely used?

Board meeting - what stage of process do we have complete for the proposal - 
We have to have enough information to make them confident that we know what we are doing and have enough participants to carry out the project.  
Need to be through step 3, need to have our core resources identified.  Define some of the sub-committees, we have interim chairperson.   Other details can be defined later.
Charter- e
Presenting formal proposal, deliver four documents listed at the end of fsg102...txt 

Task, we will not be able to say who is performing each task.  We can identify leaders for each sub-section.  
Janina- we need formal recognition to help recruit people and to go to sponsors for funding.   We need enough for the board to feel comfortable going public. 

Doug sending out list of people for the participants section.

Roadmap review:
1. AT-SPI -  This is a finished product that we want to adopt.  Benefits people who cannot use the standard interface.  It facilitates an appropriate alternative interface via assistive technology.  These are meta-user agents that exist on the GUI, not work around for each application.  Bill- the two primary Linux graphics environments, Gnome and KDE, have both have committed to adopt this technology.  Debian and other distributors of Linux graphical environments benefit since it enables them to meet accessibility requirements.
2. Develop libraries that allow client applications to share I/O devices.  Shared access to accessibility related devices such as Braille displays, reduces cost of ownership, improves user experience  - Currently can't use speech synthesis and media player simultaneously.

3. Xkb - prior art to adopt- user visible features such as sticky keys and xkb routines - people with mobility problems benefit from this via built in features and via AT such as screen-keyboards and screen readers (for keyboard echo).  Rename to Keyboard accessibility- end user features all or a subset of xkb features, all API features of Xkb.  Also note that this is a accepted standard.

4. Text only booting- access to system functions throughout the booting process.  Change "will require kernel and bios changes" to "may require coordination with kernel and bios teams".

5. Sysadmin- accessible sysadmin process and helping sysadmins support people with disabilities.  Not too big a problem except for tools that have graphical elements for visualization.  Managing Binary unfolding.  Wizards to help set up access features, sysadmin could show various options to user.  Set up where user and sysadmin don't have to be experts on configuration of Linux AT software.  Needed for People who have conditions that vary over time, have tremors some days and not others.

6. Magnification support standard, "this will remove device driver dependency", in Linux applications have little interaction with drivers.  AT can't access video driver since X isolates you from it.  Purpose is to Allow AT to interact with display hardware in more sophisticated and higher performance level to provide screen magnification.  Allow moving small areas of screen, enlarge and display it in another part of the screen.  Allow magnified display while application is writing to the screen.  Will need a lot of cooperation.  Because of transparent networked nature of X system, it is not possible for AT to just replace device drivers or talk directly to video hardware. This standard will facilitate providing interfaces such as screen magnification.  Some vendors have projects in process that will contribute as an implementation.

7. Text-to-speech- a framework where you can always do text-to-speech in any language.  Internationalization cannot only deal with fonts but also text-to-speech in the language.  Standardized mark up for spoken dialog.  Provision of an API for text-to-speech services (JSAPI like)  Gnomespeech provides an API and there is a proposal which would converge Gnomespeech with JSAPI.  

8. V2 - XML transport independent method to auto-negotiate with another device to change its user interface.  Do we need to require V2 as part of the standard?  Are there parts of V2 that can't be implemented without some specific features in the API?  Differences could exist between embedded Linux vs. Enterprise versions.  This time frame seems to be work but we may need to revisited as the V2 standard is developed.  

9. Accessibility Standard for Administrators- 
10. Installation Standard for Accessibility 
11.  Comprehensive Braille Standard - brltty  ... If they are compliant USB device, you have to identify yourself.  You should be able to look it up and see what driver you need.  Responsibility is extension to brltty for identifying devices.  This could be sooner than 3 years.  Other aspect which maybe out of scope- problems of multi-language Braille.  We can't say what the Braille content should be- partially international group - do you reverse the Braille display for right to left languages? 

Burden of dealing with multilingual text is on the reader.  With written text foreign phrases are italicized so you can identify them easily.  In Braille languages have different dot patterns.  Need to have markup to indicate where you are changing languages.  Need language tagging for text-to-speech particularly in multilanguage cases.  Unicode string unambiguously specifies international characters,  Braille glyph sets are different in have to be different since you only have 6 or 8 dots- Also problem of level 2 braille which creates contractions.  

Our next meeting is Wednesday, August 27 at 18:00 

More information about the Accessibility mailing list