[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tdf-discuss] Accessibility (was Java dependency)
- Subject: Re: [tdf-discuss] Accessibility (was Java dependency)
- From: jonathon <email@example.com>
- Date: Wed, 03 Nov 2010 02:08:05 +0000
- To: firstname.lastname@example.org
-----BEGIN PGP SIGNED MESSAGE-----
On 11/02/2010 07:56 PM, T. J. Brumfield wrote:
> LibO uses the Java Accessibility API to enable the use of screen readers and braille devices.
Screen reading is not the only thing that that API can be used for.
> Is there a better alternative for Windows users?
Roughly five years ago, IBM promised to deliver a better A11Y solution
for Windows to OOo. AFAIK, that hasn't yet happened.
> And how can LibO be made more accessible in general for all users?
Basically, you have to throw away _all_ of the existing code, and
rewrite it from scratch, with i18n, l10n, and a11y as the core
requirements. [Retrofitting a11y, i18n, or l10n always requires more
time and effort that starting from the beginning, with no code at all.]
Full accessibility has several mutually conflicting requirements.
However, if the following criteria are met, most of the conflicting
requirements are negated:
* All input can be done by voice;
* All input can be done by a joystick;
* All input can be done by a Perkins Keyboard;
* All input can be done by a mouse;
* All input can be done using an 78 key keyboard;
* All input can be done on a touchpad;
* All input can be done using a virtual keyboard;
The program must be able to accept simultaneous input from each device;
* All output can be read on a Braille display monitor;
* All output is in an audio format;
* All output can be read on either a CRT or LCD monitor;
* All output can be felt on a touchpad;
The program must be able to simultaneously output to those devices;
The user must be able to change:
* The display size of the data that is presented to them:
** This includes screen magnification on CRT or LCD monitors;
** This includes screen magnification on touchpads;
** This includes all tactile devices;
* The audio volume of the data that is presented to them:
** This includes screen readers;
** This includes self-voicing functionality;
** This includes all audio output devices;
* The colours that are used:
** Icons must be changeable both individually, and as a group;
** Colours used anywhere in the program must be user changeable;
The program must be able to print to:
* A Moon Printer;
* An audio file;
* A Braille printer;
* A "normal" printer:
** Ink jet printer;
** Dot matrix printer;
** Laser printer;
** Thermal ink printer;
In an ideal world, the user could select any of those, and the program
would automatically print out the data on the requested printer, without
any more user intervention.
There is an extension that tries to do output to Braille. The major
issue with it, is that it only works for one or two languages.
I've read about an extension that outputs a text document to mp3 format.
I do not know how far it progressed.
Arguably, A11Y also requires the program to be able to print out the
following file formats:
* Plain text:
** Other common plain text character encodings;
* eBook file formats:
** HTML 5.0;
** AZW (Kindle);
** PDB (eReader);
** Other common eBook file formats;
* Graphical file formats;
** Other common graphical file formats;
I think that most of these could be done as extensions that the user
installs, if they want/need/require the specific output capability.
Some of these, involve file formats that are patented, trademarked,
under copyright, or otherwise blemished.
For full accessibility, the best option, from the user's point of view,
is for each component of an office suite to be a single program, written
for a set of specific accessibility requirements. This option is also
the most expensive for developers to implement.
Some aspects of a11y can be provided as extensions to LibO.
- From my POV, the major point of failure, of the ODF specifications, in
terms of A11Y requirements, is that the style does not define the
writing system that is used.
This is one "custom extension" of the specification that LibO could
make, that should not break in other software that can utilize the ODF
file formats. (My understanding of the XML criteria, is that unknown XML
markup is ignored.)
The importance of including the writing system, is so that text in
Braille, Moon, ASL, and other a11y orientated writing systems can be
directly created and edited within LibO.
I am acutely aware of the issues involved in making LibO capable of
editing documents in Moon. I'm even more aware of the issues involved
in printing documents in Moon. It is hard task. It is very non-trivial
to implement. But full
Something I hadn't thought of earlier, was what the Libre Colour palette
looked like to a person that was colour blind. My colour blind palette
only covers the "websafe color palette". None of the colours are in that
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Unsubscribe instructions: Email to email@example.com
Posting guidelines: http://netmeister.org/news/learn2quote.html
*** All posts to this list are publicly archived ***
|Re: [tdf-discuss] Accessibility (was Java dependency)||Michael Meeks <firstname.lastname@example.org>|
|[tdf-discuss] Accessibility (was Java dependency)||"T. J. Brumfield" <email@example.com>|
- Prev by Date: Re: [tdf-discuss] Old Bugs
- Next by Date: Re: [tdf-discuss] Java dependency
- Previous by thread: [tdf-discuss] Accessibility (was Java dependency)
- Next by thread: Re: [tdf-discuss] Accessibility (was Java dependency)