|
|
(2 versions intermédiaires par 2 utilisateurs non affichées) |
Ligne 1 : |
Ligne 1 : |
| [[Catégorie:Transcriptions]] | | [[Catégorie:Transcriptions]] |
− | | + | transcription publiée : http://www.april.org/comment-fonctionne-laccessibilite-des-logiciels-rmll2014-conf-de-samuel-thibault |
− | ==Présentation==
| |
− | | |
− | * conférence donnée par Samuel Thibault
| |
− | * date : 10 juillet 2014
| |
− | * lieu : Montpellier
| |
− | * lien vers la vidéo : [http://video.rmll.info/videos/comment-fonctionne-laccessibilite-des-logiciels/ RMLL2014 Samuel Thibault - Comment fonctionne l'accessibilité des logiciels ?]
| |
− | * licence :
| |
− | * Transcription : https://2014.rmll.info/slides/259/2014-07-devel.txt
| |
− | * durée : 37min
| |
− | How does software accessibility work?
| |
− | | |
− | [...]
| |
− | ==copier coller du fichier. relu par Véronique Bonnet==
| |
− | | |
− | | |
− | | |
− | [Slide 4]
| |
− | | |
− | Ideally you're never in a handicap situation, just because the tools you are
| |
− | using are just fine, and it's really the situation which makes you not at ease
| |
− | with doing something, or making it impossible for you to do some things. And
| |
− | it's not necessarily permanent. You may break your arm, and then you have only
| |
− | one hand to type, it's not convenient, etc. etc. So you never know, it may be
| |
− | anybody anytime.
| |
− | | |
− | [Slide 5]
| |
− | | |
− | So, let's talk a bit about some hardware.
| |
− | | |
− | [Slide 6]
| |
− | | |
− | Just to show some examples. So of course there is braille, and speech, for blind
| |
− | people. There are also joysticks which can replace the mouse, because it's
| |
− | easier to move with just a few fingers. You may just have one press button, and
| |
− | then still you can manipulate for instance some on-screen virtual keyboard. If
| |
− | you really can't move anything, you can still track the eye, and blink the eye
| |
− | to click, thinks like this.
| |
− | | |
− | [Slide 7]
| |
− | | |
− | The thing to understand is that one shouldn't focus on just one technology and
| |
− | say it will work for everybody. That is never the case. For instance, Braille is
| |
− | not perfect, just because at least not everybody can read and write Braille.
| |
− | Even among blind people, I mean. Only few people actually read and write
| |
− | Braille. And this is extremely expensive. I will show later.
| |
− | | |
− | Speech synthesis is not perfect either. Well, at least just because sometimes
| |
− | you can not hear it, because it's noisy outside, so you have headphones, but
| |
− | it may not be convenient, etc. But also just because it's not so accurate, so
| |
− | precise. For spelling, it is really tedious to have words spelt, while with
| |
− | Braille, you just read, and have the spelling.
| |
− | | |
− | So, nothing is really perfect, even for a given kind of disability.
| |
− | | |
− | [Slide 8]
| |
− | | |
− | So, just to show what Braille devices look like. So this is just one cell, and
| |
− | so eight dots to show one character. And the idea is that you have these piezo
| |
− | bars here which bend up and down to raise or lower the dots, and so you have
| |
− | eight of them, so you have eight dots.
| |
− | | |
− | [Slide 9]
| |
− | | |
− | And this is awfully expensive. So a Braille device is typically like 40 cells,
| |
− | and the price is then 40 times 150€, so it's like several thousand euros. So
| |
− | it's extremely expensive.
| |
− | | |
− | [Slide 12]
| |
− | | |
− | About software...
| |
− | | |
− | [Slide 13]
| |
− | | |
− | So, one thing I would like to emphasize first is that generally it's not a good
| |
− | idea to make a dedicated software for a given kind of disability for instance.
| |
− | For several reasons.
| |
− | | |
− | Maybe the main one is that you will have to maintain this software. So the
| |
− | example I show is edbrowse. So it's a browser for blind people, but then
| |
− | does it support javascript, does it support flash, does it support this and
| |
− | that... And nowadays it's really difficult to write a web browser, because you
| |
− | have to implement CSS and all these things... So you can not really maintain
| |
− | that. For office suites, it's even worse to maintain the compatibility with
| |
− | office, Microsoft office, libreOffice, etc. You don't really want to implement
| |
− | everything yourself.
| |
− | | |
− | And the other thing is that if you make people use another software, something
| |
− | which is not mainstream, then they can not discuss with people who use the main
| |
− | software, because they don't understand each other, the interface is not the
| |
− | same, maybe items are not called the same, and when they are working together,
| |
− | on the same computer, then one or the other is not at ease with the software,
| |
− | because he is not used to it.
| |
− | | |
− | So it's usually really better to make existing software accessible.
| |
− | | |
− | [Slide 14]
| |
− | | |
− | So, just to explain what we have nowadays.
| |
− | | |
− | So, text mode, it works quite well. Just because it's text, it's easy to make it
| |
− | accessible. The thing is, beginners don't really like textmode usually. We often
| |
− | hear people saying "OK, let's just make text interfaces, and then it will be
| |
− | fine for blind people". Well, maybe for technicians, but for the average blind
| |
− | person in the street, they don't like textmode. They don't want to type commands
| |
− | etc., they prefer to have something intuitive. So of course, you could make them
| |
− | learn etc., but in practice we don't see that working.
| |
− | | |
− | So, we have to make graphical interfaces accessible. So, about Gnome, it's quite
| |
− | accessible in that it has started like a decade ago, and it's really quite
| |
− | usable nowadays. One of the issues we have met is that for instance Gnome 3
| |
− | was a complete rewrite of a lot of things, and accessibility was not really a
| |
− | priority at the time, so we had a lot of regression there. So it wasn't really
| |
− | good news.
| |
− | | |
− | Now, compared to what we have with proprietary software, we are really late.
| |
− | Compared to Windows, which started working on accessibility long long time ago,
| |
− | we are really late. Compared to Apple, we are at Stone Age. Apple made a lot,
| |
− | really a lot of effort, to make its products accessible. And disabled people
| |
− | really like iPhones, and MacOS, etc. etc. just because it really does work, it's
| |
− | integrated, you don't have to install new software, make your computer less
| |
− | reliable or whatever, it's really good and integrated. They even have training
| |
− | sessions in the Apple stores. So, they really managed to do it.
| |
− | | |
− | So there's no reason we shouldn't be able to do it, and it's a shame that
| |
− | nowadays, some people recommend proprietary software, to free people with the
| |
− | use of their computer. We should be able to use *free* software, to free people
| |
− | for using their computer.
| |
− | | |
− | [Slide 15]
| |
− | | |
− | So... So I wanted to explain how accessibility works. This is the general idea
| |
− | of how this works. So we have the application here, and for anybody who has
| |
− | developped a graphical application, you know that there is some kind of abstract
| |
− | representation of the application. So you have a dialog box, you have some
| |
− | panels, you have buttons, labels, text, etc. So there is some abstract thing
| |
− | here. And then you have the visual rendering of this which shows up. And the idea
| |
− | is that you have an accessibility bus, which is the way for the screen reader to
| |
− | access this abstract representation. So the screen reader gets the text of the
| |
− | application, and the structure of the application. And then it can display this
| |
− | on an accessibility device, so Braille, speech or whatever anybody would rather
| |
− | use as a way of accessing information.
| |
− | | |
− | [Slide 22]
| |
− | | |
− | So just to give an example, so here we have a window with a vertical container,
| |
− | which contains at the top a menu bar with a file menu with some items, and etc.
| |
− | we have other menus. And then a horizontal container with a text area, an OK
| |
− | button. And this is actually a tree of widgets, which is what is displayed, and
| |
− | what is... what the screen reader can find. And the idea is that the user will
| |
− | just navigate through all of this, to access the content.
| |
− | | |
− | [Slide 23]
| |
− | | |
− | Just to give an example, so we have gedit here, which uses gtk for the
| |
− | rendering, so it uses pango for the actual rendering on the X server, and there
| |
− | is atk which provides the abstract representation through the bus, the
| |
− | accessibility bus, which is called AT-SPI, to the screen reader Orca, which can
| |
− | just show on the braille device, or speech, etc.
| |
− | | |
− | [Slide 24]
| |
− | | |
− | So, technically speaking, applications can be made accessible that way, and so a
| |
− | lot of applications are accessible. So, the console applications, of course,
| |
− | it's just text, so it's easy. Gtk applications, through, as I said, atk and the
| |
− | accessibility bus. Kde and Qt applications are getting plugged into this as
| |
− | well. This is progressing, slowly. This would really welcome some help, but
| |
− | it's improving. Interestingly enough, acrobat reader was made accessible by
| |
− | Adobe, so they really made the effort of making acrobat reader accessible. And
| |
− | then you have a lot of applications which are not technically accessible, just
| |
− | because they don't discuss with the accessible bus, so Kde/Qt 3 applications, Xt
| |
− | applications, so the really old ones. And applications which draw the content
| |
− | themselves, so xpdf draws the content of the pdf itself, and doesn't give the
| |
− | content through the accessibility bus, so it's not accessible. Technically, so
| |
− | there is no way a blind user can access it.
| |
− | | |
− | [Slide 25]
| |
− | | |
− | Now, that was for the technical part. In practice, it's not enough that the
| |
− | information is availble. If it's a mess, then it's a mess, and it's tedious to
| |
− | use.
| |
− | | |
− | So, for instance here, we have a dialog box with just a label, First name, the
| |
− | first name Foo, Last name, Bar, Password, baz. OK, but that's the visual
| |
− | representation, and maybe when the programmer wrote his program, he said "OK, I
| |
− | have first a column with label First name, label Last name, label Password, and
| |
− | then I have a second column, with text Foo, text Bar, text baz". And this is
| |
− | what the screen reader will see: it will not see First name then Foo, and Last
| |
− | name then Bar, and Password then baz, no, no. It will first see First name, Last
| |
− | name, Password, and then Foo Bar baz. And so for the user who is navigating
| |
− | through all of this, when he is on the second column, he will have to remember
| |
− | that Foo is the First name, Bar is the Last name, etc. So it's much better, in
| |
− | the application, to write things with a semantic mind. So, we have a label,
| |
− | First Name, *for* the text Foo, a label, Last Name, *for* the text Bar, etc. And
| |
− | then that gives the information for the screen reader and for the user, that the
| |
− | label and the text are related together.
| |
− | | |
− | So ideally, applications would be written really in a logical way that way.
| |
− | Quite often it's not the case, and so we have this. And that's why screen
| |
− | readers often have scripts, for each kind of application, which reorganize
| |
− | this. That is they tinker with the abstract representation of the application,
| |
− | some sort of patch in fact, actually, of the tree of widget. To say "OK, I know
| |
− | that on this application, label First Name is for text Foo, etc. etc.". So this
| |
− | is a way of not having to modify the application, and be able to read the
| |
− | application. But ideally the programmer would have done things in a logic way
| |
− | and then we wouldn't have to do some scripts like this.
| |
− | | |
− | [Slide 30]
| |
− | | |
− | So. So, generally, actually, don't try to make your applications accessible,
| |
− | because it's hard, you have to modify your application. Usually it's just a
| |
− | matter of making accessible applications. In that, it's deep inside the very
| |
− | thinking of your application, that you have to do it in a semantic way, in a
| |
− | logical way, and then you have the rendering. But mostly it's about making
| |
− | things logical. And so, just thinking about it from the start, then it's not
| |
− | more difficult than doing without having accessibility in mind.
| |
− | | |
− | Of course, that doesn't mean you shouldn't fix your existing applications, but
| |
− | it will be harder to patch your application than, just from the start, thinking
| |
− | about "let's make it logical, etc.". A good reason for doing that way is also
| |
− | that it will be most probably be more maintainable. If you make it logical, nice
| |
− | and everything, it will be easier to modify later.
| |
− | | |
− | [Slide 31]
| |
− | | |
− | So, about text applications. I said it really works great, for braille output
| |
− | for instance, so it's a good idea to always have a text equivalent of some tool,
| |
− | for instance you have a shared library which implements the functions, and then
| |
− | you have several backends for graphical interface, and console interface. And
| |
− | then you will realize that it's also cool to have this tool as a text-mode tool,
| |
− | just because then you can ssh to the server and do the things you would have to
| |
− | do graphically. That's actually a quite common thing we see in accessibility:
| |
− | once you have made something accessible, then you realize that it's convenient
| |
− | for some new usage.
| |
− | | |
− | So this is for the technical part, you have text equivalents to the
| |
− | applications. Then one thing you have to understand is that... So you have 25
| |
− | lines of 80 columns, and the screen reader has to decide what to show to the
| |
− | user, it can not show everything at the same time. And what he does, usually, is
| |
− | to show what the cursor is on. So that's why, in an editor for instance, you
| |
− | have the cursor somewhere, and so the screen reader shows what is being edited,
| |
− | so that works fine. But if you have a semigraphical app, which shows a lot of
| |
− | things, all at the same time, then the screen reader doesn't know what to
| |
− | display. But if you move the cursor to what is being modified, for instance you
| |
− | have a mixer, so sound card mixer, then you just move the cursor to the precise
| |
− | button that is being modified, and then the user has the feedback of what he is
| |
− | doing.
| |
− | | |
− | So just put the cursor as appropriate, so for instance in mutt, the cursor used
| |
− | to be just in the corner of the screen, which is not useful, and then we had a
| |
− | patch to make it put on the line of the message being browsed through. So it's
| |
− | just a matter of doing that, to make it, well, more usable. It's accessible in
| |
− | that you have the text, but it's more convenient if the screen reader is guided
| |
− | by the cursor.
| |
− | | |
− | [Slide 32]
| |
− | | |
− | So for graphical applications, I've discussed a bit about it already... So
| |
− | design your application *without* the graphical interface in mind. Just use a
| |
− | logical order, just like CSS actually. You construct your content in a logical
| |
− | way, and then you have the rendering. This actually a common recommendation that
| |
− | you would find in programming courses, but it's actually important, at least for
| |
− | this, as well.
| |
− | | |
− | And use standard widgets, that is the widgets which is provided by your toolkit,
| |
− | because it's up to the toolkit to then provide the information to the screen
| |
− | reader. So for instance, you have text fields, then the toolkit provides you
| |
− | with a way to label the text field. Don't just put a label and a text field,
| |
− | because then you don't have the connection.
| |
− | | |
− | Avoid to make you own widget, or else you have to make it accessible. It's not
| |
− | so easy, but it's not too difficult either, to make it accessible through atk,
| |
− | but you have to think about it. And if some widget already exists, which
| |
− | provides accessibility, then just use it.
| |
− | | |
− | Alway provide alternative textual content for visual content, it's really
| |
− | simple, but some people like to have nice icons on OK buttons or whatever... OK,
| |
− | this is nice, but always remember to put the text "OK" alongside the image,
| |
− | so that for the screen reader he knows that OK, it's an OK button, and not just
| |
− | "picture of something". So, yeah.
| |
− | | |
− | And keep it simple. Because the user, with his screen reader, will have to
| |
− | browse through all the tree of everything which is in the window, so it's better
| |
− | if it's simple, in a logical order, everything. And actually you will realize
| |
− | that... all users will benefit from this, from making the interface simple, and
| |
− | logical.
| |
− | | |
− | [Slide 33]
| |
− | | |
− | Some pitfalls... So this is actually from the accessibility Howtos that you can
| |
− | find on the web. These are just ideas, there are a lot of things...
| |
− | | |
− | As I said, there is no single solution, so some people will be able to only use
| |
− | the mouse, some people will only be able to use the keyboard, so you shouldn't
| |
− | have to use the mouse for things, you should have shortcuts for this, and
| |
− | vice-versa.
| |
− | | |
− | Take care of constrasts. When you choose colors, choose colors with a good
| |
− | constrast, or even better, make the colors configurable, so that the user can
| |
− | decide which colors he prefers. You can never know which colors a user will
| |
− | prefer. Some users will prefer black on white, some others will prefer white on
| |
− | black. And you can not know, it really depends on the kind of disability that he
| |
− | has.
| |
− | | |
− | Avoid timing-based actions. I remember somebody at a bank, trying to get money
| |
− | from the ATM, and there was a message displayed, for like 2 seconds, and she
| |
− | didn't... she wasn't able to read it. And so I had to explain her, etc. So never
| |
− | use timing-based actions, as much as possible. Or at least make them
| |
− | configurable. For instance the double-click, I do remember back in the old days,
| |
− | when I've seen that configuration box, in Windows, saying "how long do you wnat
| |
− | the double-click to be?", and I was thinking "what's the use?". Well, it's just
| |
− | because some people are not able to click so fast. They have to make it
| |
− | configurable.
| |
− | | |
− | About applications, so don't think about 2 dimension organization, ideally.
| |
− | Because some people will be only able to browse through the application in a
| |
− | linear way, just because they use braille or speech, speech is inherently
| |
− | one-dimension. Or just some people with cognition issues would not be able to
| |
− | comprehend something which is complex, so make it simple. And that will help
| |
− | everybody, actually.
| |
− | | |
− | [Slide 35]
| |
− | | |
− | So, some tools... For text applications, you can test it yourself, so you can
| |
− | just run brltty and a gnome terminal, so there is a documentation for this on
| |
− | brl.thefreecat.org . So you can actually see what the screen reader shows by
| |
− | default, from your application, and you can check that it's easy to use it that
| |
− | way.
| |
− | | |
− | [Slide 36]
| |
− | | |
− | For graphical interfaces, you can check that the application is properly
| |
− | exposing the information. So, accerciser is a tool which shows you the tree of
| |
− | widgets, so you can see for instance gedit, you see that there is the document,
| |
− | then filer, then there is the menu bar, etc. and there are other widgets which
| |
− | are shown, and there you can check that all the information is available as
| |
− | text.
| |
− | | |
− | If you have your home-made widget, then you will see the widget in the tree, but
| |
− | you will see that no information is available, and so you have to implement in
| |
− | atk or whatever.
| |
− | | |
− | You will also see that maybe there are some things that are not useful, maybe
| |
− | here, the filer, you have put a name on this, but actually it's not useful,
| |
− | because for the user it's just a container which doesn't provide information, so
| |
− | just remove the name. And the File menu, however, is something interesting.
| |
− | | |
− | So you check that the information which is useful is there, the unuseful
| |
− | information is not there.
| |
− | | |
− | [Slide 37]
| |
− | | |
− | About documentation... I can recommend at least two. So there are Howtos
| |
− | actually, which are quite old, but they are still quite accurate in that they
| |
− | provide useful advices which will probably be still correct in the coming
| |
− | decades.
| |
− | | |
− | Gnome has written an accessibility devel guide, so for Gtk applications, it
| |
− | explains a bit what I've said about the accessibility bus etc. and then it
| |
− | provides recommandations about how to use Gtk, how to label text instead of
| |
− | having a text and some label next to it, and things like this.
| |
− | | |
− | [Slide 38]
| |
− | | |
− | OK. So now I want to discuss a bit about accessibility
| |
− | | |
− | [Slide 39]
| |
− | | |
− | And just to explain that this is actually all about Freedom#0, which, according
| |
− | to the FSF, is the freedom to *run* the program, for any purpose. But the thing
| |
− | is, you can run the program, but if you are not able to use it, then you don't
| |
− | have freedom#0 actually. Richard Stallman said that "OK, yeah, accessibility is
| |
− | a nice thing to have, it's a desirable feature". Is it just "desirable"? The
| |
− | thing is, if you write some software, and some people are not able to use it,
| |
− | then you are actually excluding them from being able to use your software. If
| |
− | the software is not popular, then you say "fine, not a problem", OK, but you are
| |
− | still excluding some people. And if your software becomes really popular, then
| |
− | it really is a social problem that some people are excluded from the people who
| |
− | can use the software. And then Richard would say "OK, but this is free software,
| |
− | use freedom #1, you can modify it". That. can. not. happen. For just simple
| |
− | social reasons, which I'll explain just after that.
| |
− | | |
− | [Slide 41]
| |
− | | |
− | Vint Cerf himself, basically, he's one of the guys who invented the Internet, as
| |
− | we know nowadays. And he asks, in the communication of the ACM in november 2012:
| |
− | "Why is accessibility so hard?" Explaining that, we have all the technical
| |
− | solutions for making accessibility just work fine etc. How is it that we don't
| |
− | achieve this? And the reasons are not technical. That's why it's so hard.
| |
− | | |
− | [Slide 43]
| |
− | | |
− | Accessibility should be a priority. Just like internationalization, and even
| |
− | more than internationalization. If your software is written in a language you
| |
− | can not understand, at worse you take a dictionary, and then you can translate
| |
− | the words, and "OK, I can see how it works", it's tedious, but at least you can
| |
− | use it. If you can not access the content, then you're screwed, you can not use
| |
− | it at all. So it's even more than an internationalization issue.
| |
− | | |
− | [Slide 44]
| |
− | | |
− | And, maybe the main reason why it doesn't happen is that... Who will work on
| |
− | this?
| |
− | | |
− | The problem concerns only a small fraction of the population, which is already
| |
− | having a hard time using computers. And so, the amount of people who have both
| |
− | the disabilities and the technical knowledge to fix the software, that fraction
| |
− | is essentially zero. You have some people, but they are really rare. And you may
| |
− | have some people with awareness of the issues, and who understand the issues,
| |
− | and have the technical skills to fix them, but they are almost zero, as well.
| |
− | | |
− | So the argument "this is free software, you can modify it", that can not work,
| |
− | because the "you" doesn't exist, or almost.
| |
− | | |
− | So the support for this has to be integrated, the workload has to be distributed
| |
− | among all the programmers, writing applications in a logical way, making the
| |
− | toolkits accessible etc. That part of the job can not be borne by the tiny
| |
− | accessibility community, because there is so few of the people there.
| |
− | | |
− | [Slide 56]
| |
− | | |
− | Just to mention about bugs. It's an interesting thing. It's always difficult to
| |
− | understand what the other one is saying. So two things.
| |
− | | |
− | If a user asks for something, then, yeah, take it into consideration,
| |
− | particularly when it's about accessibility. So people might ask you in a web
| |
− | browser, to put brackets around links. That's just because it makes it easier to
| |
− | find links, because when you are using a braille device, you don't know that it
| |
− | is blue, so you have to have brackets to find this. And if you think as a
| |
− | sighted person, you can not understand why it's useful, and you say "OK, maybe
| |
− | some day I will do it". But no, when it's about accessibility, he is, the user,
| |
− | in another situation, you have to understand that that situation requires this
| |
− | kind of thing, and then you do it.
| |
− | | |
− | And about the bug report itself, well you have to be patient, and both parts
| |
− | have to be patient. The thing is, the user has troubles with using the computer.
| |
− | Most probably because the rendering of the application is not so good on his
| |
− | device, and the thing is, he doesn't understand what he is reading or seeing or
| |
− | whatever, and so he has troubles with explaining, because he doesn't even know
| |
− | what he is supposed to read or see or whatever. And so it's really difficult for
| |
− | them to explain in an understandable way, what the problem actually is. And so
| |
− | the only solution is to discuss. Maybe find somebody in between who is used to
| |
− | accessibility, can actually run the software, and see what shows up, and what
| |
− | shows up on the device, to exchange. But the only way is to just discuss, and
| |
− | not get angry or whatever. Just calmly discuss.
| |
− | | |
− | [Slide 65]
| |
− | | |
− | OK, so, just to conclude, so accessibility is really a concern for a lot of
| |
− | people actually, even if people are not so much aware of it. And usually it's
| |
− | quite common sense and good practice in programming, and most often it also
| |
− | helps everybody. So, yes, spend time on thinking about it, and then you will
| |
− | realize that it doesn't take much time to actually do things in a good way. And
| |
− | then, please help raising awareness of the issue, because we really need all
| |
− | applications to be accessible. Thanks.
| |
− | | |
− | {Je suppose qu'il doit y avoir quelque part une API standardisée au niveau du
| |
− | bus d'accessibilité, est-ce que c'est en amont ou en aval du bus, c'est-à-dire
| |
− | est-ce que c'est le même composant logiciel qui est utilisé sur Qt et Gtk, ou
| |
− | alors est-ce que chacun amène le sien, et s'interface ensuite avec des modules
| |
− | de l'autre, et caetera ?}
| |
− | | |
− | [Slide 23]
| |
− | Alors le standard, qui a été choisi et sur lesquels les gens ont travaillé,
| |
− | c'est AT-SPI. Donc ça c'est le même sous Unix. Sous Windows ils appellent MSAA,
| |
− | mais essentiellement c'est le même principe. Et après, chaque toolkit implémente
| |
− | le bout qui va discuter avec AT-SPI. Donc sous Gtk, c'est ATK qui fait ça. Donc
| |
− | les applications peuvent utiliser ATK directement, ou bien elles peuvent parler
| |
− | AT-SPI si elles veulent. Qt a choisi de parler AT-SPI elle-même, d'avoir son
| |
− | propre composant, mais ça marche quand même.
| |
− | | |
− | So the question was "which part of the accessibility bus is standard, is it
| |
− | before or after Atk, typically?" And the answer is: well, which way you prefer.
| |
− | So Gtk has its Atk tool, which talks AT-SPI, so AT-SPI is really a standard, and
| |
− | applications can choose between using Atk to expose their widget, or they can
| |
− | talk AT-SPI directly, and Qt actually does that, it talks AT-SPI with its own
| |
− | accessibility engine.
| |
− | | |
− | {I think you are very clear about why it's important to make applications
| |
− | accessibile from... To make accessible applications, sorry. But just to say it even
| |
− | more I think we have to think about it as compared to buildings. When you
| |
− | want to build a building, you can see that it's really easier to build it
| |
− | accessible from the beginning, as opposed to make it accessible later. The second
| |
− | comment, maybe you may want to show the difference betwen, in the sound mixer,
| |
− | horizontal bars and vertical bars, maybe you may want to show that, maybe not, I
| |
− | don't know. And then the question, can you elaborate a bit more the difference
| |
− | between Atk, and AT-SPI? Thanks}
| |
− | | |
− | Ok, so thanks for the comments, so the difference between AT-SPI and Atk is that
| |
− | AT-SPI is the communication part, it's just a standard and a bus where messages
| |
− | go through. And Atk implements the part which talks AT-SPI language, actually.
| |
− | So Atk plugs into the AT-SPI bus and talks AT-SPI, and Orca does the same at the
| |
− | other end, and so the information can travel between the application and Orca.
| |
− | So that's the idea. So you can talk AT-SPI directly, with another tool, such as
| |
− | Atk or something else. So the screen reader typically talks AT-SPI directly.
| |
− | | |
− | {AT-SPI, heu, il y a l'équivalent avec MSAA, et, mais pourquoi ou comment elles
| |
− | ne peuvent pas être cross-OS en fait ? Et quelles sont les spécificités et
| |
− | pourquoi est-ce qu'il y a besoin d'une interface de traduction comme Atk qui en
| |
− | fait est une interface de traduction pour AT-SPI qui est encore une fois traduit
| |
− | par Orca. Donc quelle est la fonction en fait de ces différentes couches? Et
| |
− | heu, voilà , ça a l'air compliqué au niveau bas-niveau.}
| |
− | | |
− | Ok, so the question is: how is it that we have AT-SPI on Linux and MSAA on
| |
− | Windows? And why is there AT-SPI and Atk and everything?
| |
− | So it's not the same on Linux and Windows... basically for history reasons,
| |
− | first. MSAA was designed in the 90s, AT-SPI is way more recent, and AT-SPI
| |
− | has benefitted from the experience of MSAA. And then on Windows they wrote
| |
− | IAccessible2, which is the next generation of the accessibility bus on Windows,
| |
− | and they have gotten experience from the AT-SPI bus. So they are not technically
| |
− | exactly the same, but they are almost the same. In the principles and
| |
− | everything, so it would be easy to write a translator between both, for
| |
− | instance. It's... you know, it... mostly for historical reasons. Then, why do we
| |
− | need Atk? Well you don't need, but it's more convenient to use Atk, because for
| |
− | instance if you write your own widget which basically behaves like a text box,
| |
− | then just use the Text box helper of Atk, which will talk AT-SPI etc. and then
| |
− | you will be fine. You don't necessarily want to implement all the AT-SPI
| |
− | speaking, that is: sending the message, update message, etc. It's like a helper
| |
− | for implementing AT-SPI messages... Yes, yes, it's just a toolbox. The interface
| |
− | of Atk is mostly the same as AT-SPI, but in a more convenient way, that is you
| |
− | call functions, while AT-SPI is a communication protocol, so it's about you send
| |
− | a message, you receive a message, etc... Yes, theoretically, AT-SPI can be used
| |
− | by whatever. For instance, brltty which is supposed to access the Linux console,
| |
− | we have written a driver which talks AT-SPI to be able to access terminals,
| |
− | graphical terminals.
| |