libreplanet-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] libreplanet-discuss Digest, Vol 70, Issue 14 F


From: arthur_torrey
Subject: Re: [libreplanet-discuss] libreplanet-discuss Digest, Vol 70, Issue 14 FS & Disabilities
Date: Tue, 15 Dec 2015 02:28:57 +0000 (UTC)

Speaking as a person with a disability, though fortunately not one that affects 
my ability to use software, it seems to me that this is a prime area where the 
classic Unix mantra of "don't do all things, instead do individual things well 
and string them together" is really the way to go...  

While disabilities vary greatly in their effects on people's ability to use 
software / computers, it is a pretty safe assumption that a problem with one 
sort of software is going to apply to all of it, and that there are some 
relatively broad categories of issues that almost ALL fall into the category of 
Input / Output...  (IMHO it is not really practical to address cognitive 
issues....)

People with visual impairments will need some form of display modification, be 
it larger images, different color schemes, screen readers, etc...

Similarly people with motor function issues need alternative input methods - 
replacements for mice, keyboard alternatives, possibly gaze-tracking, and so 
on...

In each case, what the developer of a software program really needs is NOT to 
address any of the above, but simply to provide a (hopefully standardized) way 
of supporting alternative I/O methods.

Then what is needed (and I believe exists to at least some degree) is a set of 
alternative I/O 'driver programs' that can be connected and used just as one 
would the normal programs - i.e. a 'gaze tracker keyboard' device, or a 
'screen-reader-monitor'...

IMNSHO it should NOT be on the typical developers plates to solve the problems 
of disability access, as they might or might not have a good idea of how to 
design for it, or have access to suitable 'testers'...  In addition if each 
program developer team tries to solve the problems independently then you end 
up with a bunch of different interfaces which causes extra challenges...

As I can barely write Arduino code, I can't volunteer to help, but I'd really 
urge that efforts be focused on making really GOOD alternative I/O drivers, and 
then just getting program devs to implement connecting to them.

I am told that the commercial outfits are in some ways ahead of us in terms of 
accessibility design, but that because many of the programs are very 
application specific, they limit their users to only certain applications....

ART
------------------
Arthur Torrey - <arthur_torrey@comcast.net>
-------------------



<SNIP>

There was some discussion about this on a FOSDEM list recently. 
Somebody expressed an opinion that if software doesn't support users
with disabilities then the developers are discriminating against those
people.

It is not so simple though.  Developers don't actively discriminate, we
simply don't have time to do everything we would like to do if time and
money were unlimited.

One thing we should be more conscious of is that there are funding
programs and grants available to make the world better for people with
disabilities.  It would be very interesting to try and ensure that some
of that money is going to free software rather than proprietary
software.  Developers don't typically have a disposition for filling out
application forms so if there are other volunteers who would like to
help look for such programs and match them to relevant free software
projects and help with paperwork it could give interesting results and
it may indirectly benefit other parts of the free software ecosystem.

Regards,

Daniel




------------------------------

_______________________________________________
libreplanet-discuss mailing list
libreplanet-discuss@libreplanet.org
https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss


End of libreplanet-discuss Digest, Vol 70, Issue 14
***************************************************




reply via email to

[Prev in Thread] Current Thread [Next in Thread]