So... Good morning!
So, I will talk about accessibility today.
We have a lot of desktops in Debian and we would like to talk
about the accessibility of these desktops.
There are all the slides and various stuff on the wiki of debian.org
in the accessibility-maint wiki page, so you can get stuff from there.
So, just to give an outline, I will introduce to accessibility,
then explain how the accessibility stack works,
how you will interact with this, with your desktop,
and provide you with a list of things that you could check by yourself,
to make our life easier, I mean the accessibility team life.
To start with, this is the output of gnuplot.
Can somebody tell me what the accessibility issue is there?
Yeah, you have green and red bars.
Why is it a problem?
Well, basically color blind people can not distinguish between both.
Just to give you an idea. How many people here are colorblind,
can not distinguish at least some colors?
So we have one, two people, out of a couple of dozen.
Indeed, it's 8% of the male people who can not distinguish colors.
More or less, it depends: some people can distinguish a bit, others really not.
I had a student who really could not distinguish them at all,
so in the practice room, he would have to ask his neighbour
"but which one is the red curve?"
Gnuplot 5, yeah! They changed the color set.
This was actually a research paper which said
"OK, this is the proper color set that you can use and really
almost everybody on earth can distinguish them,
except those who can not really distinguish colors at all,
and still with the intensity of the color, you can still distinguish."
So, yes, things get improved.
It's not so difficult, it's just a matter of changing the colors,
but the most difficult part was knowing about the problem.
What is accessibility?
It is contracted into a11y. It means being usable by
people with specific needs or specific conditions or anybody actually.
So of course the obvious is blind people, but also people with a low vision,
so they can actually see the screen, but not that good.
Deaf people is not much a concern with a lot of things, but still
if you only signal something through noise, then they can not get it.
Color blind, as I said.
People may have just one hand, and to type control-alt-backspace,
with just one hand, it's really horrible.
Cognition issues, so people may have problems with understanding your software,
just because they can not,
it's not a problem of making efforts, it's really a health issue.
Motor disability, so it becomes difficult to use a keyboard
when you have Parkinson, for instance.
And elderly people, who basically have everything at the same time.
You can have a look at the accessibility HOWTOs, which talk a bit about all of this.
Maybe that can be you, maybe within a couple of decades,
because of getting older, but also if you break your arm, or whatever.
So this is really something which is for everybody,
not only a small part of the population.
And still, there was a survey which shows that
10% of the people consider that they are handicapped in their life,
and then 20% consider that they are limited.
They can do everything they want, but it's a pain, quite often.
Handicap depends on the situation, maybe it's just,
you may break your arm, or you are too small to get something,
or you are too tall to get into a room or something,
so it's not a problem of the person, but of the situations.
And it's not necessarily permanent, sometimes it's just
you broke your arm for some time, and then you're back to order.
And for me, this is all about freedom 0.
We have been discussing with Richard Stallman about this.
The freedom 0, as he said, was the
"freedom to run the program, for any purpose".
But OK, running the program is not really useful if you can not use it.
And RMS said yes, "it's just a desirable feature that you can use it",
I mean because you're disabled. Is that only "desirable"?
Richard said, "well if you need it, then you can modify the software, it's free".
Okay, but that can not happen, I will explain that later.
Just to give the UNO rights.
So I put in bold the interesting part for us.
So there are rights of persons with disabilities, and it says that
"Discrimination on the basis of disability" means any distinction, exclusion or
restriction on the basis of disability which has the effect of
impairing exercise of all human rights and fundamental freedoms,
in all kinds of fields, and that includes denial of reasonable accommodation.
And that's the point I want to emphasize:
if you are not doing the reasonable accommodation, you are actually
excluding people, and that's something that the UNO considers.
And what does it mean, "reasonable accommodation"?
It means not imposing a disproportionate or undue burden.
So we don't ask the Debian project to do a lot things,
we just ask for reasonable accommodations.
And we are trying to see what we can do like this:
making things easy for Debian maintainers, so that they have to do it actually, in a way.
For us it's then a question of priority in the project,
for us it's a bit like internationalization,
it's basically the kind of the same issue, and everybody has to do it
for his own language, every package should have it, etc.
But then more importantly, it's a question of who doing it.
Accessibility is a problem in that
it concerns a really small fraction of the people using computers.
They already have a hard time using computers,
and it's even worse with accessibility issues.
And the thing is: since there are not so many disabled people,
almost nobody has these disabilities and the programming skills to fix them.
And still, if you have the programming skills, it's extremely difficult,
like for instance if you want to make the Debian Installer accessible:
OK, you get the CD, you run it, and then you don't have any output
on your Braille device.
What can you do?
You have to first get a debugging environment,
but nobody thought about having a debugging environment without a screen,
so you have to invent that first.
So it's really difficult for people with disabilities
to get their things done by themselves.
Then you will have sighted people for instance who could work on it,
but people with sight and the awareness of the issue and
what could be done about it, it's even smaller.
And so this sentence "this is free software, you can modify it"
that can not work.
Because there are not so many people, they can not do everything.
So the support has to be actually integrated into the process and
the load of working on it distributed among the maintainers.
Of course we would like to make that load as light as possible to maintainers,
but there is no way around fixing bugs in applications,
so that the tiny accessibility community doesn't have to do all the work.
Ok, so that was just an introduction to accessibility in general.
Let's talk about hardware.
People may use for instance braille input and output,
or speech synthesis, but that's mostly for blind people.
People with motor issues can use just one joystick which would replace a mouse,
or would just be able to press a button, and that's still enough to get things done,
thanks to a virtual keyboard.
Or they could use just eye-tracking, and by blinking their eye actually acknowledge,
and whatnot.
We have a lot of ways for people to interact with a computer.
The thing is, one shouldn't focus on just one technology.
For instance, even for blind people, Braille is not perfect,
just because not so many people know Braille actually.
I don't remember but it may be like 10 or even 5 percents of the blind people
only know Braille.
And the Braille devices are already extremely expensive,
like several thousands of euros.
Speech synthesis either is not so good in a lot of cases,
like if you have a noisy environment, you can not hear it,
or you are disturbing your neighbours.
And also, it's really tedious to get words spelled,
because you have it letter by letter,
it's much less convenient than reading it on a Braille device.
Just to show what it looks like, so a Braille cell.
Usually you have 8 dots like this, which make for one character.
And the dots are moved upside and down thanks to a Piezzo bar,
which is why it's expensive because that Piezzo bar
has no other use in the Industry, and so it is really a little market.
A Braille device is simply that kind of cell, replicated alongside,
and connected through serial, USB or bluetooth, and the price is usually
the number of cells you have times a hundred and fifty euros.
So for forty character displays, you have to pay like a few thousands euros.
So it's really awfully expensive.
About software. So it's more interesting for us.
The first question which is interesting is
"why would you take the burden of making the GUI accessible?"
There are a lot of text applications, you could do everything with these.
Well, not everything, that's the problem.
A lot of things are really not available in textmode,
like real JavaScript support in textmode is actually really difficult because
it doesn't sometimes even make sense for JavaScript
to have just characters and not pixels.
And for business applications usually you have just the graphical one,
and you don't have the text equivalent, so you have to have a way to use them as well.
And what's even more important is that you shouldn't make people use
a dedicated software because then they don't have help around them,
because they are using their software and nobody knows how to use it, except them.
And that's really a problem, because then they cannot be helped by people.
Another idea is
"let's make accessible software which is dedicated to people with disabilities".
So for instance we have edbrowse, which is a blind-oriented editor and browser,
and this is generally a bad idea.
Well, for one because quite often, this is dedicated to one kind of disability,
one kind of situation, and it's not universal,
you would have to do it several times for each kind of disability.
But then also it's just a problem of manpower,
as I've said we don't have so many people working on this kind of thing,
and so for instance if you wanted to maintain a web browser,
you would have to implement JavaScript, flash, tables, CSS, etc.
So you don't really want to do that.
Or for an office suite, have compatibility with Microsoft and whatnot.
And also it's also again an important thing which doesn't come to mind first.
The important thing is not only getting help, but also working with people.
If you have the same software, if you are used to use the same software,
then you can work together,
you don't have to play with format conversion or whatever.
Or even just work at the same time on the same software, pointing at something,
then reading what is happening there,
then interacting with the other one within the software.
So that's why we should really make the existing software accessible,
instead of writing new software.
Another important thing is: we shouldn't make "accessible" distribution.
Well, it can be a good idea, but in the end we want all distributions to be accessible.
Because accessibility is completely orthogonal to any other concern,
like blends and tasks, this is orthogonal with accessibility.
Just like, be it a musician, for medicine, for teaching, whatever,
all these specialized distributions should be all accessible.
So it doesn't make sense to make an "accessible" distribution,
except as being a testbed for experimental features,
but maybe want to push to users to make them happy and test these things,
and then we can integrate them into all the distributions.
Ideally, you would have accessibility everywhere.
Like, I enter a library,
there are computers to get the catalogue of the books in the library,
or you get to an airport and they have internet access there, but on a computer,
or you get to the university and you have the practice room.
All these situations, if you have just a Braille device,
then you will have to ask the administrator to install the software and configure it
and whatnot.
We do not want that, you shouldn't have to ask the administrator,
because he's probably not there and you would have to wait for a week or a month.
So ideally it should be just installed by default, and ready for use.
So that means quite close integration with the system,
but for instance we managed to get this in the Debian Installer.
Nowadays, the standard CDs, installation CDs of Debian,
it's just, you insert the CD, you boot the computer,
you hear a beep saying "you're at the boot menu, you can press enter",
and then d-i boots and then it is actually showing the output on the Braille device.
So that's really the kind of things we want to achieve.
[claps]
Thanks!
Just a couple more of design principles
As I mentioned, just use the same software, make it accessible.
Synchronize work, as I said it's just an alternate input and output
and we work together in a synchronized way.
And be pervasive, so you shouldn't have to ask
for software installation or configuration.
Ok, so that was discussion.
Now the real stuff.
How it looks like, how it works, and what we could check.
In a few words, text mode is really accessible but at least for one
it's not suited to beginners.
Gnome is quite accessible.
One issue we had with was gnome 3, which was almost a restart from scratch.
The status of gnome 3.0 was really awful.
Nowadays, we got to the point almost like gnome 2 before gnome 3,
but it was really a pain.
And in the end we are really late compared to the Windows world,
we have like a decade...
we are a decade late compared to them.
And compared with the Apple world we are really at Stone Age.
You have to understand that Apple has integrated and good support
for accessibility.
It's always installed, it's ready for use all the time, and it's really good.
We really see people who were using free software etc.
and then eventually they saw that Apple thing, and they said
"OK, it's really working much better than free software, so I will switch to Apple".
This is really a shame for us,
there is no reason why we shouldn't be able to do that good.
More technically, how does it work?
The idea is that we have the application, a standard application which uses
its own abstract representation through the toolkit, to render things visually.
And the idea is that we have a bus, an accessibility bus
which can exchange with that abstract representation.
And the screen reader can just go through this bus to access
the text of the application,
and then render it on an accessibility device, whatever it is.
Is it Braille, is it speech, is it something else, I don't know,
but the idea is that it's generic so that we don't have to know.
So, just to give an instance, we have the X server,
and the gedit application renders pixmaps to the X server,
it is pango which does the rendering, but there is in GTK, inside GTK the text,
which is what we want, and so there is a part of gnome which is called ATK
which plugs into GTK to get that text and provide it to the screen reader,
on Linux it's called Orca, and then Orca can output this through braille or speech.
So we have this bus between ATK and Orca,
it is basically an RPC bus, actually, so that is:
Orca can ask for the text explicitly or it can ask for getting
notifications about the changes,
so once it's registered, ATK sends messages whenever text is modified,
so Orca doesn't have to poll for changes.
And so it means that it's only on request from the screen reader.
So if there is no screen reader then there is no message on the bus,
so it's quite lightweight when the screen reader is not there.
The idea is that the screen reader gets the abstract representation as a tree,
so we have the main window, with maybe some container,
and then have the menu bar with several items in them,
and then a text area, an OK button, etc.
So that's the idea, the screen reader really has the representation of the application,
and then the user can go around it.
So, technically speaking, now.
A lot of applications are already technically accessible in that
the textmode applications for instance, you can always get the text for course.
GTK 2 and 3 are accessible, it's improving over years,
it's really in a state nowadays, which can be used for everyday work.
And KDE is, I mean Qt actually, has been trying to push for accessibility
for a long time,
Qt 4 had some implementation which was a bit sketchy, with Qt 5 it's much better.
So it is on its way to get really accessible.
Mono, however, had an accessibility effort but Novell actually basically fired
all the team, the Accessibility team in 2012 or something.
And so it's not maintained any more, and it has been removed from Debian
because it was really not maintained.
So, let's see. Acrobat reader is actually accessible.
Adobe made the effort of plugging the rendering of the PDF file into ATK,
so that the screen reader actually gets the content of the PDF file.
And then you have the other applications, so Qt3, or Xt,
or applications which draw things themselves, like xpdf,
these are really not accessible at all.
To give an idea in Debian, of the stack, we have brltty
which contains the drivers for braille,
we have speech-dispatcher which manages the drivers for speech.
Then for the bus, the accessibility bus, we have the server part
which is at-spi2-core, which is generic, all toolkits use it,
and then you have the GTK-ish part of it which is gail and libatk.
And on the Qt side you have qt-at-spi.
And in Qt5 it's actually integrated into the core of Qt.
And then you have the screen reader, which is called Orca.
So basically, once you have all this installed,
you have the whole stack for accessibility.
So, what do we want to achieve?
Which is where I will be asking you for trying to do things.
What is the goal?
The goal is at the very least, having the accessibility stack working on all desktops.
That is, you can actually run it and it works.
It is a matter of a few tests, I will explain that,
so that you can actually include them in regression tests.
That would only allow to access some applications, but that's already huge,
in that if it's all desktops which have it, then a blind user for instance
is not afraid of asking, like a neighbour or a coworker, or whatever
"can I use your computer, just to read my mails or whatever?".
It will not be convenient for the blind user,
but at least he will be able to work with his coworker or whatever.
That's already huge.
And then of course the graal would be that all desktops would be
completely accessible.
I understand that this is not achievable but that's really the target we would have.
So that, you would just be able to choose your desktop.
So this is more involved, I'll explain later.
Getting the accessibility stack working...
The goal is that you just run Orca and it works.
Whatever situation you're in, you have already applications running, and whatnot,
and you just start Orca, and you manage to read the existing applications.
At the moment, this is not enabled for all toolkits,
it is enabled by default in GTK3, actually, in Jessie, so it does work with GNOME.
But not with GTK2, Qt4, Qt5, there is often people who say
"yeah, but there might be bugs, it may make things slower".
Ok, but we are at the beginning of the release, err.
the development of Stretch, maybe it is the time to just enable this,
and if there are bugs, let's just fix them, there is no way forward except like this,
we've been not enabling accessibility for like a decade,
and maybe now is the time to just do it, and then...
[round of claps] [smile] Thanks!
The question is: how do you test it?
I'll explain the details, and then you'll see that we provide scripts
to do it for you.
The idea is that we have that accessibility bus running,
so there are some dbus daemon running, you have to check that they are running,
there is a script which does that automatically normally,
but maybe it does not for your desktop,
and when it is running, you have actually a dbus specialized bus, for accessibility
and the session bus should be providing its address so that applications can find it.
And also there, the Xorg root window provides the address as well.
And then we have to have the toolkits enable their layer for accessibility.
All of this is actually checked with a small script that I've written
and it is available on pkg-a11y.
There are pointers to this on the wiki page, accessibility,
that wasn't -devel but -maint, but there are links between
accessibility, accessibility-devel and accessibility-maint,
so you should be able to find it.
The idea is that you clone this repository.
There is an env.sh file which you can source
to basically define all these variables to enable accessibility in GTK2, Qt4, Qt5, etc.
and once you have this you can run "make check" which runs
GTK2, GTK3, Qt4, Qt5 applications, and check that they are really accessible.
If they are not, or for users who can not manage to get their thing working,
there is a troubleshoot script which tests every bit one by one and tells you
"this is not properly configured, maybe that's the issue actually".
And also you can run "orca -l" to get the list of applications,
so it's a quick test really so you can just run, like,
geany or gedit or whatever GTK application and check that "orca -l" sees that.
If that's the case, then probably the accessibility stack is working properly.
OK, so that was the part that you can do, the first part that you can do.
Another part is how the user will start Orca.
So of course, in the "foreign user" use-case,
so a disabled person uses the desktop of somebody else,
he can ask the somebody else to run Orca for him.
But a shortcut would be really welcome,
for instance when you go to a library or whatever, he wants to use a computer.
Gnome settled on using super-alt-s to just start the screen reader.
Our concern is that OK, gnome chose that, maybe KDE will choose something else, etc.
It would be extremely convenient to have just one so that you don't have to ask
"Which desktop is that? Alright, this desktop I remember that it is that shortcut".
So the problem we may have, I don't know, is deciding on a universal shortcut
which doesn't conflict with any other shortcut in any other desktop.
So I don't know, maybe super-alt-s is already fine,
maybe that's something that should be discussed at freedesktop, I don't know.
I really don't know for this.
For the installer, for instance, at the boot menu, you would type s and enter
to select the speech-enabled installer.
So maybe just try to have just one.
And maybe also we could autostart it when you plug a USB Braille device.
That may be useful, but as long as we have super-alt-s
then we are fine with starting Orca, so maybe it's not so much worth
spending efforts on autostart on plugging USB Braille display,
and really get that shortcut running.
For the regular user, you want of course Orca started automatically,
you don't want to have to start it by hand each time you want to use your own computer.
The thing is: there should be at least two things.
There should be an icon in the interface so that, like,
the administrator of the machine enables it easily, finds it easily,
and that icon also should be accessible, just because the disabled person
might want to interact with it.
That hasn't been always the case.
Sometimes the accessibility icon was not accessible in some releases of software.
And the second thing is having a command-line interface for enabling it.
Quite often it is the case, but the thing is: please tell us which one
we should use in the Debian installer, so that when
the user installs Debian with accessibility enabled in the Installer,
then we enable accessibility in the installed system automatically.
We are fine with having to deal with gconf, gsettings, xfconf, whatever.
Just give us the way to do it and document it, so that we can do it.
Eventually, we would like all desktops to be completely accessible.
So that means making, like, the start menu, the panel, task switching,
all these tiny bits of the desktop to be accessible.
So if your desktop is based on GTK/Qt, it's quite easy
because the toolkit does it for us.
You should still check out what Orca and Accerciser are saying,
I will explain that a bit later.
And also that everything can be achieved by using just the keyboard.
It's really important, some people just can not use the mouse,
and they can see and can use the keyboard, but also blind people really like
being able to do everything with the keyboard and speech output.
And if you can do that, with just a keyboard, no cheating with the mouse,
then that's already quite good.
If some of the parts of your interface, your desktop interface, are self-drawn,
not using GTK or Qt, then you will have to implement accessibility yourself,
so interface with AT-SPI, maybe by using ATK, or talking AT-SPI protocol natively,
yourself, it's up to you.
But that's the kind of drawback for using a self-drawn widget.
At the moment, mostly only Gnome and MATE are really accessible like this,
I mean really usable with a keyboard, shortcuts, etc.
XFCE and LXDE start being accessible, they don't always have shortcuts,
so we wouldn't recommend these, so basically people only have
two choices for desktop at the moment.
That's really sad.
To develop accessible applications, more generally,
the idea is that you should not design your interface with the GUI in mind,
but rather start with a logical way of thinking about your interface, first.
Because then, the screen reader, since it is that structure of the application
and not the visual representation, it will be easier for disabled people.
And actually in the end, it will make your code much better,
to make it structured logically instead of graphically.
And as I said, better use standard widgets,
because then they have integrated support for accessibility.
And also, make sure to use the proper widget for what you want to do,
so for instance if you have a text field to be filled,
and then a label in front of it,
you should use the labeled text field widget, which makes a relation
between the label and the text.
Otherwise the screen reader just notices labels and text,
it doesn't know which is which.
So avoid homemade widgets, or you have to implement accessibility yourself.
And if you put an image, of course, provide a text alternative
for the screen reader to give to the user.
And keep it simple.
For people with cognition issues, but also for blind people,
if there are too many things, too complex dialog boxes, or whatever,
it will be tedious for them.
But it's also for your regular users,
if the interface is simple, then it will be easier for them.
Quite often you ask "OK, but I would like to test myself".
Orca has a braille monitor, so what you can simply do is running
"orca -e braille-monitor" to enable it,
and then just work as usual with your desktop,
only using the keyboard, don't use the mouse,
and then check that whatever you are doing appears on the Braille monitor,
and that it is correct.
And there is a crash test that you can do, it is to just turn on the speech,
and then switch off the screen, and then to try to work.
And you are... [they are trying to tell something but... Oh sure, sure].
So try to just switch off the screen and work, and you will see that it's difficult.
Even developers of accessibility who are sighted
don't always do that, and they realize, when they do that,
"OK, there was one thing which I didn't realize that it wasn't working,
just because I could see the screen".
There is on gnome.org a guide for developing accessible applications,
you should have a look at it, it's quite interesting.
Then there is Accerciser, maybe you will not use it because it's a sort of debugger.
The idea is that it shows the tree of widgets,
and you can have a look at the details and check the properties,
that the text is really right, or whatever.
So you can try to use it, but most probably you will want to just use Orca
and check quickly what is showing up.
One last thing, about bugs.
One thing to understand is that the users, disabled users,
are in a different situation than you, so if they make suggestions
like in a webbrowser, put brackets around URLs which are clickable,
then do that, at least as an option.
Because it is really useful for them.
You, as a sighted person, wouldn't understand why, but they do know why.
And so OK, make it an option, and the users will enable it.
It's extremely difficult to deal with accessibility bugs,
because it's already not easy for people to use your software,
because of hindrance, or whatever,
but it's even more difficult for them to report bugs,
because they have some output on the braille device or speech or whatever,
and they don't even know what they are supposed to have,
because they can not see what is on the screen.
So it's difficult for them to understand what is happening,
and so it's even more difficult to explain what is happening.
So, yes, the only way out is to discuss, and take the time to discuss,
it's long but there is no other way.
Remember to ask the user for screenshots, they don't necessarily remember to do this.
Try to think about this because it's actually easy for them to do,
they just don't think about it.
And try to keep in mind that their disability and consequences.
It was quite fun, a few years ago, during the discussion with debian-boot,
when we talked about making the framebuffer accessible, some person said
"OK, but then if the framebuffer doesn't show up nicely, the user
will not be able to report the bug about the framebuffer not showing up nicely."
OK, but he doesn't care, he won't see it anyway.
So that's fine, we can leave the bug.
So it's kind of situations where you have to think their situation.
You can even just contact a institution near you to discuss directly with users.
There are a lot of them all around the world, so you can try that.
OK, to conclude: quite a few of your desktop users need accessibility,
really need it, in any kind of situation,
so we really want to make accessibility mainstream,
and we can do quite some work, but we need your help for this,
so you're welcome.
Thanks.
[claps]
[Michael Banck] Thanks a lot Samuel. So are there any questions?
[Q] Excuse me, do you know the current status of Chinese,
Japanese, and Korean support on the Braille display?
[sthibault] So on the Braille display, I don't remember exactly
which Braille tables we have...
Korean we have a table for this, Japanese, we don't seem to have one,
and Chinese we do have, I don't remember where, but we do,
I know that there is a proper table for Chinese.
Japanese, I'm surprised that I couldn't find it, but at least I think
this is something which already works.
It has improved a lot since the desktop went to UTF-8 by default,
so nowadays it's really working, I think.
Not on the text console on Linux, because Linux' support
for double-width glyphs is not really good, but on the desktop yes, it's really working
[Note of transcriptor: there indeed is a japanese table,
along the chinese and real corean tables (not kok!)]
[Michael Banck] Any other question? Well...
[Ksamak] What do you think could be doable at the Debian level, I don't know,
on the archive or process, to, I don't...
for maintainers and developers to be aware when they push something,
that it breaks a feature, or...
[sthibault] Oh you mean if some desktop breaks accessibility support?
[Ksamak] Yeah
[sthibault] Yeah, I was thinking, I've written a note about it,
to make these checks on a VM somewhere,
to run it all periodically on all the desktops,
and then have a red light in the tracker page of these desktops
so that maintainers see that
"Oh, there is a problem here",
and then a link to the wiki page so that they test themselves, and then fix,
or at least ask for help for fixing it.
But yeah, that's the kind of thing, as usual,
making accessibility not a special thing, but just in the usual process,
like all the lights in the tracker page.
[Michael Banck] So I have a question about these special widgets,
did you talk to upstream, GTK or Qt, suggest to disallow special widgets
which are not accessible, or is it not possible technically?
[sthibault] Sorry?
So you said it's problematic if people come up with their own widgets,
and is it, would it be possible to just disallow or block it
if they are not accessible, or is that
a technical solution to a social problem.
[sthibault] Yeah, I think that's one of the issues, I mean, people not aware of the problem.
It is that the development tools not always remind the developer for them, like,
if you run glade, and do an interface, it should prevent, give a warning
"You didn't put an alternative text for an image", etc. and yes....
But when people write C code, I don't know how to tell them that that's bad.
[Michael Banck] Are there any other questions? Yes, one?
[Q] So you talked about you have to turn on the accessibility in the installer,
I have no idea?
[sthibault] Sorry I couldn't hear.
[Q] You talked about, during the installation,
people might press s or something to turn accessibility on.
I think Apple have it turned on by default, I mean...
[sthibault] Well, Apple has it available by default, yes,
and you have to type a shortcut, I don't remember the shortcut for Apple,
but yes, it is available all the time on a mac, and on the phone as well.
[Q] Well, I was thinking in a minute, it's no big deal for me if you turn it on,
at my computer start...
[sthibault] Wait, when I say turn on, that means,
start talking and blabber, so it will make noise [giggles]
[Michael Banck] Any other questions? Ah, there is one.
[Steve McIntyre] So the installer, booting off CD, kind of beeps at boot,
has anybody checked UEFI boot to see if that works the same way?
UEFI, if you boot the installer CD, I honestly don't know,
I haven't thought to check until just now, whether it works if you boot
via UEFI instead of the old bios.
[sthibault] I think it's really independent of the firmware.
The only think is the boot menu where we do have to have a beep.
Exactly.
[sthibault] And that's something I didn't test myself.
[Steve McIntyre] So for UEFI we boot grub instead of isolinux.
I don't know if grub does a beep.
[sthibault] grub does have a driver for PC speaker,
so it can beep actually.
I'll just write a note.
[Steve McIntyre] If you can check that, let me know, and we can fix it
if it's not working.
[sthibault] Thanks.
And I was happy to notice that the liveCD of Debian
actually has the same kind of beep.
I don't remember asking for it, so it really shows that things are going.
[Michael Banck] OK, so we are running out of time, so let's thank Samuel again.
[claps]