Mechanisms for accessibility

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.

Retrouvez ce fichier audio sur media april.

L'aide pour lire ce fichier audio est sur cette page.

  • Conférencier : Samuel Thibault
  • Date : 9 juillet 2010
  • Langue : Anglais
  • Licence de la vidéo : cc-by-sa

Transcription

* Slide 1

Ok, so... Good afternoon, my name is Samuel Thibault, I will talk about mechanisms for accessibility. So, it's something that is not very well known from an operating system point of view. So I will detail things like how to access the screen, etc.

* Slide 2

So the outline will be... I will first introduce a bit about accessibility, because probably you don't know much about that topic. Then, detail a bit about the hardware, which hardware we can use. Then I will detail a lot software parts, so the layers and intefaces that are used for accessibility. And finaly I will talk about how to bootstrap, which is almost a design and user interface problem, but also an operating system problem.

* Slide 3

So, first, what is accessibility? It's also called "a11y", so it's the usual contraction, you know, i18n for internationalization, it's because it starts with an i and finishes with an n, and then you have 18 letters in between, and a11y is the same, it's accessibility. So, that means making software usable by, well, disabled people, but actually, anybody on earth.

So, the obvious people who are concerned are blind people, but there are a lot of other disabilities, like people who have sight impairements, and not necessarily completely blind, but some problems.

Some people who are deaf, so for instance games which rely on being able to hear what is happening to not get killed is a problem.

Colorblind, it's probably not well known, how many people, well, how is colorblind in this room? There is nobody, that's really strange: there is 8% of male people who are colorblind, so that's quite a lot actually. Women are fortunate that they are not much affected by this.

Some people just have one hand, and so the usual keyboard is not really suited to that, so what they do is use a special layout which has a toggle key, so that when they toggle, they actually have the other half of the keyboard and the finger. So they don't have to move the hand from the left part to the right part and vice-versa, they just need to toggle to get the other half of the keyboard.

Finger-handed, so some people just... are just able to move a finger or something similar to a finger. They would use joysticks to, like, use a mouse, but with a joystick.

Eye-handed people, so I will just show a bit about dasher, so I have the mouse here, which actually follows my eye, and I can quite easily type things by just looking at letters. For instance, Hello... I'm looking for the comma... sorry, I can't find it... Here it is... And what you see is that the word, for instance here you see "you", y-o-u, quite clearly, because statistically, in the English language, when you start with a y, often you want to put an o right after that, so you actually see the words forming, it's really a fun thing. And it's quite efficient for typing things.

Cognition. Some people even say that it's a bit of a taboo, but there are of course a lot of problems with cognition. Be it, well, you're a bit lost in an interface with a lot of buttons and things like this. Or you just can not read what is on the screen, and so you need images to be able to use software.

And, elderly people, who have, well a bit of everything that is above. So of course it's difficult for them.

I really invite you to have a look at the accessibility howtos because they have quite a lot of details, descriptions of different kinds of disabilities and solutions for these. It's quite old, like 2002, but it's still quite accurate, things haven't really changed since then, in that regard.

* Slide 4

So, let's talk about hardware, well, there was a talk about how to make a free braille device the other day, by Mario Lang. I will just detail on the hardware itself.

* Slide 5

So of course there is braille input and output for blind people. Some other people like speech synthesis. You can use joysticks, which can basically replace the mouse, so there is not much to say about it. Press buttons are interesting in that you have a virtual keyboard on the screen, and with the press button you can, with some timing, you press the button to scroll the rows of the keyboard, and then stop to say "I select that row", and then the columns are scrolling, and then you stop with another click, and then you can validate to say "yes, it's this key that I want to press". It's quite slow. With an adaptive on-screen keyboard which just shows the important parts of what is shown on the screen on the virtual keyboard, you can be quite efficient, but it's a bit hard, but yes it makes it possible to really do a lot of things with really small capabilities. Eye tracking, I've talked about it and shown the dasher.

* Slide 6

One important thing to understand is that there is no one technology that's perfect. Braille is not perfect in that there is a lot of people who can't read braille, especially when they got blind while being old, they can not make the effort to learn this. Or they just can't feel it with their fingers. Braille devices are really expensive, I will detail a bit about it. Speech synthesis itself can replace braille, but it's not perfect either, you might be in a train, or in the tram. It's also sometimes considered as slow, compared to braille, there is also a problem of accuracy. With braille you can quickly check, for instance when you are coding, the opening braces, parentheses. With speech synthesis it's a bit difficult, it's a burden.

* Slide 7

So I will focus a bit on braille. This is a braille cell, it uses the piezo effect, that is, you have these bars which can actually bend when you apply some voltage, so they push or lower dots that are above it, and that way with 8 piezo bars and 8 bars you can actually form what we call a braille pattern, so 8 dots, which basically is like one character, I will detail a bit more about it later.

* Slide 8

So, braille devices is just a collection of these cells, like 40 or 20 cells, they can be connected to a PC, a standard PC via serial, USB, or bluetooth. The thing is, the price, when you look at the market, is like 150 times the number of cells euros. That means that, no I don't have the slides for this. A standard 40 cells braille display is like 5000€, which is way more expensive than the laptop you actually run software on. So that's why we had a talk about a free braille device to try to cut that price a bit.

* Slide 9

About braille, I'd like to desccribe a bit because it's really not well-known, generally speaking. So, you have 8 dots, that means 256 patterns only, two power 8. The thing is, only the letters from a to z are world-standard, there are even exceptions, for instance in vietnamese for the d letter. The rest depends on the language, so for instance ':' is not the same in US and in French. Yeah, in English and in French. So when you are given for instance a card with something printed in braille, you may not even be able to read it, just because you don't know US braille or things like this. It also depends on the country, it has now converged, but the French Belgium, the French Canadian and the French French braille were a bit diverse before, so it was a bit of a mess, and it also depends on the usage. Because actually the French braille changed a few times like in 1998, and 2007, something like this, so there are some old people who know the old version, young people who know the new version, and it's a bit of a mess. Some devices have their own table, so that the user is used to that table and not the official country table. And also there is quite a few problems with multi-language documents. A French person would prefer to read English with a French table, because it's used to see colons with the French table, but for Japanese on the other hand, well he would need the Japanese table, because there is not Japanese encoding in French.

* Slide 10

So, now, to get a bit more precise by what we mean for a "braille table". There are two levels, basically. So you have grade 0, which is also called integral, litteral, well, the principle is that each cell codes for one character. So you actually have a bijection between the character and the cell, which makes things really simple. In particular, when you have an 8bit charset, it's merely a bijection between the charset you are using and the space of braille patterns. So for instance I showed 'A', 'B', 'C', and quotes. But then, when you are moving to unicode and have several languages in the same document, well you have ambiguity, and that's not a solvable problem without some markes to say "well now this is English, now this is French", etc. Now, you have a second level, which is grade 1 or 2, it's also called abbreviated or contracted. It's actually like when you are writing with latin letters, usual, for instance, suffixes, are contracted in just a few cells, so you see ation which is a common suffix of English words, is contracted into just these two cells. The problem of course is that, then you have ambiguity, this "ation" suffix is then coded the same way as capital 'N'. But it was chosen in a way that it's usually not a problem, and of course these rules depend a lot on the language and practice.

* Slide 11

So, that was for the hardware. Let's talk about software.

* Slide 12

I just want to talk a bit about dedicated software. For instance there is edbrowse, which is a browser for blind people. Well, generally I think it's not a good idea, because edbrowse started to implement javascript, it surely doesn't implement flash, I guess it supports tables, css is probably probably not supported. Well, you can not do everything yourself, you should really reuse just what is existing. Another example an office suite would need OpenOffice compatibility, but well you don't want to write code to read an OpenOffice document, etc. Another reason to just use the existing applications is working together. When you are blind, you usually work with non-blind people, and when you are working with them, you are next to each other on the computer, and so it's better to just use the same software, so you understand each other. And also, to get information and documentation, you have a lot more documentation on OpenOffice to do this and that, than edbrowse, so it's probably, it makes more sense to use what exists.

* Slide 13

Now the problem is, how to make it accessible. So, first, I would like to make a quick summary of the current state. Text mode is generally quite well accessible, in that it's just text and so you can render it, it's not so much a problem. But all beginners would say "it's not easy to use", "I don't want to learn all these commands", so they would rather use Gnome, which starts being accessible. It started like a decade ago, a bit less than that, but there is still a long road to go, particularly compared to the windows world, which started decades ago, and which is, yeah, much more advanced than what we have in Linux. That being said, the current state is really that you can use the Gnome desktop, at work, for instance to work with people working on OpenOffice documents and all this. It can be better, but it's already quite usable.

* Slide 14

So, now, about the mechanism for, say gnome accessibility, the general principle is that, well, you have the usual pipeline starting from the application, you have an abstract representation of the application things that should appear on the screen, and then you have visual rendering. What accessibility does is just adding something along the abstract representation, so that there is a registry to know the list of applications which are here, and a screen reader can access to the abstract representation of each application, and then, render this on any kind of accessibility device you might want, be it braille, speech, or any other thin.

* Slide 15

So, for instance, in the case of Linux, it's quite simple: so you have Linux with the virtual consoles, you have several applications running on VT1, VT2, VT3, and what Linux provides, and it was, I think, really meant for accessibility, /dev/vcsa which just basically provides the text, that's all, and that's all we need actually for text mode things, and then brltty is the screen reader whichs that, and then uses some drivers to show this on the braille device.

* Slide 16

There is one additional thing about, when the braille device has a braille keyboard, you want to simulate the effect of the keypress in Linux, just like you had pressed on the real PC keyboard. That is done via some ioctl on the virtual terminal device, to it's called TIOCSTI, it's a long story I guess. Or you can use the uinput module of Linux to actually make like you have a fake keyboard, and you write the key. The interesting thing is that the ioctl way needs a string, while the uinput way needs a key number. The huge difference is that here ['ioctl'] the key has been translated already, so this is really an 'a' that the application will get, while there, the uinput way, you have key 'a' which means "the key that is labeled a on a qwerty keyboard". So if you have an azerty keyboard, actually after the uinput module, it will get translated into 'q' if the keyboard is azerty. This is actually needed when the user has an azerty keyboard on his device, or whatever. That's something we added quite recently actually.

* Slide 17

Another way to achieve similar things is to use ptys, so you have a ty at the top, which can be a linux virtual console, or an xterm, whatever, and you start yasr (which means "yet another screen reader"), which starts a pseudo-tty, in which the real application can run, and so basically yasr acts as a filter, it just copies in both ways, but gets the text along this, and can then use speech, so it's quite portable, but then it has to interpret everything, that means all the tty escapes and things like this.

* Slide 18

The question, then, when you have text, then you have a big matrix of text, is "what to show?". Well, what people do, usually, in screen readers, is showing what the cursor is on, so it works quite great with a shell for instance. So here, I have a shell, so when I'm typing, the braille device is actually following what's happening, so see, I'm at the end of the braille line, and then it switches to the next part of the line. Also, if I run mutt, for instance, you can see that it follows the cursor, in that in mutt we made, we had the developers put the cursor on the line that is currently selected, because else it's just highlight and that is hard to track, so you see the cursor is at the end of the line, and so when I'm moving, the screen reader is actually updating automatically, you don't need anything to do. I show aumix, which does the same, basically, you have the cursor here, and when I switch to the right part of the screen, then it follows as well, so it's really neat.

So, this means that, if you want to make your text application quite accessible, just put the cursor where it should be, even when for instance in mutt you wouldn't like to show it. Still put it somewhere, somewhere that makes sense.

* Slide 19

Now, about graphical accessibility, it's a long story that started, like, 20 years ago maybe, I can't remember, mercator, at the time, was working with, for instance xedit, which was sending text to the X server and then rendered in the X server. So mercator could actually get the text directly on, say, the "cable" between the applications and the X server.

* Slide 20

The problem is that nowadays, if you run gedit, which uses gtk to render the text, which uses the pango rendering library, which gets the text and transforms it into pixmaps before sending to the X server. And so mercator gets just pixmaps, and it would have to do some OCR to actually get the text, and that's not something that really can work.

* Slide 21

So, what is being done, what is currently working in Linux, is directly get the text from the gtk layer, where it still is text, and not just pixmaps. So that's the same principle as I exposed before, you have an accessibility bus here, which permits Orca, the screen reader, to get the text from the application, and output the way it prefers.

* Slide 22

So, to summarize, a lot of applications are already accessible, so console are mostly accessible, there are a few exceptions, but mostly it's quite ok. Gtk, because people have implemented an automatic way of presenting the abstract representation from the, well, what the application wants, a screen box, etc. KDE does the same, but it's not yet connected to the standard accessibility bus, so it's "really soon now", since 4 years, but well, we hope that it will happen, yes, maybe the year or two. Adobe made quite good work at making his acrobat reader accessible, it's really neat that a proprietary software really did it.

KDE does the same, but it's not yet connected to the standard accessibility bus, so it's "really soon now", since 4 years, but well, we hope that it will happen, yes, maybe the year or two. Adobe made quite good work at making his acrobat reader accessible, it's really neat that a proprietary software really did it.

And the rest is basically not so accessible, for instance KDE3 didn't have the infrastructure, Xt is the old toolkit that, for instance ghostview or xpdf, or xfig, use, and it's not accessible at all. Applications which draw things themselves are not accessible of course because well, they would have to just provide the text and the structure, just like what acrobat reader does, actually.

* Slide 23

In practice, those applications which were supposed to be accessible are not so much accessible, so for instance in the console, I still have my braille device, yes. Alsamixer poses, well, a few problems in that it exposes vertical things, which is not really nice for braille devices. You would prefer horizontal things.

On the graphical side, well, usually the problem is that you have a mess of widgets, for instance here you have labels, three labels, and three text boxes, and the label relates to text box, but maybe you have first layed out the labels and then put the text boxes, and so it's a bit of a mess and the screen reader can not know that they are related, so that's why people write scripts for each application to relate them together, instead you should just use labeled text boxes, so that right from the start they are related together.

* Slide 24

So, just a few things I've already told about this morning:

* just design your application without thinking about graphical things
* always provide equivalents, text equivalents, for instance you can share the libraries between text and graphical
* for text applications, put the cursor in a sane place, so you can guide the screen reader
* take user suggestions into consideration, when they say it would be useful to have this, then think about it, really.
* and if you're crazy enough, yes, test it yourself, be it using gnome-terminal and accerciser for the graphical ones, and gnome-orca to just try yourself, it's not really easy, you have to learn quite a bit.

* Slide 25

Now, I would like to talk about bootstrapping. It's more perspectives than existing solutions, and I'm mostly thinking loud.

* Slide 26

So, you enter a cyber-café, and you want to use the computers there, how to access them? What should be quite easy is automatic detection, like you have your USB braille device, you just plug it in, the system recognizes it's a braille device, and starts the screen reader. This should be relatively easy.

Ubuntu does this, it has posed some problems because some devices advertise them as a serial port, a generic serial port, and so it poses problem with the real serial ports which are not braille devices, but well.

There are some shortcuts, that can be useful, for instance, for people who have problems with the keyboard, there are some shortcut to enable some keyboard features. Compiz has an integrated zoom feature, which is quite easy to just trigger on any desktop.

My question is, well, it would be great to have a standard shortcut that enables speech synthesis that would work on any distribution. That hasn't appeared yet.

Or, well, this was mostly for blind people and some keyboard problems, ideally you should have an accessibility panel which presents all the options that you would want to enable/disable, etc. The problem is that this panel needs to be accessible, itself. A way we might think of is just a USB key with a config file on it, like at the root of the file system, and you plug it in, and when the system sees that config file, it says "ok, that's an accessibilty configuration, I will apply the options that are described", and then automatically starts acting like the user would like.

* Slide 27

Another aspect which is quite related, you have a brand new computer, and you want to install Linux on it, of course. That's just the same issues and potential solutions, nowadays what is happening mostly is that people have accessible versions of installation CDs, for instance that they start speech synthesis by default. The problem is then that it's not mainline, in principle all installation CDs should be accessible, including for instance all the Debian forks for different uses, be it Debian Med, or Debian Multimedia, etc. There is no reason that it should be a separate CD that is just for people who need it.

I talk a bit about Debian, what we have now already, is - USB braille autodetection, so that somebody who has a USB braille device can just be alone, his computer crashes, he has to reinstall, not a problem, he just uses his CD, standard, downloaded from the Internet, or asks somebody to burn it for him, or just use the one he has in his library. And then he can install Debian again, or restore something on the system. - You can enable high contrast, or hardware speech by hand, there is no software speech synthesis yet, for space reason, some drivers reason, lot of things, but well we hope to eventually manage to get this on the standard CD set, that would be really great.

* Slide 28

But then there is the problem of the BIOS. How can you make your CD boot? BIOSes are mostly non-accessible, except a few old ISA card which can just read the video memory and then get the text from there. On servers, you have the serial port support, which is useful for professionals, and then it's accessible. Well, maybe we could think about EFI, to have accessibility modules that you could load, or something like this, I'm not really into the standard, the EFI standard, but that could be something to have a look at.

* Slide 29

And eventually the bootloader, mostly they are not accessible, nowadays, but they are improving. What they usually have is a beep to say that, "yes, you are at the menu, I can accept the keys to change the item that should be booted". You have quite often keyboard shortcuts to quickly select the one you want. Well, things I'm thinking out right now and I've been talking with grub people already, is some beeps to tell that, yes, you have selected this one, that one. Maybe just presynthesize some .ogg file, since, you have a configuration file, but you know what grub will need to say, so you just do the speech synthesis in advance, and then at boot, the bootloader just needs to have some drivers, and play the .ogg files, well, sound drivers seems a bit crazy but well, why not. You could even want to ship a whole screen reader in the core. From the point of view of grub people it's actually just another alternative terminal, it's just that it's synchronized with the actual screen. That's something we have talked together with them. And yes, the synchronization part is already implemented, so it's now just about drivers.

* Slide 30

So, to conclude, accessibility features are a bit convoluted, it's not the "standard" way of propagating the information. That standard way was invented by sighted people who had both hands and will hear etc. so that's why it's, yes, out of the standard, but anyway, it can not be standard, since you never know what people would need to be able to use the software and hardware, so you have to find ways. From my experience, all this is not really technical issues, it's mostly integration issues, so for instance if you have a look at the debian-boot and debian-accessibility lists, you'll see that there were some periods with really a lot of mails just because they were talking to each other and finding a solution to integrate things properly.

One thing we did, however, is defining a client/server way of displaying braille and getting keypresses, that is used between brltty and orca, for instance. Orca doesn't have braille drivers, it just talks with brltty to actually render things on the braille device. But for now it's just used for software. Maybe, with free braille devices, we would use free and open protocols for these, that would be great.

Question : I remember reading something on the linux kernel mailing list, where you were asking something I don't remember, somebody replied basically that blind people didn't code anything or something like that. Do you often get this kind of crazy answers when for instance you go to talk with the aumix maintainer and tel him "put the cursor at this place, because it's better for blind people". Do they agree, or is it difficult to comm with them.

Réponse : Basically, the thing is, you shouldn't hurt the sighted way. If you do not hurt the sighted way, then they are more keen on modifying things. Like, if it's an option then it's really usually fine. The problem is that then you have to enable the option, and that's a pain for users. In the mutt and aumix case, actually they enabled it by default because they they realized that they can hide the cursor, so it doesn't hurt the sighted way, and, for instance, yeah, we submitted a patch to the linux kernel for make menuconfig, and they just applied it immediately, didn't even ask.

Traduction

* Diapo 1

Ok donc... bonjour à tous, je m'appelle Samuel Thibault, je vais vous parler des mécanismes de l'accessibilité. Donc c'est quelque chose qui n'est pas très connu du point de vue du système d'exploitation. Alors je vais détailler des choses comme la manière d'accéder à l'écran, etc.

* Diapo 2

Donc le plan sera... Je vais d'abord vous présenter un peu l'accessibilité, parce que vous ne savez sûrement pas grand chose sur ce point. Puis je détaillerai un peu le matériel, quel matériel on peut utiliser. Puis je détaillerai beaucoup le côté logiciel, donc les couches et les interfaces utilisées pour l'accessibilité. Et enfin je vous parlerai de la façon de bootstraper, ce qui est presque un problème de design et d'interface utilisateur, mais c'est aussi un problème de système d'exploitation.

* Diapo 3

Alors d'abord, qu'est-ce que l'accessibilité ? On l'appelle aussi « a11y », c'est disons l'abréviation habituelle, vous savez i18n c'est pour l'internationalisation, c'est parce que ça commence par un i et finit par un n et vous avez 18 lettres entre les deux, eh bien a11y c'est pareil, c'est « accessibility ». Donc ça veut dire faire un logiciel utilisable par, ben les personnes handicapées, mais en fait par tout le monde sur terre.

Alors les personnes évidemment concernées sont les personnes aveugles, mais il y a beaucoup d'autres handicaps, comme des gens qui sont déficients visuels, et pas nécessairement complètement aveugles, mais elles ont des problèmes.

Certaines personnes sont sourdes, donc par exemple les jeux qui se basent sur le son pour entendre ce qu'il se passe pour ne pas se faire tuer, c'est un problème.

Le daltonisme, ce n'est peut-être pas très connu, combien de personnes sont daltoniennes dans la salle ? Personne, c'est super bizarre parce que 8% des individus masculins sont daltoniens, donc ça fait beaucoup en fait. Les femmes ont de la chance parce qu'elles ne sont pas trop touchées par ça.

Certaines personnes n'ont qu'une main, donc le clavier habituel n'est pas très adapté, donc elles utilisent une présentation spéciale avec une touche de bascule, pour que quand elles appuient dessus, elles ont l'autre moitié du clavier et des doigts. Donc elles n'ont pas besoin de bouger la main de gauche à droite et vice-versa, elles doivent juste basculer pour avoir l'autre moitié du clavier.

Ceux avec une main-doigt, donc certaines personnes ... peuvent juste bouger un doigt ou quelque chose qui ressemble à un doigt. Elles utiliseraient des manettes, pour utiliser comme une souris mais c'est une manette.

Ceux avec une main-œil, donc je vais juste vous montrer un peu dasher, alors j'ai la souris là, qui suit mon œil et je peux très facilement taper des choses, en regardant juste les lettres. Par exemple, Hello... Je cherche la virgule désolé, je la trouve pas... elle est là... et vous voyez que le mot, par exemple, là vous voyez « you » y-o-u, très clairement parce que statistiquement, en anglais, quand on commence par un y, souvent on veut mettre un o juste après ça, donc vous voyez en fait les mots qui se forment, c'est vraiment marrant. Et c'est très efficace pour écrire des choses.

Handicap cognitif. Certaines personnes disent même que c'est un peu tabou, mais il y a bien sûr beaucoup de problèmes mentaux. Regardez, vous êtes un peu perdu dans une interface avec pleins de boutons et des choses comme ça. Ou juste vous n'arrivez pas à lire ce qu'il y a à l'écran, donc vous avez besoin d'images pour pouvoir utiliser un logiciel.

Et les personnes âgées, qui ont... ben un peu de tout ce qui précède. C'est donc bien sûr difficile pour elles.

Je vous invite vraiment à jeter un œil sur les guides pratiques de l'accessibilité parce qu'ils contiennent beaucoup de détails, des descriptions de types différents d'handicap et leurs solutions. C'est très vieux, genre 2002, mais c'est toujours très correct, les choses n'ont pas vraiment changé depuis de ce côté-là.

* Diapo 4

Alors parlons matériel, bon il y a eu l'autre jour une conférence sur la façon de faire un périphérique braille libre, par Mario Lang. Je vais juste détailler le matériel lui-même.

* Diapo 5

Alors bien entendu, il y a l'entrée et la sortie brailles pour les personnes aveugles. D'autres personnes aiment la synthèse vocale. Vous pouvez utiliser des manettes, qui peuvent remplacer les bases de la souris, donc il n'y a pas grand chose à dire sur ça. Les boutons à pression sont intéressants dans le sens où vous avez un clavier virtuel à l'écran et avec le bouton à pression, vous pouvez, avec un délai, vous appuyez sur le bouton pour faire défiler les rangées du clavier puis vous vous arrêtez pour dire « Je sélectionne cette rangée » puis les colonnes défilent, puis vous vous arrêtez avec un autre clic et alors vous pouvez valider pour dire « Oui, c'est sur cette touche que je veux appuyer. » C'est très lent. Avec un clavier d'assistance à l'écran qui affiche du clavier virtuel juste les parties importantes de ce qui apparaît à l'écran, vous pouvez être très efficace mais c'est un peu difficile, mais oui ça rend possible beaucoup de choses avec très peu de possibilités. La poursuite de l'œil, j'en ai parlé et je vous ai montré le dasher.

* Diapo 6

Il y a une chose importante à comprendre, c'est qu'aucune technologie n'est parfaite. Le braille n'est pas parfait dans le sens où il y a beaucoup de gens qui ne savent pas lire le braille, surtout quand des personnes deviennent aveugles à un âge avancé, elles ne peuvent pas faire l'effort d'apprendre ça. Ou elles ne peuvent tout simplement pas le sentir avec leurs doigts. Les périphériques brailles coûtent très cher, je vais le détailler un peu plus. La synthèse vocale elle-même peut remplacer le braille mais ce n'est pas parfait non plus, vous pourriez vous trouver en train ou dans un tram. On la trouve aussi lente parfois ; par rapport au braille, il y a aussi un problème de précision. Avec le braille, vous pouvez rapidement contrôler, par exemple quand vous codez, si les guillemets ou parenthèses sont ouverts. Avec la synthèse vocale, c'est un peu difficile, c'est pénible.

* Diapo 7

Alors je vais un peu m'arrêter sur le braille. Ça c'est une cellule braille, elle utilise un effet piezo, c'est-à-dire que vous avez ces barres qui peuvent en fait se dresser quand vous appliquez une tension, et donc elles élèvent ou abaissent des points situés au-dessus d'elles, et c'est comme ça avec 8 barres piezo et 8 barres, vous pouvez former ce qu'on appelle alors un signe braille, donc 8 points, ce qui correspond en fait à un caractère je vais détailler un peu plus tout à l'heure.

* Diapo 8

Alors un périphérique braille, c'est juste un ensemble de ces cellules, comme 40 ou 20 cellules, on peut les connecter à un PC avec un port série, USB ou bluetooth. Le truc c'est que le prix, quand on regarde le marché, est de l'ordre de 150 fois le nombre de cellules en euros. Ça veut dire que, non je n'ai pas de diapo pour ça. Un afficheur braille standard de 40 caractères coûte environ 5000€, ce qui est bien plus cher que le portable où vous faites tourner un logiciel. C'est donc pourquoi on a eu une conférence sur un périphérique braille libre, pour essayer de casser un peu ce prix.

* Diapo 9

Sur le braille, j'aimerais vous le décrire un peu plus parce que c'est vraiment méconnu en général. Alors, vous avez 8 points, ça veut dire seulement 256 signes, deux puissance 8. Le truc c'est qu'il n'y a que les lettres a à z qui sont standards dans le monde entier, il y a même des exceptions, par exemple en vietnamien, pour la lettre d. Le reste dépend de la langue, par exemple ':' n'est pas le même signe en américain et en français. Oui, en anglais américain et en français. Donc quand on vous donne par exemple un papier avec quelque chose d'écrit en braille, il se peut que vous n'arriviez même pas à le lire, juste parce que vous ne connaissez pas le braille américain ou des choses comme ça. Ça dépend aussi du pays, les choses convergent maintenant, mais le braille français belge, français canadien et français de France étaient un peu différents avant, donc c'était un peu le désordre, et ça dépend aussi de l'utilisation. Parce qu'en fait le braille français a changé plusieurs fois comme en 1998 et 2007, quelque chose comme ça, donc des personnes âgées qui connaissent l'ancienne version, les jeunes connaissent la nouvelle version et c'est un peu le désordre. Des périphériques ont leur propre table, donc l'utilisateur est habitué à cette table et pas à celle officielle du pays. Et il y a aussi des problèmes avec les documents multilingues. Certains préfèrent lire l'anglais avec une table française parce qu'ils sont habitués à voir les deux-points avec la table française, mais d'un autre côté pour un Japonais, eh ben on aurait besoin de la table japonaise parce qu'il n'y a pas d'encodage japonais en français.

* Diapo 10

Alors maintenant, pour être plus précis sur ce qu'on entend par « Table braille ». Il y a deux niveaux à la base. Alors vous avez le degré 0 qu'on appelle aussi le braille intégral, littéral, bon, le principe est que chaque cellule code un caractère. Donc en fait vous avez une bijection entre le caractère et la cellule, ce qui simplifie vraiment les choses. En particulier, quand vous avez un encodage 8 bits, c'est juste une bijection entre l'encodage qu'on utilise et l'espace des signes brailles. Alors par exemple, je vous ai montré 'A', 'B', 'C' et guillemets. Mais ensuite, quand on passe en unicode et qu'on a plusieurs langues dans le même document, eh bien on a une ambiguïté, et c'est un problème insoluble sans des repères pour dire « bon maintenant c'est en anglais, maintenant c'est en français », etc. Maintenant vous avez un deuxième niveau, qui est le degré 1 ou 2, on l'appelle aussi braille abrégé.En fait c'est comme quand on écrit avec l'alphabet latin habituel, mais par exemple les suffixes sont abrégés en seulement quelques cellules, donc vous voyez « ation » qui est un suffixe courant dans les mots anglais, est abrégé par seulement ces deux cellules. Bien sûr le problème c'est que vous avez ensuite des ambiguïtés, ce suffixe « ation » est alors codé de la même façon que le 'N' majuscule. Mais on l'a choisi d'une manière que ça pose rarement problème, et bien sûr ces règles dépendent beaucoup de la langue et de l'usage.

* Diapo 11

Donc ça c'était pour le matériel. Parlons du logiciel.

* Diapo 12

Je veux juste vous parler un peu des logiciels dédiés. Par exemple, il y a edbrowse, qui est un navigateur pour personnes aveugles. Eh bien en général, je pense que ce n'est pas une bonne idée parce qu'edbrowse a commencé à implémenter le javascript, il n'implémente sûrement pas le flash. J'imagine qu'il supporte les tableaux, le css n'est sûrement pas supporté. Bon on ne peut pas tout faire soi-même, vous devriez vraiment seulement réutiliser l'existant. Un autre exemple, une suite bureautique devrait être compatible OpenOffice, mais bon vous n'avez pas envie d'écrire du code pour lire un document OpenOffice, etc. Une autre raison d'utiliser simplement les applications existantes est le travail ensemble. Quand vous êtes aveugle, en général vous voulez travailler avec une personne non aveugle, et quand vous travaillez avec elle, vous êtes à côté d'elle sur l'ordinateur, et donc c'est mieux d'utiliser tout simplement le même logiciel, pour que vous vous compreniez. Et aussi pour avoir des informations et de la documentation, vous avez beaucoup plus de documentation sur OpenOffice pour faire ceci ou cela qu'edbrowse, donc cela est plus logique d'utiliser ce qui existe.

* Diapo 13

Maintenant le problème est : comment le rendre accessible. Alors d'abord, j'aimerais faire un petit résumé de l'état des lieux. Le mode texte est généralement très accessible, dans le sens où ce n'est que du texte et on peut l'interpréter simplement, ce n'est pas trop un problème. Mais tous les débutants diraient « Ce n'est pas facile à utiliser », « Je ne veux pas apprendre toutes ces commandes », donc ils utilisent plutôt Gnome, qui commence à être accessible. Ça a commencé il y a une décennie, peut-être un peu moins, mais il y a encore un long chemin à faire, en particulier par rapport au monde Windows, qui a commencé il y a des décennies et qui, oui, est beaucoup plus avancé que ce qu'on a avec Linux. Ceci étant dit, l'état actuel est vraiment que vous pouvez utiliser le bureau Gnome desktop, au travail, par exemple pour travailler avec des gens qui travaillent sur des documents OpenOffice et tout ça. On peut mieux faire mais c'est déjà très utilisable.

* Diapo 14

Alors maintenant, concernant l'accessibilité de gnome, le principe général est que, bon, vous avez le pipeline habituel qui commence par l'application, vous avez une représentation abstraite de l'application et des choses qui devraient apparaître à l'écran, puis vous avez le rendu visuel. L'accessibilité ajoute juste quelque chose à la représentation abstraite, pour qu'il y ait un registre pour savoir la liste des applications qui sont là, et un lecteur d'écran peut accéder à la représentation abstraite de chaque application, puis la rendre sur n'importe quel type de périphérique d'accessibilité que vous pourriez vouloir, que ce soit du braille, du vocal ou autre chose.

* Diapo 15

Alors par exemple, dans le cas de Linux, c'est très simple : donc vous avez Linux avec les consoles virtuelles, vous avez plusieurs applications qui tournent sur VT1, VT2, VT3, et Linux fournit, et ça a été, je pense, vraiment conçu pour l'accessibilité, /dev/vcsa qui fournit basiquement le texte, c'est tout, et c'est tout ce dont on a besoin en fait, pour des choses en mode texte, et donc brltty est le lecteur d'écran qui lit ça, puis utilise des pilotes pour afficher ça sur le périphérique braille.

* Diapo 16

Une chose supplémentaire, quand le périphérique braille a un clavier braille, vous voulez simuler l'effet de l'appui sur une touche sur Linux, comme si vous aviez appuyé sur le vrai clavier du PC. Cela se fait avec des ioctl sur les terminaux virtuels, dons on appelle ça TIOCSTI, c'est une longue histoire j'imagine. Ou vous pouvez utiliser le module uinput de Linux pour faire en fait comme si on avait un faux clavier et on y simule la touche. Ce qui est intéressant, c'est que la manière ioctl a besoin d'une chaîne, alors que la méthode uinput a besoin d'un numéro de touche. La grande différence, c'est qu'ici, ['ioctl'] la touche a déjà été traduite, donc c'est vraiment un 'a' qui sera envoyé à l'application alors que là, la méthode uinput, vous avez la touche 'a' qui signifie « la touche étiquetée a sur le clavier qwerty ». Donc si vous avez un clavier azerty, eh bien après le module uinput, elle sera traduite en 'q' si c'est un clavier azerty. C'est en fait nécessaire quand l'utilisateur a un clavier azerty sur son périphérique, ou autre. C'est quelque chose qu'on a ajouté très récemment en fait.

* Diapo 17

Une autre façon de faire des choses similaires est d'utiliser des ptys, donc vous avez un tty en haut, qui peut être une console virtuelle linux, ou un xterm, n'importe quoi, et vous démarrez yasr (ce qui veut dire « yet another screen reader" » (encore un nouveau lecteur d'écran)), qui lance un pseudo-tty, dans lequel la vraie application peut fonctionner, et alors yasr agit basiquement comme filtre, il copie juste dans les deux sens, mais il obtient le texte avec ça et il peut donc utiliser la voix, il est donc très portable mais il doit alors tout interpréter, ce qui veut dire tous les échappements du tty et des choses comme ça.

* Diapo 18

La question qui se pose alors, quand on a du texte, donc on a une grosse matrice de texte, c'est « Qu'afficher ? » Eh bien ce que les gens font en général, dans les lecteurs d'écran, c'est d'afficher ce sur quoi est le curseur, donc ça fonctionne très bien avec un shell par exemple. Donc là j'ai un shell, donc quand je tape, le périphérique braille suit en fait ce qu'il se passe, donc regardez, je suis à la fin de la ligne braille, et ça bascule vers la partie suivante de la ligne. Si j'exécute mutt aussi, par exemple, vous pouvez voir qu'il suit le curseur, donc ce qu'on a fait avec mutt, c'est que les développeurs ont mis le curseur sur la ligne actuellement sélectionnée, parce que sinon c'est juste surligné et c'est difficile à voir, donc vous voyez, le curseur est à la fin de la ligne, et donc quand je bouge, le lecteur d'écran se met automatiquement à jour, vous n'avez rien besoin de faire. Je vous montre aumix, qui fait la même chose, vous avez le curseur là, et quand je vais à droite de l'écran, il suit aussi, donc c'est très bien.

Donc ça veut dire que si vous voulez rendre accessible votre application texte, il faut juste mettre le curseur là où il le devrait, même si par exemple dans mutt, vous ne voudriez pas afficher ça. Mettez-le quelque part, là où c'est cohérent.

* Diapo 19

Maintenant cencernant l'accessibilité graphique, c'est une longue histoire qui a commencé il y a peut-être 20 ans, je ne me souviens plus, mercator, à cette époque, fonctionnait par exemple avec xedit, qui envoyait du texte au serveur X puis l'affichait sur le serveur X. Donc mercator pouvait en fait récupérer directement le texte sur, disons le « câble » entre les applications et le serveur X.

* Diapo 20

Le problème est qu'aujourd'hui, si on exécute gedit, qui utilise gtk pour afficher le texte, qui utilise la bibliothèque d'affichage pango, qui récupère le texte et qui le transforme en pixmaps avant de l'envoyer au serveur X. Et donc mercator récupère les pixmaps, et il devrait faire de l'OCR pour récupérer le texte, ce qui n'est pas quelque chose qui fonctionne vraiment en fait.

* Diapo 21

Alors ce qui se fait, ce qui fonctionne actuellement sur Linux, c'est de récupérer directement le texte depuis la couche gtk, là où c'est encore du texte, et pas seulement des pixmaps. Donc c'est le même principe que ce que je vous ai présenté tout à l'heure, sauf qu'avant, on a ici un bus d'accessibilité qui permet à Orca, le lecteur d'écran, de récupérer le texte depuis l'application, et de l'afficher de la manière qu'on préfère.

* Diapo 22

Alors pour résumer, beaucoup d'applications sont déjà accessibles, donc la plupart de celles en console sont accessibles, il y a quelques exceptions mais en général ça va. Celles gtk, car les gens ont implémenté une manière automatique de présenter la représentation abstraite à partir de, ben de ce que veut l'application, une boîte, etc.

KDE fait pareil mais il ne se connecte pas encore au bus d'accessibilité standard, alors c'est « pour très bientôt » depuis 4 ans, mais bon on espère que ça se fera, oui peut-être dans un ou deux ans. Adobe a fait du très bon travail pour rendre accessible son acrobat reader, il est impressionnant qu'un logiciel propriétaire l'ait vraiment fait.

Et le reste n'est tout simplement pas très accessible, par exemple KDE3 n'avait pas d'infrastructure, Xt est l'ancien « toolkit » qu'utilisent, par exemple, ghostview ou xpdf, ou xfig, et il n'est pas accessible du tout. Les applications qui dessinent des choses elles-mêmes ne sont pas accessibles bien entendu, parce que bon, elles devraient juste fournir le texte et la structure, comme le fait acrobat reader en fait.

* Diapo 23

En pratique, ces applications qu'on supposait accessibles ne le sont pas tant que ça, donc par exemple en console, j'ai encore mon périphérique braille, oui. Eh bien alsamixer pose quelques problèmes dans le sens où il présente les choses de façon verticale, ce qui n'est pas génial pour les périphériques brailles. On préférerait des choses horizontales.

Côté graphique, eh bien en général, le problème c'est qu'il y a du désordre dans les widgets (éléments), par exemple là vous avez des étiquettes, trois étiquettes, et trois zones de texte, et l'étiquette est liée à la zone de texte, mais peut-être vous avez d'abord rangé les étiquettes, ensuite les zones de texte, et donc c'est un peu le désordre et le lecteur d'écran ne peut pas savoir qu'elles sont liées, c'est pourquoi des gens écrivent des scripts pour chaque application pour les relier ensemble, alors que vous devriez simplement utiliser des zones de texte étiquettées, donc la bonne formule serait de commencer à les relier ensemble dès le départ.

* Diapo 24

Alors juste quelques éléments dont j'ai déjà parlé ce matin :
* Concevez tout simplement vos applications sans penser à des choses graphiques
* fournissez toujours des équivalents, des équivalents textes, par exemple vous pouvez partager des bibliothèques entre du texte et du graphique
* pour des applications texte, mettez le curseur à un endroit qui a du sens, pour guider le lecteur d'écran
* prenez en compte les suggestions des utilisateurs, quand ils vous disent que ce serait utile d'avoir cela, réfléchissez-y vraiment
* et si vous êtes suffisament fou, oui, testez vous-mêmes, utilisez gnome-terminal et brltty pour les applications en console, accerciser pour celles graphiques, et gnome-orca, juste pour essayer vous-même, ce n'est pas très facile, vous devrez apprendre un peu.

* Diapo 25

Maintenant, j'aimerais vous parler du bootstrapping. C'est plus des prospectives que des solutions existantes et je ne fais que réfléchir à haute voix.

* Diapo 26

Alors, vous entrez dans un cyber-café, et vous voulez y utiliser les ordinateurs, comment y accéder ? Ça devrait être facile avec une détection automatique, genre vous avez votre périphérique braille USB, vous le branchez simplement, le système reconnaît que c'est un périphérique braille et il démarre le lecteur d'écran. Cela devrait être relativement facile.

Ubuntu fait ça, ça a posé problèmes car certains périphériques se comportent comme un port série, un port série générique, et donc ça pose problème avec les vrais ports série qui ne sont pas des périphériques brailles, mais bon.

Il y a des raccourcis, ça peut servir, par exemple pour des gens qui ont des problèmes de clavier, il y a des raccourcis pour activer certaines fonctionnalités de clavier. Compiz a une fonction de zoom intégrée, ce qui s'utilise très facilement sur n'importe quel bureau.

Ma question est, bon, ce serait génial d'avoir un raccourci standard qui active la synthèse vocale qui fonctionnerait sur n'importe quelle distribution. Cela n'existe pas encore.

Ou alors bon, c'était surtout pour les personnes aveugles ou ayant des problèmes de clavier, idéalement on devrait avoir une barre d'accessibilité qui affiche toutes les options qu'on peut vouloir activer/désactiver, etc. Le problème est que la barre doit elle-même être accessible. Une façon dont on pourrait faire est tout simplement de créer une clé USB avec avec dessus un fichier de config, comme à la racine du système de fichiers, et on la branche et quand le système voit ce fichier de config, il dit « ok, c'est une configuration d'accessibilté, je vais appliquer les options décrites », puis commencer à se comporter automatiquement comme le souhaite l'utilisateur.

* Diapo 27

Un autre aspect très lié est quand vous avez un nouvel ordinateur, et vous voulez bien sûr installer Linux dessus. Ça pose les mêmes problèmes avec les mêmes solutions potentielles, aujourd'hui la plupart du temps, les gens ont des versions accessibles des CDs d'installation, par exemple qui démarrent avec la synthèse vocale par défaut. Le problème alors est que ce n'est pas dans la branche principale, en principe tous les CDs d'installation devraient être accessibles, y compris par exemple tous les forks Debian pour les différents usages, que ce soit Debian Med, ou Debian Multimedia, etc. Il n'y a pas de raison pour qu'il y ait un CD séparé réservé aux personnes qui en ont besoin.

Je vais vous parler un peu de Debian, ce qu'on y a déjà, c'est - l'auto-détection du braille USB, pour que quelqu'un qui a un périphérique braille USB puisse être seul, son ordinateur plante, il doit réinstaller, pas de problème, il utilise simplement son CD, standard, qu'il a téléchargé sur Internet, ou il demande à quelqu'un de le graver pour lui, ou utiliser celui qu'il a dans sa bibliothèque. Et alors il peut réinstaller Debian ou restaurer quelque chose sur le système.

- Vous pouvez activer les forts contrastes, ou la synthèse matérielle à la main, il n'y a pas encore de synthèse vocale logicielle pour des questions de place, de pilotes, beaucoup de choses mais bon on espère réussir éventuellement à avoir ça sur un CD standard, ce serait vraiment génial.

* Diapo 28

Mais alors il y a le problème du BIOS. Comment fait-on démarrer son CD ? Les BIOSes ne sont pas accessibles la plupart du temps, sauf quelques vieilles cartes ISA qui peuvent simeplement lire la mémoire graphique puis y récupérer le texte. Sur les serveurs, vous avez le support des ports série qui est utile pour les professionnels et donc ils sont accessibles. Bon on pourrait peut-être penser à l'EFI, pour avoir des modules d'accessibilité que vous pourriez charger, ou quelque chose comme ça, je ne suis pas très au fait des standards, du standard EFI, mais cela pourrait valoir le coup de regarder.

* Diapo 29

Et à terme les chargeurs de démarrage, ils ne sont pas accessibles la plupart du temps, mais aujourd'hui ils s'améliorent. En général ils ont un bip pour dire « Oui, vous êtes dans le menu, je peux accepter les touches pour modifier l'élément sur lequel démarrer ». Très souvent on a des raccourcis claviers pour sélectionner rapidement celui qu'on veut. Bon, il y a des choses auxquelles je réfléchis et j'en ai déjà parlé avec les gens de grub, comme des bips pour dire que, oui vous avez sélectionné ceci, cela. Ou présynthétiser peut-être quelques fichiers .ogg, puisqu'on a un fichier de configuration mais on sait ce que grub devra dire, donc on fait juste la synthèse vocale en avance, puis au démarrage, le chargeur de démarrage n'a plus qu'à avoir des pilotes et lire des fichiers .ogg, enfin des pilotes de son, ça semble un peu fou mais bon, pourquoi pas. On pourrait même vouloir embarquer un lecteur d'écran entier dans le cœur même. Du point de vue des gens de grub, c'est en fait simplement un autre terminal alternatif, simplement il faut le synchroniser avec l'écran effectif. C'est quelque chose dont on a discuté avec eux. Et oui, le côté synchronisation est déjà implémenté, donc maintenant c'est juste une affaire de pilotes.

* Diapo 30

Donc, pour conclure, les fonctionnalités d'accessibilité sont un peu alambiquées, ce n'est pas la manière « standard » de communiquer l'information. Cette manière standard a été inventée par des personnes voyantes qui ont leurs deux mains et leurs deux oreilles, etc. C'est pourquoi c'est, oui, hors du standard, mais de toute façon ça ne peut pas être standard, puisqu'on ne sait jamais ce dont ont besoin les gens pour utiliser un logiciel et du matériel, donc il faut trouver des moyens. Par expérience, tout ça n'est pas lié à des problèmes techniques, c'est souvent des problèmes d'intégration, donc par exemple si vous jetez un œil sur les listes debian-boot et debian-accessibility, vous verrez qu'il y avait à certains moments beaucoup de messages, juste parce qu'ils se parlaient et ils trouvaient une solution pour intégrer correctement les choses.

Merci.

applaudissements

Y'a-t-il des questions ?

Question : Y a-t-il un standard pour l'accessibilité, un protocole qu'utilisent le braille, une tablette ou des choses comme ça?

Réponse : Tu veux dire le même protocole que pour les cellules braille ? Pour le port série, il n'y en a pas. Bon en fait il y a comme un combat entre les constructeurs là-dessus, bon il y a des compatibilités, des périphériques peuvent émuler d'autres protocoles, c'est un peu le désordre en fait. Il y a bien 20 pilotes sur brltty je crois, pour supporter genre 40 ou 50 types différents de périphériques.

Une chose qu'on a faite par contre, c'est définir un chemin client/serveur d'affichage braille et de récupération des appuis sur une touche, c'est utilisé entre brltty et orca par exemple. Orca n'a pas de pilotes brailles, il ne parle qu'avec brltty en fait, pour afficher des choses sur le périphérique braille. Mais pour l'heure ce n'est utilisé que pour du logiciel. Peut-être qu'avec les périphériques brailles libres on utilisera des protocoles libres et ouverts pour ça, ce serait vraiment génial.

Question : Je me souviens avoir lu quelque chose sur la liste de diffusion du noyau linux où tu demandais quelque chose dont je ne me souviens plus, quelqu'un a répondu que, de toute façon, les personnes aveugles ne codaient rien ou quelque chose comme ça. Tu as souvent ce genre de réponse folle quand par exemple tu parles avec le mainteneur d'aumix pour lui dire « mets le curseur là car c'est mieux pour les personnes aveugles ». Sont-ils d'accord ou c'est difficile de communiquer avec eux?

Réponse : La base, ce qu'il y a c'est qu'il ne faut pas gêner le procédé visuel. Si on ne gêne pas le procédé visuel, ils sont plus motivés pour changer les choses. Si c'est en option, en général ça passe bien. Le problème c'est qu'il faut alors activer l'option, et c'est pénible pour les utilisateurs. Dans le cas de mutt et de aumix, ils l'ont en fait activée par défaut car ils se sont rendus compte qu'ils pouvaient cacher le curseur, donc ça ne gêne pas le procédé visuel, et, par exemple, oui on a soumis un correctif au noyau pour make menuconfig, et ils l'ont immédiatement appliqué, ils n'ont même pas demandé.

Merci.

applaudissements