Re: [Audio-video] http://audio-video.gnu.org/video/ghm2013/Samuel_Thibault_Jean-Philippe_Mengual-Freedom_0_for_everybody_really_.text

[MENGUAL Jean-Philippe]

Hi Richard,

First of all, after all I read, I'd like to tell you "thanks" myself 
too, because Your accessibility is amazing and appreciated. Then, I try 
to write "short" but it's somewhat long to discuss all you could write 
in the thread which created questions in I, in a single mail.

I would like to go on discussion about some points that I don't 
understand yet well. In particular, to explain why, for me, 
accessibility isn't a functionality. Because a functionality is a task 
that can do a program (or not do). In this meaning, as you mentioned,  
the capacity to vocalize the screen is a functionality.
However, "making the software compatible the assistive technologies" is 
a METHOD, yes, but not to implement these functionalities in a given 
program. It's a way of code it so that any "outside" "third-party" 
technology can interact with it. It is a quality matter, as the fact the 
code must be understandable. If an editor application has not a feature, 
such as create a PDF file, this missing feature does not exclude any 
user, because other features are available for everyone. However, if the 
editor code has not mind (API, clean code) related to accessibility, it 
fully will not be usable by some users due to their physical or 
cognitive impairment. That's 9hy accessibility is, I think, transversal.
I could explain this in other words: when a functionality is missing, 
you can perform a task with a different way or use the program in 
another way. When accessibility is missing, I cannot do anything.
Examples: I don't speak English, the soft is in English, so I can learn 
English (skill limitation). If something only works on a computer, I can 
buy a computer (financial limitation). If a dev refuses modifications 
from an external dev and doesn't want accessibility to be a priority, 
nothing is possible. This distinction is essential. Because indeed, we 
cannot say "ship a magnifier" or "ship a speech synthetiser" in every 
program. It's not wise to say "implement a method to enable your program 
to speak, display braille". It's much wiser asking to software to have a 
"understandable" code is something included, if I do not mistake, in the 
Freedom 0. Here, I think we could add that this code should be "clean" 
enough so that the accessibility bus can, once coded to connect to it, 
fetching useful information to give to the assistive technology. For me, 
it's the "global" message to the free software developpers that we could 
promote together: work for accessibility if you like, but to be really 
usable for everybody and to enable everybody to have freedom to run it, 
make an accessible code, that is, a code that every one can use usefully.
This approach is essential: take the example of any way, a frontier for 
instance. If you say "frontier is opened" but no way to access to it by 
bike, walking or car or other ways, is it opened? If European Union 
decided to impose to States to take measures to help exchanges between 
them, it's because it was clear that affirming a freedom, asking "not 
do", without never asking "co", doesn't work. Saying "you're free to 
exchange" is cool, but if no way is implemented to help these exchanges, 
nothing will exchange.
That is exactly why I think we cannot reduce accessibility to a 
functionality. Assisti(e technologies, as you say, are specific and yes, 
State should support them. But it's impossible to support ALL software 
accessibility if their author do not the effort. Typically, Orca will do 
any efforts, it will be so hard if all the widgets of a toolkit are 
disordered and impossible to be analyzed by a screen reader.

Subsequently, when a program isn't accessible, the community could help 
the developper to make it usable by specialized technology, and 
considering that its sociey role isn't fully accomplished, otherwise.
If a program is not accessible, and if patches sent by few contributors 
are not used, it's difficult to say "better late than never", because 
practically, it's never. Why? because the program changes, the code too, 
the patch becomes deprecated, and even the effort to make a software 
accessible is disappointing and useless. All the more as practically, an 
app is never re-written "in the second time". First, because some 
projects are too big and miss developpers to do it. Secondly, because 
devs prefer adding new features instead of improving or optimizing. 
Thus, they always consider accessibility for "to be done as soon as I've 
time". And, of course, they've never time. It results it's never a 
priority and that if they are not in front of consequences of this, the 
program never improves his code or is improved by few people.

And if it doesn't seem a disaster, it can become one in some 
circumstances. 1st, when French State chooses LibreOffice and refuses to 
use another thing, it prevents many people to work for it due to 
inaccessibility of the suite. When Firefox isn't accessible, users 
cannot do a lot of things which are mandatory is the modern society. Of 
course, some specific software can difficultly be accessible and it's 
not a disaster, but for most used and friendly software, yes it is a 
disaster (and it will become more and more a disaster in societies where 
computing has a major place and people are more and more old and need 
computing despite physical problems).

What's your feeling about this 3 ideas, in particular, the 2 first ones. 
I really would like to understand our respective approach of 
accessibility is not a functionality (mine) and yours.

Best regards,



Le 20/07/2014 03:11, Richard Stallman a écrit :[[[ To any NSA and FBI 
agents reading my email: please consider ]]] [[[ whether defending the 
US Constitution against all enemies, ]]] [[[ foreign or domestic, 
requires you to follow Snowden's example. ]]] 1. Richard, what do you 
mean when you say that "accessibility is a functionality"? 
"Functionality" refers to the useful things that a program does when it 
runs. For instance, if it is a C compiler, that is a functionality. If 
the C compiler handles C89, that's a (more specific) functionality. If 
it implements alloca, that's an (even more specific) functionality. If a 
program can communicate with a screen reader, that's also a 
functionality. Thus, each specific feature that contributes to 
accessibility is a functionality. If I cannot run Evolution (Gnome), I 
am unable to debug, use, study and modify it. Why? Because I have not 
all my physical potential. Does it seem ethical for you? The question is 
misconceived, because this problem is mainly due to your being blind, 
and (except in special cases) nobody is to blame for that. I think it is 
a damned shame that you are blind. I think the government should spend 
our money on work to make things easier for blind people. This can 
include improving free software for the sake of blind users. But your 
blindness does not make you ethically entitled to order a specific 
person do specific work to help you out. 3. You are afraid, when you 
hear "Freedom 0 could ship accessibility", What you have said is, 
"Accessibility is a part of freedom 0." That is a dreadful mistake and 
compels me to oppose your activities. a) When we promote a11y for devs, 
we do not tell them "know all disabilities and make your software 
accessible". We explain rather that, if a program is developped 
properly, it can present all info needed by accessibility pipe That 
practical activity we would be glad to support -- if only you drop the 
broader philosophical statement that distorts the idea of freedom. We 
only want to give a stronger message, with more consequences, If what 
really matters to you is a stronger impetus for making free programs 
accessible, the FSF would gladly join you in supporting that, if you 
stop confusing the idea of freedom.

--

Jean-Philippe MENGUAL

accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels

Mail:address@hidden

Site Web:http://www.accelibreinfo.eu