[Slides and documentation stuff etc. on http://brl.thefreecat.org/] [...] [Slide 24] ... the sofware at hand all the time, so that the talk just before this one, about having your preferences stored somewhere, and then you get them automatically, configured on the desktop you are using, without having to ask for it, you just plug something, and then, everything is working nicely for you. So it should be available already, on all systems. [Slide 26] So, to talk about free software... Text mode is generally quite well accessible because technically it's quite simple. But it's not so suited to beginners. Beginners don't really like text interfaces. Gnome is quite accessible. One issue we had with gnome3, it was mostly a restart from the beginning. So it's taking back to the point it was with gnome2, but not so much. So, that's really a concern to see this kind of regression. And what's more concerning is that we are really late compared to the Windows world. They started like a couple of decades ago, while we have started only like a dozen years ago. And it does show up in the tests we can be doing. Compared to Apple, we are really at Stone Age. The Apple screen readers are really great. And they are integrated: you take whatever Apple product, you just have to know some shortcut, you learn by heart, it works on all Apple products. And it does really work nice, so much that people who were really strong free software believers have switch to Apple, just because otherwise they wouldn't be able to do computing. And that's really a concern we have to deal with. [Slide 52] A bit of technology... the way it works is that we have the application here, which has an abstract representation of the widgets, windows, etc. and then it is rendered visually. And what happens is that we have an accessibility bus, which will actually discuss with that abstract representation to get the information, the text, how it is related together, and etc. And then we have the screen reader which is able to get that information through the bus and render that to an accessibility device: a braille device, speech synthesis, something else... we don't have to care. The idea is that as long as the abstract representation provides all the information in a good way, then the screen reader will do its work. [Slide 57] So for instance we have here gedit, which uses gtk, and renders things through pango to the X server, but it also has atk to let Orca, the screen reader, access the text, and then render this as braille, speech, etc. [Slide 58] So how it works is basically that Orca asks for the text... [Slide 59] ... and also gedit notifies Orca when text changes. [Slide 63] So that's how it looks like from a Screen reader perspective. So you have the main window, which may have a vertical container, and then you have a menu bar with menu items, and then you have a horizontal container with a text area, an OK button. And so, the screen reader has access to the tree of widgets. [Slide 64] It can work quite well, and it does so... Well, the console is just text. For graphical applications, it does work really well with gtk 2 and 3. Qt4 was not so good, they mostly have left it as it is. Qt5 is being worked on and is really improving. We have Java also working. Acrobat... Adobe did implement some accessibility in the Reader, so it does... it did work at least, I haven't tested lately. A lot of other applications are not... So notably old Qt applications, the venerable Xt applications, and also of course the the applications which render their output directly. So Xpdf is not accessible at all. [Slide 65] In practice it's not just because you have your application in Gtk that it is accessible. Because for instance here, we have a dialog box with "First name", "Foo", "Last name", "Bar", etc... [Slide 66] ... but if it is programmed this way, that is we have a first column with label "First Name", label "Last Name", label "Password", and then a second column with text "Foo", text "Bar", text "Baz", you don't remember which one is which: is it "Foo" or "Bar", "Last name", "First name"? I don't know. And so it's really not usable, even if technically it is accessible, in practice it's not usable. [Slide 67] And so you would much better use label "First Name" for text "Foo", so you make a relation between the label and the text. And then you have put the semantic into your application and so the screen reader can work. [Slide 68] In case you have not done your work, what happens in practice is that in the screen reader we would implement a script that takes that information and knows that "ok, they are related together, I know that, and so I put them together." And this is what we would like to avoid, not having to write scripts in the screen reader, because of course as soon as you add something in your application, then the script is outdated and it doesn't work any more. So you really need to do things logically. [Slide 70] So that's the idea: don't try to make your application accessible, just make accessible applications, from the start. And quite often it's just common sense. Well of course it doesn't mean you shouldn't fix your existing applications. But if thinking about it, which way of thinking I have to keep to make things accessible from the start. [Slide 71] For text applications, there are just a couple of things. So text really works great, so if you have something implemented, make a library so that you can have both a graphical and a text interface for it. And for text, do put the cursor where it does matter. So that the screen reader will know that this is where the user should look at. [Slide 72] For graphical applications, ideally you would design your application *without* thinking about graphics, without thinking about rendering, just making it logical, just like css thinking. And use standard widgets, so as I said use a *labeled* text field instead of a label and text field. Avoid homemade widgets, because then they will not be accessible, or you may implement accessibility for them. And always provide alternative textual content when you have for instance a picture or something like this. And of course, keep it simple. That will be useful not only for accessibility but also for all your users. [Slide 73] A couple of traps... You shouldn't have to use the mouse, you shouldn't have to use a keyboard, you shouldn't have to use anything, you should be able to do everything with all kinds of input. Of course, take care of contrast. Make colors configurable. That's one thing: make things configurable, in general, so that the user can tune the way he prefers. Avoid timing-based things, people have the need for time to understand what's happing, so don't make time things. Do not organize 2D things, just organize logically, and it'll work. [Slide 74] Juste a couple of tools... [Slide 75] For textmode, you have http://brl.thefrecat.org/ which provides a tutorial for this. [Slide 76] There is documentation on the same website. [Slide 91] You can text yourself with Orca, you can enable a braille monitor so you can see what is actually showing up on a braille device. Of course you can crash-test: you can turn on speech, and then try to use your application, and then you see that it's really hard. [Slide 92] Accerciser shows you the tree as the screen reader sees it, so that you can check that everything shows up, all the information. [Slide 101-102] About bugs, you will read about it later, it's a bit long to explain. [Slide 111] To conclude, accessibility is really a concern for a lot of people: 10% people would say that they have major concerns, but 20% would say "some of the things I can not do because I can not", and they would not consider themselves handicapped, but still some things they wouldn't do. Quite often it's just a question of common sense: do things logically, simple, configurable, and then it will be nice for everybody, not only people who have disabilities, but also your regular user. We just need to raise awareness of this so that everybody thinks about it all the time. Thanks. [Claps] Questions? {So I have sort of thought about it myself, and what you often see is... For certain reasons because it's[...] about braille... Everything is different and you have special [...] in making accessibility tools for handicap. But they always have to [...] specific, [...] they always have to implement it for the patient in specific, because they have specific needs.} I'm not sure I understand the question, but you are saying that in some cases you have to make specific implementations because this {Yeah, it's really expensive BTW also, because often you have to make a explicitly specific accessibility tools for that patient in specific} You you say in some cases you have to make something specific for one person? {Yeah, in most cases actually} Ideally your software is configurable enough so that yes, you have to tune it for one person, but at least you can do it, and for me it's quite of a new job, for practitioners for physicians, to say "OK, I know that this software, this software, this software exist, I will take this one for you and adapt it for your needs. For me that's perhaps some kind of new job, yeah. But at least they won't have to deal with the code, and it's much easier to get people doing it. That's the way I see it. Of course in some cases you will have to use dedicated software because even if the software is configurable, you can not get up to the task of making it usable for *that* person, and then yeah, it's expensive. But at least for 99.99% people, maybe you can have that way with configuration. {One more question?} {Wouldn't supporting software could be the [...] answer, that those screen readers and stuff for example, for images, the IA solution that learns, you know, what does the image contain, and you know, as we designer are going out [...]} I'm sorry I couldn't hear everything {OK} It's just a question of loudness, please speak louder. {OK, so wouldn't supporting software would be the better answer that are already existing for them, you know, screen reading, and stuff [...] There are screen readers for blind people that read a lot of text on the page already. And there could be AI solutions you know [...] images [...] make better support software.} I'm not sure to understand the question, you're saying that perhaps we could make Artificial Intelligences which are able to understand the software, so that the person can use it? {We don't have the time...} [Slide 63] I'll just say: even with that things it's really difficult, so I don't see more easy with Artificial Intelligence.