Samuel Thibaut est un des membres les plus actifs du groupe Accessibilité. Il a donné plusieurs conférences lors des rencontres mondiales de juillet 2010. Celle-ci en fait partie.
[4]
Retrouvez cette vidéo sur media april [4].
L'aide pour lire cette vidéo est sur cette page [5].
- Conférencier : Samuel Thibault
- Date : 9 juillet 2010
- Langue : Anglais
- Licence de la vidéo : cc-by-sa
Transcription
* Slide 1
Good morning everybody. Thanks for coming early after the meal of yesterday evening. So, my name is Samuel Thibault. I will talk about how to make applications accessible. I've been working on accessibility since 2001 maybe. It took me actually that long time to really understand how everything... I mean, how things should work, or should not work. So I would like to share some of my thoughts, some knowledge about which tools you could use, trying to, in a short period of time, to explain you the general idea.
So my talk is “how to make applications accessible?” or rather “How to make accessible applications”. There is a slight difference between both which I will explain.
* Slide 2
So I will first introduce a bit to accessibility just to have a bit of idea of what you have as handicaps and things like this. Some hardware, some software interfaces, I will not detail on these, because there is a talk in the OS session this afternoon. Then some guidelines about accessibility and the tools that you can use to check accessibility.
* Slide 3
So what is accessibility? It's also known as a11y, that's the usual contraction algorithm, you know internationalization is i18n, because it's the first letter and the last letter and have the number of letters in between. So if you see a11y, that means “accessibility”. So it means making software, well, usable by disabled people, but actually any people.
As you can see, of course the obvious example is blind people, but some people have just... are just... have sight impairments and have a low vision.
Some people are deaf, that can be a problem for games for instance, if you can only hear the enemies coming or something like this.
Colorblind, just curious, in this room, who is colorblind? There is one, two, three, over maybe thirty, so you see it's ten percent. Well, of course we are all geeks so that there are mostly males in the room, and well, female usually are not colorblind, so it's a high representation over the whole population, but it's really something that you shouldn't neglect.
There are people who have only one hand. So they need a special keyboard layout.
Some people can only move one finger. So they would use, like joysticks.
Some people can move just their eye. Just show you quickly the dasher application which can be used by just pointing to something that I want. The principle is that boxes are bigger when it makes a verb. So for instance “hello”... “hello you all”. I just need to find the `l', and then the second `l' is quite big, because after one `l'... after one `a' and one `l' usually you have another `l'.
Cognition. Actually you have to make your software as simple as possible for people that... some people that have problems with understanding software, so just keep it simple.
And also elderly people who have all these problems at the same time, mostly.
To have more details, descriptions about things that can happen to people, there are accessibility howtos which are quite old, like 2002, or so. But everything that is said in them is actually still up to date, I mean in medical terms.
* Slide 4
So I will first talk about hardware.
* Slide 5
So there are a lot of technologies.
Braille input and output, I will detail about it a bit.
Speech synthesis, so to actually let the computer talk.
Joysticks, to basically replace the mouse.
Press button, it's just one button that you press and you have an on-screen keyboard, that shows you which key is about to be pressed when you press the button.
Eye-tracking, actually I've already the dasher application.
* Slide 6
The thing is you should never focus on one technology. Even for a given disability. For instance blind people do not necessarily read braille. For instance people who have become blind quite late, it's too difficult for them to learn it. And also, braille devices are quite expensive, as I will detail a bit. On the other hand, speech synthesis is not perfect either, if you are [cell-phone noise] in a noisy environment [giggles]... or you do not want to use speech, or you are not able to. And also, some people consider that it's quite slow compared to reading braille. Well, some people just use both at the same time or one or the other. And that's just for blind people, some people just have sight impairments and other disabilities and so they would use a mixture of various technologies to actually be able to use a computer.
* Slide 7
So just to detail a bit about braille, so this is, this is a picture of a braille cell, so you can see some bars, some horizontal bars, which are actually piezzo bars, which, which bend when voltage is applied, so that it pushes the dots up and down to form a braille cell. Usually a braille cell is 8 dots, which basically maps to one character if... I'll detail about it in my talk this afternoon.
* Slide 8
So braille devices, just a line of these braille cells, usually 40, but there are smaller like 12, 20, and there are bigger like 80. They are connected through serial, USB, bluetooth, etc. The price is quite expensive. It's approximately 150 times the number of cells you have. This includes all the package around it. The braille, the cells themselves are usually 50€ per cell. But there is all that stuff around, and there was a talk by Mario, the other day, about, well, maybe we could have an open braille device that would cost less.
* Slide 9
So I'm mostly done with hardware, I'll talk a bit more this afternoon.
* Slide 10
About software, there is quite an often idea that, well, let's write software dedicated to some people, for instance edbrowse is a blind-oriented editor and browser. Well, generally it's not really a good idea in that, then you have to maintain the software. And people would like to support javascript, flash, tables, CSS, etc. to benefit from all the webpages that exist, but then they have to do it themselves, or maybe use libraries, it's not really easy. If you want to write some office application, then you have to be compatible with OpenOffice and all these, yes, this means, quite some work. So, it's better to reuse the existing applications and just make them accessible.
There is also something that is quite important is “working together”. When somebody that has some impairments is working on some software and with somebody else which doesn't have any impairment. Well, they have to use the same software, usually, because else they can't work together. And so, just to find out documentation more easily, because documentation on the web or forums are about the mainstream applications.
* Slide 11
In a few words, just to give an idea of how things are going nowadays. Text mode is generally quite well accessible, but beginners consider that it's not really easy to use it. Of course, all the geeks are really happy with text mode, but non-geek people... Gnome starts being accessible, it has started a few years ago. There is still some road to got. It's usable in a professional environment, there are quite a lot of bugs and things like this, but, well, it can really be used nowadays, but we have still some road. We're still late compared to the windows world, because we started way later, in terms of graphical application accessibility. So that's why we just need to catch up.
* Slide 12
So, a bit about the methodology, I will detail more this afternoon, but basically the principle is that usually the application pipeline on the left is, you have an application which uses an abstract representation (buttons, text boxes etc.), and there is a toolkit that makes a visual rendering.
The usual principle is that you have an accessibility bus next to it, which talks with the abstract representation. You have registry which knows. Screen reader can just access the accessibility bus to get the abstract representation of applications, and render this on accessibility devices.
* Slide 13
So, for instance the Linux console accessibility is actually quite trivial in that Linux has those virtual terminals on which you have applications, and you have /dev/vcsa that just provides the text of the text-mode screen. And so brltty which is a screen reader, can just read that file and output the content on the braille device. Of course this is not really an abstract representation, but it's actually the text that is shown on the screen, so it works quite well.
* Slide 14
For graphical applications, you really have to go through the abstraction representation, just because, for instance for gedit, before it goes to the screen, you have the pango layer which is inside the application actually. With gtk as a layer between the application itself and the rendering part, which is pango. And so the accessibility bus is connected to gtk, which has the representation, the abstract representation of the application. And Orca, which is the screen reader, can just fetch the text from that layer, and render it as braille or speech. If it was fetching from between the application and the X server, it would just get pixmaps, and it would have to run some OCR to detect the characters, it's not really convenient. So it just rather peeks information from the gtk layer.
* Slide 15
So, as a summary, as a technical summary, technically speaking a lot of applications are already accessible, so, most console applications are, there are a few exceptions, but mostly it's quite fine. Gtk applications are technically accessible, because they export their internal representation automatically, there is a layer that does that automatically. KDE4 is supposed to be accessible, there is a problem of interconnection with the orca screen reader, there is work, unreleased, it's really soon now since... 4 years or something, well [giggles], all the infrastructure exists, there is just a problem of communication with gnome and KDE people. Well, Adobe made quite good work on Acrobat Reader, it is accessible, they made the effort, it's impressive in that they had to really write it, because Acrobat renders the text itself, it doesn't use GTK, so they really had to say, Ok, I'm rendering this text here on the screen, so I will give a representation of this, for the screen readers.
A lot of applications are not, so KDE3, the Xt applications, the good old ghostscript, xpdf, and things like this, and yes xpdf is not accessible either because it draws the text itself and doesn't expose the text of the pdf on an accessibility bus.
* Slide 16
So, now, in practice, a lot of (technically-speaking) accessible applications actually are not. One of the common pitfall is, you have a mess of widgets in a dialog box. For instance, here, it looks quite simple, you have text fields, that you have to fill, and you have labels for them, and if you do it wrong, you put the labels first, and then the text fields, and there is no connection between the label and the text field, and so the screen reader would first see a lot of labels, and then a lot of text fields, and the user doesn't know which text field correspond to which label. And so that's why screen readers usually have what we call "scripts", to adapt to what, to how the application actually is made, and try to reorganize things. So my talk will be mostly about how to reorganize.
* Slide 17
So, the guidelines is “don't try to make applications accessible, just make accessible applications”. It's... the difference is that you shouldn't try to think “well, yes, my application needs to be readable by a blind person, so I will make efforts to make it accessible by a blind person”, by putting some layers, or trying to render voices yourself and things like this. Just think, well, put some common sense in your development, that is, organize your application logically before actually writing the layout of the application. So it's really something that you should think about from the start. Usually it's just common sense.
* Slide 18
So, for text applications, there are some technical things. Well, basically it works quite great, especially for braille output. One thing I would like to say is “always provide text equivalence of graphical applications, for instance based on the same shared library”. This is actually common sense, writing shared libraries instead of putting the code in the application is usually a good development, way of doing development. And then you will mostly realize, that, yeah, then I can use ssh to a server and run the application there. So it's really common sense to have text equivalence.
There is one thing particular to screen readers on text applications is that the default, well it's also for graphical applications, but it's usually more obvious. The default output of the screen reader is what the cursor is on.
* demo
So, I will just show you a few examples. For instance here I started a screen reader [Can you just zoom the window?] Sorry? [Fonts?] it'll be easier [Affichage]. The thing is, what you should read is at the top of the screen. I hope it's big enough.
Ok. So here I'm at the shell, and I'm typing things. And as soon as, you see on the braille device, it fills the braille device, and when it's completely filled, it actually moves to the next part of the screen. I'll try to add the highlighting, so you can see it more easily. Oh, no it's not implemented here.
For instance, if I use mutt, what we have gotten into mutt is, I think, is using the cursor to just indicate which message is being read.
So, here I kept the cursor active in gnome-terminal, so you can see it's at the end of the line. We got the mutt developers to indeed put the cursor on the line that is currently selected, so that the screen reader actually knows where to go automatically, without having to guess something. There is another example, the mixer here, you have several lines for the mixer. When I switch to the right, to the balance, the cursor moves as well, so it works quite great. And it's
common sense but well, you have to think about it, indeed. So yes, just put the cursor where it should go. There was an example also, the dialog box. So when you switch between the buttons, the cursor also switches, and then it's actually obvious for the user what he is doing.
* Slide 19
For graphical applications, well, the thing is you should just design your application without the graphical stuff in mind first. That is, yes, separate the content from the layout. Just like CSS actually, CSS is really a good thing to make people realize that, first the structure and the content, and then you have all the colors and things like this. So that's a problem with development tools that allow you to just put buttons here and there, randomly, because then the order of the buttons is, as you invented the button, so when you were thinking “maybe I should add one here and there”, and then it's a complete mess.
So, just use the logical order and that should already be quite good. Use standard widgets, so for instance the dialog box I talked about earlier, should be implemented using labeled text fields, that is text fields that have a label on the left or on the right or etc. because then the screen reader knows that they are related together. Avoid homemade widgets, because of course they won't be accessible since you need to talk to the accessibility bus, to export the structure of the widget and the text and things like this. So, well you can implement homemade widgets, but then you have to implement the ATK layer yourself, to make them accessible, to provide the text and structure. Always provide alternative textual content for visual content, so it's the same as the web pages, if you have a picture, or if you have an image on a button instead of text, provide the equivalent text, so that the screen reader know what to speak. Of course people developing screen readers would add the text themselves if they realize that the application doesn't provide it, and then provide a script for this, but it's better that you just provide it from the start.
And the general guideline is “keep it simple”. It's way easier to browse in a simple interface than in something that has a lot of buttons and not organized in a logical order, or separated by panels and things like this. And then you will realize that it's useful for your users too. It's not only, well, there are some users that have cognitive impairments, but also the usual users will be faster to use your application.
* Slide 20
Just a list of common pitfalls and advices. This is actually mostly from the accessibility howto, so I really urge you to have a look at the accessibility development howto.
Everything should be easily doable with either a mouse, or a keyboard. That is, you can, you should be able to just use a mouse and do everything, well, not typing text, there are applications for this, some tools. But all the, tweaking some attributes etc. Or being able to do everything with a keyboard. I would say that windows is really good at keyboard shortcuts, and gnome used to not be so, it's improving, and nowadays it should be good. Some applications are not quite good on keyboard shortcuts. Do improve them, make sure that everything can be done on the keyboard, and it will be very good for accessibility.
Take care of contrasts, some people have just sight impairments so use high contrast, for instance here my slides are blue, not so dark over white, this is right, if I use more light blue, that wouldn't have been right. And well, not only for people who have problems with seeing, but also for every people, actually, if you are not really awake, you prefer high-contrast, because you will be able to read it faster, have to take less brain percentage for this, etc.
And for colorblind people, there are so many different kinds of colorblindness. Just permit color themes, and let the user define them, so that users will just write them for you, and maybe submit them, but just permit it.
Avoid timing-based actions, as that's really a problem on cell-phones for instance, old people have a lot of problems with them, because they hold the key too long, or they are not able to hold the key that long. Or there are timeouts that makes them not have the time to understand what's going on, and then it has cancelled the thing. So really avoid time things, or at least make them configurable, so that you can make them longer or shorter.
Avoid pop-ups, if you have ever worked with somebody who just discovers computers, and is quite old, things that appear on the screen will catch attention a lot, and they will forget what was on the screen before. Well actually it's even some natural thing of human beings of making sure that things that move are not harmful to you, so you check them, and then you almost forget the rest. That's biologically included in our body. So yes, really avoid pop-ups, well sometimes you need, but at least keep them simple.
Yes, the general idea is keep things simple and obvious, it's not only for people who have problems, but also for your users.
* Slide 21
I would like to talk a bit about bugs. First, take high consideration of the suggestions of your users. For instance, there is one thing that blind people ask is bracketed links in text web browsers. That is, just a number in brackets.
It's actually a quick hint that this is a link, and that it's the first link, the third link, etc. it's really useful to quickly browse between links. And so that's a feature that people ask for, and some developers say “no it's not useful”. Well, the user says it _is_ useful to him. At worse, make it an option, so that those users can enable it, and other users don't have that mess of link with bracket number. But take these into considerations, because suggestions are actually, that's precious for the application, I think. Be kind, patient, etc., disabled people, well, sometimes it's very difficult to talk with disabled people, because not only it's not easy for them to use your software because of their impairment, but it's even more difficult for them to explain their problem. For instance, there is one sentence that you could hear is “braille doesn't follow”. And you don't really understand what it is, it's just that for instance here in my text box with “Oui” and “Non” buttons, braille does follow, in that when I switch between buttons, the braille device shows the current button. If the text box wasn't putting the cursor on the appropriate button, braille wouldn't follow, so that's what he means. So, just talk with the user, take the time, it's also probably difficult to even type the mail, to explain, so it's not easy, but take the time.
* Slide 22
Try to keep in mind their disability and their consequences. This is something that I've seen, really difficult for people to always remember about the consequences of disability. So, I think a famous example was, on some debian mailing list, we were talking about starting the frame buffer, for language which needs this in the debian installer, and somebody said “Well, we shouldn't start this for blind users because then they will not be able to check that the framebuffer is properly set up so that it renders on the screen” and... yes, but why? I mean, they don't care. They have the internal representation from the kernel, and if it doesn't show up right on the screen, then right, doesn't matter. Well, it does matter if some sighted person is also next to the blind person, but then that sighted person can say “yes, there is a problem” and will add some parameters. So it was an example, of well, he just forgot about this.
To deal more properly, well, you could even contact your local institutes for disabled people to, for instance, test your applications, with actual people. Or even better, just make friend with them, so that you have plenty of time and beers to talk about things.
* Slide 23
* Slide 24
So, about tools, I won't be very long, so I showed here, I used brltty which provides a virtual braille device, and gnome-terminal which is the only terminal that is accessible actually, at the moment. So there is documentation on my website. My slides are on the LSM website, so you can get the link from there.
* Slide 25
That is accerciser, which is quite nice in that it shows you the internal representation of your application, so for instance it shows that gnome-terminal has a frame with a filler, that has a menu bar, a page tab list, and, well the actual content doesn't show up so maybe there is some problem here with the representation. So just try this on your application, check that the tree of widget looks sane in that it's in the logical order, and it doesn't have mixed things that, for instance, you have things not in proper order, or you have a blank element, and then the actual content is inside, because you didn't have to put some text equivalent for this, and things like this. And that it is complete, for instance, then you will realize for instance, that your homemade widget is not accessible because you can not get information from accerciser.
So you have the tree on the left and you have details on the right, and the console there, you can actually do things by hand.
* Slide 26
So to conclude, accessibility is a concern for really a lot of people. There was a poll on some media, one year ago, I can't remember. A poll for users, they asked users “well, do you have problems with using computers?”. And 10% said “Yes, I have major concerns with using a computer”. That's quite a lot, and in particular that in people who have minor concerns is even more people, it's 20%, so one every 5 person in this room has problems. Be it colorblindness, because then you have some applications you can't distinguish elements. Or just because it's written too small. Here I tried to keep large fonts, but sometimes you wouldn't think about this, and then, some people in back would have problems with [Chair: Actually, go to the point] [Chair: XXX]. So mostly, there are... dealing with accessibility usually boils down to common sense. Taking... well, things into account, but mostly do things logically, and then it will be already great. And you will then realize that it also helps other users which didn't have real problems but they were less fast to use your application.
Thanks.
applaudissements
[Are there any questions?]
[... Web browsers... brackets]
I couldn't hear.
[please ... numbers in brackets]
Yes, I will actually just show it. I think I have the html version of my presentation. So here you have bracketed links, that is before each link there is a number between brackets. So that for instance you know that there are four links, and you always know that, well, this is the first slide, so the first link is “suivant”. The next slide. Then on all the other slides it will always be the third link. And it's written like this so it's quick to remember this.
[What about web applications? Because you only talked about desktop applications. There are more and more ajax, webtools, so.]
So about web applications, I'm really not a specialist of this, so I couldn't really speak for them really. There was an Internet session on Wednesday afternoon I think, which was mostly focused on accessibility. Some of these applications are already accessible in that they provide some text. I think one of the problem, maybe Mario can detail about it, but I think one of the problems is that you might have really a lot of content that is hidden or not hidden, and the way you might try to do it is to put a box over another to hide it, instead of just using the proper “hidden” property of elements. As long as you provide the structure and text and it's logically structured, then it's up to writing the proper software that goes inside the structure and fetch everything, I don't think you need more... Well, of course I'd say the ideal thing is provide an API, a programming API to access the web application, so that people can just write their own client.
[Command line, or...]
Yeah, command-line or... whatever. You can never in advance know which needs users will have, so just provide an API, yes.
[Mario: And if you do so, make sure you're doing through all functionalities, because it's pretty common to design an interface that is like three or four features, but the specification is like 20]
Yeah, I'll just repeat for the microphone, Mario said that please always include all the functionalities in your API, so that you don't have several layers of functionalities depending on whether you're... you have impairments or not.
[Any other questions?... Okay, thanks again.]
applaudissements
Traduction
* Diapo 1
Bonjour à tous. Merci d'être venu si tôt après le repas d'hier soir. Donc je m'appelle Samuel Thibault. Je vais parler de la façon de rendre accessibles des applications. Je travaille sur l'accessibilité depuis environ 2001. J'ai quand même mis du temps à comprendre la façon dont tout... je veux dire dont les choses devraient fonctionner, ou ne devraient pas fonctionner. Donc j'aimerais partager certaines de mes réflexions, quelques connaissances sur les outils que vous pourriez utiliser, en essayant, dans un laps de temps réduit, de vous expliquer l'idée générale.
Donc mon sujet est “comment rendre accessibles des applications?”, ou plutôt “comment écrire des applications accessibles”. Il y a une certaine différence entre les deux que je vais expliquer.
* Diapo 2
Alors je vais tout d'abord commencer par vous présenter un peu l'accessibilité, juste pour avoir une petite idée des handicaps que vous avez et des problèmes du genre. Du matériel, des interfaces logicielles, je ne vais pas détailler tout ça car il y a une conférence sur la session OS cet après-midi. Donc quelques grandes lignes sur l'accessibilité et les outils que vous pouvez utiliser pour vérifier l'accessibilité.
* Diapo 3
Alors qu'est-ce que l'accessibilité ? On la connaît aussi sous le nom d'a11y, c'est l'algorithme habituel d'abréviation, vous savez, l'internationalisation c'est i18n, parce que c'est la première et la dernière lettre et qu'il y a le nombre de lettres entre elles. Donc si vous voyez a11y, ça veut dire “accessibilité”. Donc ça veut dire rendre des logiciels utilisables correctement par, eh bien, des personnes handicapées, mais en fait surtout n'importe qui.
Comme vous pouvez le voir, l'exemple évident est bien sûr les personnes non voyantes, mais des gens n'ont que... ne sont que... déficients visuels et ils ont peu de vue.
Certaines personnes sont sourdes, ça peut poser problème pour les jeux par exemple, si vous pouvez juste entendre les ennemis qui arrivent ou quelque chose comme ça.
Ceux qui ne peuvent pas voir les couleurs, juste par curiosité, qui dans cette salle a ce problème ? Y en a un, deux, trois, sur peut-être 30, donc vous voyez, ça fait dix pour cent. Ok, bien sûr on est tous des geeks, donc il y a surtout des hommes dans cette salle, et les femmes n'ont habituellement pas ce problème, donc c'est une certaine représentation de toute la population mais c'est vraiment un truc que vous ne devriez pas négliger.
Il y a des gens qui n'ont qu'une main. Donc ils ont besoin d'une disposition spéciale du clavier.
Certaines personnes ne peuvent bouger qu'un doigt. Donc ils utiliseraient par exemple des manettes.
Certaines personnes ne peuvent bouger que leurs yeux. Voici rapidement l'application dasher qui peut être utilisée en désignant seulement ce que je veux. Le principe est que les boîtes sont plus grosses quand elles produisent un mot. Donc par exemple, “hello”... “hello you all”. J'ai juste besoin de trouver le `l' puis le deuxième `l' est très gros parce qu'après un `l'... après un `a' et un `l' vous avez en général un deuxième `l'.
Troubles cognitifs. Vous devez rendre votre logiciel le plus simple possible pour les gens qui... certaines personnes ont du mal à comprendre un logiciel, donc faites-le juste simple.
Et les personnes âgées aussi, dont la plupart ont tous ces problèmes en même temps.
Pour avoir plus de détails, de descriptions sur ce qui peut arriver aux gens, il y a des guides pratiques de l'accessibilité qui sont très anciens, comme de 2002 ou autre. Mais tout ce qui y est dit est en fait à jour, je veux dire en termes de médecine.
* Diapo 4
Donc je vais d'abord vous parler du matériel.
* Diapo 5
Alors il y a beaucoup de technologies :
- Entrée et sortie braille, je détaillerai un peu ça.
- Synthèse vocale, donc pour que l'ordinateur parle.
- Manettes, essentiellement pour remplacer la souris.
- Bouton-pressoir, c'est juste un bouton sur lequel vous appuyez et vous avez un clavier à l'écran qui affiche la touche qui va être enfoncée quand vous appuierez sur le bouton.
- Suivi de l'oeil, j'ai déjà parlé de l'application dasher.
* Diapo 6
Le truc c'est que vous ne devriez jamais vous focaliser sur une technologie. Même pour un handicap donné. Par exemple, les personnes aveugles ne lisent pas nécessairement le braille. Par exemple pour les gens qui ont perdu la vue très tard, c'est trop difficile de l'apprendre. En plus les terminaux brailles coûtent très cher, comme je le dirai un peu en détails. D'un autre côté, la synthèse vocale n'est pas parfaite non plus, si vous êtes [bruit d'un téléphone portable] dans un environnement bruyant [rires]... ou si vous ne voulez pas ou ne pouvez pas utiliser la voix. En plus, certaines personnes trouvent que c'est très lent par rapport à la lecture en braille. Bon après certaines personnes utilisent les deux en même temps ou l'une ou l'autre. Et ça c'est pour les personnes non voyantes, certaines personnes sont déficientes visuelles et d'autres handicaps, donc elles utiliseraient un mélange de plusieurs technologies pour pouvoir utiliser un ordinateur.
* Diapo 7
Alors pour approfondir un peu le braille, ça c'est l'image d'une cellule braille, donc vous pouvez voir des barres, des barres horizontales, qui sont en fait des barres piezzo, qui agissent quand on leur envoie une tension, pour élever ou enfoncer les points afin de former une cellule braille. En général une cellule braille fait 8 points, ce qui correspond en général à un caractère si... j'en dirai plus dans ma conférence de cet après-midi.
* Diapo 8
Alors les périphériques braille, c'est juste une ligne de ces cellules braille, en général 40 mais il y en a de plus petites comme 12, 20, et de plus grosses comme 80. Ils sont connectés via le port série, USB, bluetooth etc. Ils coûtent très cher. Environ 150 fois le nombre de cellules dont vous disposez. Ça comprend tout le paquetage qui va avec. Le braille, les cellules elles-mêmes coûtent en général 50€ la cellule. Mais il y a tout ce qui va avec, et il y a eu une conférence de Mario l'autre jour sur... ben peut-être qu'on pourrait avoir un périphérique braille libre qui coûterait moins cher.
* Diapo 9
Bon j'en ai assez dit sur le matériel, je vous en parlerai un peu plus cet après-midi.
* Diapo 10
Concernant les logiciels, il y a une idée courante, ben écrivons des logiciels dédiés à certaines personnes, par exemple edbrowse est un éditeur et un navigateur orienté non-voyants. Ben en général, ce n'est pas vraiment une bonne idée car il faut alors maintenir le logiciel. Et les gens aimeraient le support du javascript, du flash, des tableaux, du CSS, etc. pour profiter de toutes les pages Internet qui existent, mais alors ils doivent le faire eux-mêmes ou peut-être utiliser des bibliothèques. Ce n'est pas vraiment facile. Si vous voulez écrire une application de bureautique,
vous devez être compatible avec OpenOffice et tout ça, oui ça veut dire que c'est beaucoup de travail. Donc il vaut mieux réutiliser les applications existantes et juste les rendre accessibles.
Une chose aussi très importante est le “travail commun”. Quand une personne handicapée travaille avec un logiciel avec quelqu'un d'autre qui n'a pas de handicap. Ben ils doivent utiliser le même logiciel, parce que sinon, ils ne peuvent pas travailler ensemble. Et donc trouver plus facilement de la documentation, car la documentation sur Internet et sur les forums concerne les principales applications.
* Diapo 11
En quelques mots, juste pour vous donner une idée de là où on en est aujourd'hui. Le mode texte est en général très accessible, mais les débutants trouvent que ce n'est pas vraiment facile à utiliser. Bien sûr, tous les geeks sont très contents du mode texte, mais les non geeks... Gnome commence à être accessible, ça a commencé il y a quelques années. Il reste encore du chemin à faire. Il est utilisable dans un environnement professionnel, il y a beaucoup de bogues et des choses comme ça, mais bon on peut vraiment l'utiliser actuellement, mais on a encore du chemin à faire. On est encore en retard par rapport au monde Windows parce qu'on a démarré plus tard, en termes d'accessibilité des applications graphiques. C'est pourquoi il faut juste rattraper le retard.
* Diapo 12
Alors un peu de méthodologie, j'en parlerai plus cet après-midi, mais basiquement, le principe est que en général, le principe d'une application, à gauche est, vous avez une application qui utilise une représentation abstraite (boutons, boîtes de dialogue, etc.), et il y a une bibliothèque qui donne un rendu visuel.
Le principe en général est que vous avez à côté un bus d'accessibilité qui parle avec la représentation abstraite. Vous avez un registre qui sait. Le lecteur d'écran peut alors accéder au bus d'accessibilité pour obtenir la représentation abstraite des applications, et il l'envoie sur des périphériques d'accessibilité.
* Diapo 13
Alors par exemple, l'accessibilité de la console Linux est très simple dans le sens où Linux a des terminaux virtuels sur lesquels vous avez des applications et vous avez /dev/vcsa qui donne simplement le texte de l'écran en mode texte. Et donc brltty qui est un lecteur d'écran, peut simplement lire le fichier et afficher son contenu sur le périphérique braille. Ce n'est pas vraiment une représentation abstraite bien sûr, mais c'est en fait le texte qui est affiché à l'écran, donc ça fonctionne très bien.
* Diapo 14
Pour les applications graphiques, vous devez vraiment vous frotter à la représentation abstraite, tout simplement parce que par exemple pour gedit, avant d'aller sur l'écran, vous avez une couche pango qui est en fait dans l'application. Avec gtk comme couche entre l'application elle-même et la partie affichage, qui est pango. Et donc le bus d'accessibilité se connecte à gtk qui a la représentation, la représentation abstraite de l'application. Et Orca, qui est le lecteur d'écran, peut simplement récupérer le texte à partir de cette couche et l'afficher en braille ou le dire. S'il récupérait ce qu'il y a entre l'application et le serveur X, il n'obtiendrait que des pixmaps et il devrait lancer un OCR pour détecter les caractères, ce n'est pas très pratique. Donc il extrait simplement les informations de la couche gtk.
* Diapo 15
Donc, en bref, en résumé technique, techniquement parlant, beaucoup d'applications sont déjà accessibles. Donc, la plupart des applications en console le sont, il y a quelques exceptions mais la plupart marchent très bien. Les applications gtk sont techniquement accessibles, car elles exportent leur représentation interne automatiquement, il y a une couche qui fait ça automatiquement. KDE4 est censé être accessible, il y a un problème d'interconnexion avec le lecteur d'écran orca, il y a du travail non encore distribué, ça devrait l'être très bientôt... depuis 4 ans ou quelque chose comme ça, enfin [rires] toute l'infrastructure existe, il y a juste un problème de communication entre les gens de gnome et de KDE. Bon Adobe a fait du très bon travail sur Acrobat Reader, il est accessible, ils ont fait un effort, c'est impressionnant parce qu'ils ont vraiment dû l'écrire vu qu'Acrobat affiche le texte même, il n'utilise pas GTK, donc ils ont vraiment dû dire, Ok, J'affiche ce texte-là à l'écran donc je vais en donner la représentation pour les lecteurs d'écran.
Beaucoup d'applications ne le sont pas, alors KDE3, les applications Xt, les bons vieux ghostscript, xpdf et des choses comme ça, et, oui, xpdf n'est pas accessible non plus parce qu'il dessine le texte même et ne présente pas le texte du pdf à un bus d'accessibilité.
* Diapo 16
Alors maintenant, en pratique, beaucoup d'applications techniquement accessibles ne le sont pas en fait. Un des écueils classiques est que vous avez un ensemble d'objets en désordre dans une boîte de dialogue. Par exemple, là, ça a l'air très simple vous avez des zones de texte que vous devez remplir et vous avez des étiquettes pour elles, et si vous ne le faites pas bien, vous mettez d'abord les étiquettes, ensuite les zones de texte, et il n'y a pas de connexion entre l'étiquette et la zone de texte, donc le lecteur d'écran verrait d'abord beaucoup d'étiquettes, ensuite beaucoup de zones de texte, et l'utilisateur ne sait pas à quelle étiquette correspond une zone de texte. Et donc les lecteurs d'écran disposent en général de ce qu'on appelle des "scripts" pour s'adapter à la façon dont est faite une application et elles essaient de réorganiser les choses. Donc ma conférence portera surtout sur la façon de réorganiser les choses.
* Diapo 17
Alors le mot d'ordre est “n'essayez pas de rendre vos applications accessibles, faites juste des applications accessibles”. C'est... la différence est que vous ne devriez pas penser “bon oui mon application a besoin d'être lisible par une personne non voyante, donc je vais faire des efforts pour la rendre accessible à une personne non voyante”, en mettant des couches ou en essayant de la faire parler vous-même ou des choses comme ça. Pensez simplement, ben mettez du bon sens dans votre développement, c'est-à-dire organisez votre application de façon logique avant d'écrire la présentation finale de l'application. Donc c'est vraiment une chose à laquelle vous devriez penser au départ. C'est en général juste du bon sens.
* Diapo 18
Donc pour les applications texte, il y a des trucs techniques. Bon, à la base, ça marche très bien, surtout pour la sortie braille. Une chose que j'aimerais dire est que “fournissez toujours un équivalent texte des applications graphiques, par exemple basée sur la même bibliothèque partagée”. C'est en fait du bon sens, écrire des bibliothèques partagées au lieu de mettre le code dans une application est un bon développement, une bonne manière de faire du développement en général. Et puis vous vous rendrez compte la plupart du temps que oui, ensuite je peux utiliser ssh sur un serveur et y lancer l'application. Donc c'est vraiment du bon sens de fournir un équivalent texte. Une chose particulière pour les lecteurs d'écran dans les applications textes est que par défaut, eh bien c'est vrai aussi pour des applications graphiques, mais c'est en général plus évident. La sortie par défaut du lecteur d'écran est ce qui apparaît là où se trouve le curseur.
*démo
Alors je vais juste vous montrer quelques exemples. Par exemple, là, j'ai démarré un lecteur d'écran [Peux-tu agrandir la fenêtre ?] Pardon ? [Les polices ?] Ça sera plus simple. [Affichage]. En fait ce que vous devriez lire se situe en haut de l'écran. J'espère que c'est assez gros.
Bon donc là je suis sur un shell et j'écris des choses. Et dès que, vous voyez sur le périphérique braille, ça remplit le périphérique braille et quand il est complètement rempli, il se déplace vers la partie suivante de l'écran. Je vais essayer d'ajouter la surbrillance pour que vous puissiez voir plus facilement. Ah non ce n'est pas implémenté ici. Par exemple, si j'utilise mutt, ce qu'on a fait intégrer dans mutt est, je crois, d'utiliser le curseur juste pour indiquer le message qu'on est en train de lire.
Alors ici, j'ai pris le curseur actif dans gnome-terminal, donc vous pouvez voir qu'il est à la fin de la ligne. On a obtenu des développeurs de mutt qu'ils mettent le curseur sur la ligne actuellement sélectionnée, afin que le lecteur d'écran sache automatiquement où aller, sans devoir rien deviner. Il y a un autre exemple, le mixeur là, vous avez plusieurs lignes pour le mixeur. Quand je vais à droite vers la balance, le curseur se déplace aussi, donc ça fonctionne très bien. Et c'est du bon sens mais bon, il faut y penser en effet. Donc oui, mettez juste le curseur là où il devrait aller. Il y avait aussi un autre exemple, la boîte de dialogue. Donc quand vous vous déplacez entre les boutons, le curseur se déplace aussi, et donc c'est évident pour l'utilisateur de voir ce qu'il est en train de faire.
*Diapo 19
Pour les applications graphiques, eh bien en fait vous devriez juste concevoir votre application sans avoir en tête au départ le côté graphique. Oui, c'est-à-dire séparer le fond et la forme. Comme CSS en fait, le CSS est une très bonne chose pour amener les gens à se rendre compte que d'abord il y a la structure et le contenu, ensuite vous avez les couleurs et des choses comme ça. C'est donc un problème avec les outils de développement qui vous permettent juste de mettre des boutons ici et là, au hasard, car vu que vous avez inventé les boutons, donc quand vous vous avez pensé “peut-être que je devrais en rajouter un ici et là”, l'ordre des boutons est alors, bref c'est un désordre total. Utilisez donc juste l'ordre logique et ça devrait déjà être très bien. Utilisez des widgets standards, donc par exemple, pour la boîte de dialogue dont je parlais tout à l'heure, elle devrait implémenter des zones de texte étiquettées, c'est-à-dire des zones de texte qui ont une étiquette à droite ou à gauche ou autre, parce qu'alors, le lecteur d'écran sait qu'elles sont liées les unes aux autres. Évitez les widgets artisanaux parce qu'évidemment, ils ne seront pas accessibles puisqu'il faut parler au bus d'accessibilité, exporter la structure du widget et le texte et des choses comme ça. Donc bon vous pouvez implémenter des widgets artisanaux, mais vous devez alors vous-même implémenter la couche ATK pour les rendre accessibles, pour fournir le texte et la structure. Donnez toujours un contenu textuel alternatif à votre contenu visuel, c'est la même chose que les pages Web, si vous avez une image ou si vous avez une image au lieu d'un texte sur un bouton, donnez l'équivalent texte, pour que le lecteur d'écran sache quoi dire. Bien sûr, les gens qui développent des lecteurs d'écran ajouteraient eux-mêmes le texte s'ils s'aperçoivent que l'application ne le donne pas, puis ils fourniraient un script pour ça, mais c'est bien mieux que vous le fournissiez au départ. Et le mot d'ordre en général est “faites simple”. C'est plus facile de naviguer dans une interface simple plutôt que dans un truc avec beaucoup de boutons et qui n'est pas rangé dans un ordre logique, ou séparé par des cadres ou des choses comme ça. Et alors vous réaliserez que c'est utile aussi pour vos utilisateurs. Ce n'est pas seulement, bon il y a des utilisateurs qui sont handicapés mentaux, mais même les utilisateurs ordinaires utiliseront plus vite votre application.
* Diapo 20
Juste une liste des pièges et conseils courants. C'est essentiellement extrait de l'howto de l'accessibilité, donc je vous encourage à jeter un oeil au howto du développement de l'accessibilité.
Tout devrait être facilement faisable, que ce soit avec une souris ou avec un clavier. C'est-à-dire, vous pouvez, vous devez être capable de tout faire en utilisant seulement une souris, bon, pas taper du texte, il y a des applications pour cela, des outils. Mais tous les, ajustements de certains paramètres, etc. Ou être capable de tout faire avec un clavier. Je voudrais dire que Windows est vraiment très bon en raccourcis claviers, et Gnome ne l'est pas autant, il s'améliore, et de nos jours il devrait être bon. Certaines applications ne sont pas très bonnes au niveau des raccourcis clavier. Améliorez-les, assurez-vous que tout peut être fait au clavier, et ce sera très bien pour l'accessibilité.
Soignez les contrastes, certaines personnes ont seulement des difficultés visuelles alors utilisez des contrastes élevés ; par exemple, ici mes diapo sont bleues, pas trop foncé sur du blanc, c'est bien, si j'utilisais un bleu plus clair, ça ne serait pas bon. Et bien, pas seulement pour les gens qui ont des problèmes de vue, mais aussi pour tout le monde, en fait, si vous n'êtes pas vraiment réveillé, vous préférez les contrastes élevés, parce que vous serez capables de lire plus vite, vous devez utiliser moins de votre cerveau pour ceci, etc.
Et pour les personnes daltoniennes, il y a tellement de sortes de daltonismes. Permettez simplement des thèmes de couleurs, et laissez l'utilisateur les définir, ainsi les utilisateurs les écriront pour vous, et peut-être qu'ils vous les soumettront, mais permettez-les.
Évitez les actions temporisées, parce que c'est vraiment un problème pour les téléphones mobiles par exemple, les personnes âgées ont beaucoup de problèmes avec les téléphones, car ils appuient trop longtemps sur les touches, ou ils ne sont pas capables de presser la touche assez longtemps. Ou il y a des comptes-à-rebours qui fait qu'ils n'ont pas le temps de comprendre ce qu'il se passe, et alors ça annule la chose. Alors évitez vraiment les choses basées sur le temps, ou au moins rendez-les configurables, pour qu'il soit possible de les allonger ou de les réduire.
Évitez les pop-up, si vous avez déjà travaillé avec quelqu'un qui découvre les ordinateurs, et qui est plutôt âgé, les choses qui apparaissent sur l'écran vont énormément attirer son attention, et ils vont oublier ce qui était à l'écran avant. En fait, c'est même une chose naturelle pour les êtres humains que de s'assurer que les choses qui bougent ne sont pas dangereuses pour eux, donc vous les vérifiez, et alors vous oubliez presque tout le reste. C'est biologiquement inclus dans votre corps. Donc oui, évitez vraiment les pop-up, bon parfois il en faut, mais alors gardez les simples.
Oui, l'idée générale est de garder les choses simples et évidentes, pas seulement pour les gens qui ont des problèmes, mais aussi pour vos utilisateurs.
* Diapo 21
Je voudrais un peu parler des bugs. Premièrement, prenez en haute considération les suggestions de vos utilisateurs. Par exemple, il y a une chose que les non-voyants demandent c'est les liens entre crochets dans les navigateurs web textuels. C'est-à-dire, juste un nombre entre crochets. C'est en fait une indication rapide signalant que c'est un lien, et ceci est le premier lien, le troisième lien, etc. C'est vraiment utile pour naviguer rapidement entre les liens. Et donc c'est une fonctionnalité que les gens demandent, et certains développeurs disent "non ce n'est pas utile". Eh bien, l'utilisateur dit c'_est_ utile pour lui. Au pire, faites en une option, afin que ces utilisateurs puissent l'activer, et que les autres utilisateurs n'aient pas cette pagaille de liens avec des nombres entre crochets. Mais prenez-les en considération, parce que les suggestions sont effectives, elles sont précieuses pour l'application, je pense. Soyez gentil, patient, etc., les personnes infirmes, eh bien, parfois c'est très difficile de parler avec des infirmes, parce que non seulement ce n'est pas facile pour eux d'utiliser des logiciels en raison de leur infirmité, mais aussi c'est encore plus difficile pour eux d'expliquer leur problème. Par exemple, il y a une phrase que vous pouvez entendre qui est "le braille ne suis pas". Et vous ne pouvez pas vraiment comprendre de quoi il s'agit, c'est juste que par exemple, ici dans ma boîte de dialogue avec les boutons "oui" et "non", le braille suit, en ce sens que quand je change de bouton, l'appareil braille montre le bouton actuel. Si la boîte de dialogue n'avait pas mis le curseur sur le bon bouton, le braille n'aurait pas suivi, c'est donc ce que ça veut dire. Donc, parlez simplement avec eux, prenez le temps, c'est probablement même difficile d'écrire un e-mail, pour expliquer, donc ce n'est pas si facile, mais prenez le temps.
* Diapo 22
Essayez de garder à l'esprit leur infirmité et ses conséquences. C'est quelque chose que j'ai vu, vraiment difficile pour les gens de toujours se souvenir des conséquences de l'infirmité. Donc, je pense qu'un exemple fameux était, sur une liste de diffusion Debian, nous parlions de démarrer le ''framebuffer'', pour des langues qui le nécessitent dans l'installeur Debian, et quelqu'un a dit "Bon, on ne devrait pas démarrer cela pour les utilisateurs aveugles parce qu'alors ils ne seraient pas capables de vérifier que le ''framebuffer'' est correctement paramétré pour que le résultat soit rendu sur l'écran" et... oui, mais pourquoi ? Je veux dire, ils s'en moquent. Ils ont la représentation interne à partir du noyau, et si cela ne s'affiche pas correctement à l'écran, alors pas de problème, ça ne gène pas. Bien, ça dérange si une personne voyante est également à côté de la personne non-voyante, mais alors cette personne voyante pourra dire "oui, il y a un problème" et ajoutera des paramètres. Donc c'était un exemple, eh bien, il a juste oublié ceci. Pour s'en occuper plus précisément, eh bien, vous pouvez même contacter vos instituts locaux pour personnes infirmes pour, par exemple, tester vos applications, avec réellement des personnes. Ou encore mieux, soyez amis avec eux, ainsi vous aurez plein de temps et de bières pour parler des choses.
* Diapo 23
* Diapo 24
Donc, à propos des outils, je ne serai pas très long, donc j'ai montré ici, j'ai utilisé ''brltty'' qui fournit un outil de braille virtuel, et ''gnome-terminal'' qui est le le seul terminal réellement accessible pour l'instant. Donc il y a de la documentations sur mon site web. Mes diapo sont sur le site de LSM, donc vous pouvez avoir le lien depuis là-bas.
* Diapo 25
Voici ''accerciser'', qui est plutôt sympa dans le sens où il montre la représentation interne de votre application, donc par exemple il montre que ''gnome-terminal'' a un cadre avec un remplissage, qui a une barre de menu, une liste des onglets de page, et, bon le contenu actuel ne s'affiche pas donc il y a peut-être un problème ici dans la représentation. Donc, essayez juste ceci sur votre application, vérifiez que l'arbre de widgets paraisse sain au sens où il est dans l'ordre logique, et qu'il n'ait pas mélangé les choses que, par exemple, vous avez des choses dans un ordre inapproprié, ou vous avez des éléments vides, et alors le contenu actuel est dedans, parce que vous n'avez pas eu à remplir de texte équivalent à ceci, et d'autres choses du même genre. Et que c'est complet, par exemple, alors vous allez réaliser par exemple, que votre widget maison n'est pas accessible parce que vous ne pouvez pas obtenir les informations depuis ''accerciser''. Donc vous avez l'arbre sur la gauche et les détails sur la droite, et la console là-bas, vous pouvez réellement faire les choses à la main.
* Diapo 26
Donc pour conclure, l'accessibilité est une préoccupation pour vraiment beaucoup de personnes. Il y a eu un sondage dans un média l'année dernière, je ne me souviens plus. Un sondage pour les utilisateurs, il leur était demandé "eh bien, avez-vous des problèmes en utilisant un ordinateur ?". Et 10% ont répondu "Oui, j'ai de grosses difficultés à utiliser un ordinateur". C'est plutôt beaucoup, et en particulier les gens qui ont des difficultés mineures sont encore plus nombreux, ils sont 20%, ainsi une personne sur 5 dans cette pièce a des problèmes. Qu'il s'agisse de daltonisme, parce qu'il existe certaines applications pour lesquelles vous ne pouvez pas distinguer des éléments. Ou juste parce que c'est écrit trop petit. Ici j'ai essayé de garder une grande police de caractère, mais parfois vous pouvez ne pas y penser, et alors, certaines personnes au fond pourraient avoir des difficultés avec [Présentateur : va au fait] [Présentateur : XXX] Donc principalement, il y a... s'occuper de l'accessibilité ça revient souvent au bon sens. Prenant... ainsi, les choses en compte, mais la plupart du temps faire les choses logiquement, et alors ce sera déjà bien. Et vous réaliserez alors que ça aide aussi d'autres utilisateurs qui n'avaient pas de réels problèmes mais qui étaient moins rapides pour utiliser votre application.
Merci.
applaudissements
Y a-t il des questions ?
Je n'ai pas entendu.
[s'il vous plait ... les nombres entre crochets]
Oui, je vais en fait vous le montrer. Je pense que j'ai la version html de ma présentation. Donc ici vous avez des liens entre crochets, c'est-à-dire que vous avez devant chaque lien un nombre entre crochets. Ainsi par exemple vous savez qu'il y a quatre liens, et vous le saurez toujours, bien, c'est la première diapo de la présentation, donc le premier lien est "suivant". La diapo suivante. Maintenant, sur toutes les autres diapo, ce sera toujours le troisième lien. Et c'est écrit comme ça, donc c'est rapide pour s'en rappeler.
[Et à propos des applications web ? Parce que vous avez seulement parlé des applications de bureau. Il y a de plus en plus d'ajax, d'outils web, alors.]
Donc, à propos des applications web, je n'en suis vraiment pas un spécialiste, donc je ne pourrai pas vraiment en parler réellement. Il y a eu une session Internet jeudi après-midi je crois, qui était principalement centrée sur l'accessibilité. Certaines de ces applications sont déjà accessibles dans le sens où elle fournissent du texte. Je pense qu'un des problèmes, peut-être que Mario peut le détailler, mais je pense qu'un des problèmes est qu'il peut y avoir vraiment beaucoup de contenus qui sont cachés ou non, et la façon que vous pourriez essayer est de mettre une boîte par-dessus une autre pour la cacher, au lieu de simplement utiliser la propriété appropriée "caché" des éléments. Tant que vous alimentez la structure et le texte et que c'est logiquement structuré, ensuite il ne reste qu'à écrire le logiciel approprié qui rentrera dans la structure et récupèrera tout, je ne pense pas que vous ayez besoin d'en faire plus. Bon, bien sûr je dirais que l'idéal est de fournir une API, une API de programmation pour accéder à l'application web, afin que les gens puissent écrire leur propre client. [Ligne de commande, ou...] Oui, ligne de commande ou... peu importe. Vous ne pouvez jamais savoir à l'avance quels besoins auront les utilisateurs, donc fournissez leur juste une API, oui. [Mario : et si vous le faites, assurez-vous que vous le faites pour toutes les fonctionnalités, car c'est assez courant de concevoir une interface qui a trois ou quatre fonctionnalités, mais les spécifications en comptent 20] Oui, je le répète au micro, Mario a dit de toujours inclure toutes les fonctionnalités dans votre API s'il vous plait, afin de ne pas vous retrouver avec plusieurs couches de fonctionalités dépendant de si vous êtes...vous avez des déficiences ou non.
D'autres questions ? ... Ok, merci encore
applaudissements