Thanks for maintaining a desktop environment, but is it accessible?

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 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 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 reach there, 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,
improving over year,

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 has 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 goal 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 checks

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 you.

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 Gnomeand 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,

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

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

if they 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.

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 it's turned 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,
wheither 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 if grub does a beep.

[sthibault] grub does have a drive
of the 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]