Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====Contents=====

  * [[https://www.linuxfoundation.org/#RoadMap_for_the_Free_Standards_Group_-_Accessibility_Workgroup|1 RoadMap for the Linux Foundation - Accessibility Workgroup]]
    * [[https://www.linuxfoundation.org/#year_plan:|1.1 year plan:]]
    * [[https://www.linuxfoundation.org/#2_years_out:|1.2 2 years out:]]
    * [[https://www.linuxfoundation.org/#3_years_out:|1.3 3 years out:]]
    * [[https://www.linuxfoundation.org/#5_years_out:|1.4 5 years out:]]
    * [[https://www.linuxfoundation.org/#Other_items_we_can_help_facilitate:|1.5 Other items we can help facilitate:]]

======  RoadMap for the Linux Foundation - Accessibility Workgroup ======

//Draft Version 0.6 -- 23 July 2003//

We will work towards standards that help those producing products to be closer to conforming to US section 508, Europe's CEN, Japan's ???, and Australia's ??? programs.
=====  year plan: =====

1. AT-SPI (or part thereof that all agree on with perhaps some minor exclusions.)

  *  This will gain us key components for desktop/windowing environments.
  *  Lays out the responsibilities of the application vs the AT layer and the kernel.
  *   We have early signs that major Xwindow environments (GNOME and KDE at least) will both be able to adopt this without major disagreement.
  *  This can be be made to work with Internationalization.
  *  The Service Provider Interface is more generic than just a program interface. Between the AT-SPI and the ATK we should be able to implement the libaries in a number of environments.

2. Develop the guidelines for a framework to build on for the use of standards to allow better utilization of a device by multiple apps to reduce the cost of ownership to the end user while maximixing all available compliant applications. (Hardware is expensive, but our software could be made less expensive.) This would make the technology more readily available to more people. #2 Janina is working on this and should publish it to the list.

3. Parts of AccessX Standard for Accessibility. XKB in the Linux world. We will need to decide which specific parts we either include or exclude. #3 Bill has published a list that needs to be reviewed by the group.

  *  Are there any questions or issues?
  *  Is adding this to our standard the right thing to do?
  *  If added what needs to be done to include it in the plan?
=====  2 years out: =====

4. Textmode Only Boot for Accessibility
This will require some kernel, bios, and bootloader coordination.

5. Guidelines for Accessibility Standard for Administrators

6. Magnification Support Standard -- this would be a service API for magnification to be available to AT. This will remove device driver dependencies and isolate utilities from drivers.Although pieces may be worked earlier, even in the first year, this could take some X extension(s) to complete thouroughly. This is not a time concern because of technology, but because of the projects overall size.

7. Text To Speech (TTS)
Could involve XML in terms of what gets sent when and how we should look at Gnome Speech (GSAPI), kttsd API, and JSAPI, as models of Speech API (SAPIs). Speech Service Markup Language - (SSML see W3C for definition.) This service depends on having working code that should be available by this time.
=====  3 years out: =====

8. Work to adopt portions of INCITS/V2 (as appropriate). Needed for servers driving kiosks.

9. Accessibility Standard for Administrators - to the extent possible.
This involves possible kernel modifications, (how do devices plug in), that should be doable by this time frame.

10. Installation Standard for Accessibility
This involves cursor tracking, etc.

11. Comprehensive Braille Standard
We need a description of what this will cover.
=====  5 years out: =====

12. Structured Navigation Standard
- Important for voice driven devices in the car, etc.
- Ties into international DAISY Consortium.

13. Voice based I/O standard
This is currently blocked on technology (software) processing capabilities. -- glyphs must be worked on much more than they currently are under voice only processing
=====  Other items we can help facilitate: =====

  *  Kernel hardware device interfacing standard--perhaps even a Major/Minor spec?

  *  Some of this item is included above--but we need more on the input side, especial console level.

  *  SMIL components and parsing mechanisms -- Libraries We need to beter define this, see what can be done in year one and what needs to be pushed out into future years.

  *  Embedded development - (is there an xServer?)

  *  OCR standards
Wiki

User Tools

Site Tools

Page Tools
