Accessibility in Linux systems

Posted Oct 9, 2008 1:04 UTC (Thu) by i3839 (guest, #31386)
Parent article: Accessibility in Linux systems

I wonder, there are systems in place for internationalisation, it seems
to me that adapting/plugging into those would be a good idea to get to
the text. After all, if the system is flexible enough to load different
texts depending on the language, it's a small step towards "displaying" it
differently when needed. It's a similar problem, and you might want to
have a different, more appropriate text if it's read aloud, for instance.
This way it also doesn't matter if it is a CLI or GUI program.

to post comments

Accessibility in Linux systems

Posted Oct 9, 2008 9:33 UTC (Thu) by jamesh (guest, #1159) [Link] (2 responses)

The point at which a string gets translated for internationalisation is often not the point where you'd want it read by text to speech software or sent to a brail terminal.

For a graphical application, it will usually translate most of its UI strings with gettext() on start up. You'd only want these read when the user tries to interact with those controls. The same probably goes for full screen text mode applications.

Accessibility in Linux systems

Posted Oct 10, 2008 1:46 UTC (Fri) by i3839 (guest, #31386) [Link] (1 responses)

Gah, you're right for how it currently works. I've no experience with internationalisation and I expected something more elaborate than just one function gettext() which is called at startup for each string, for some reason.

Accessibility in Linux systems

Posted Oct 11, 2008 2:49 UTC (Sat) by nix (subscriber, #2304) [Link]

It's not, _() (aka gettext()) is called *when a translation is needed* for
each string (it translates each format string into a new one given the
current locale, possibly reordering arguments in the process). It's just
that GUI applications often need to translate most of their strings in one
big lump at initial-window-mapping time.

Accessibility in Linux systems

Posted Oct 9, 2008 17:53 UTC (Thu) by sthibaul (✭ supporter ✭, #54477) [Link]

It would also be a big work. Internationalization is already a
difficult task just because of finding translators. Finding translators
who _also_ know a bit about accessibility and have an idea on how they
should translate strings is even harder, I'd say "square as much" :)

That's why having a technical solution that just uses what exists is
the most pragmatic solution for now.

That being said, having a different output for sighted and non-sighted
users is not so handy, in particular when you have both kind of users
working together: if they don't have the same output, they will not
understand each other.

Accessibility in Linux systems

Posted Oct 10, 2008 14:12 UTC (Fri) by Cato (guest, #7643) [Link]

It's worth pointing out that there is more to accessibility than screen readers or braille output for the seriously visually impaired. It's also important to support the following:

- mild visual impairments: large fonts and magnification

- for the deaf: visual equivalents of sound effects, and subtitling of videos

- for those with motor/dexterity impairments (including RSI): speech input, alternative input mechanisms (e.g. tongue, foot, blowing), modified input mechanisms (alternative pointing devices)

- for those with speech and language impairments: alternative input/output, communications boards (i.e. use computer to communicate with others interactively through symbols) - inconsistent speech can be a problem for speech input though.

See http://en.wikipedia.org/wiki/Computer_accessibility#Consi... for more complete coverage of this.