-
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]