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 browse, 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 against 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.

[Slide 23]

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.

[Slide 24]

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 should 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!

[Slide 25]

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.

[Slide 26]

Ok, so that was discussion. Now the real stuff. How it looks like, how it works,
and we could check.

[Slide 27]

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.

[Slide 53]

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.

[Slide 58]

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 [Slide 59] or it can ask for
getting notifications about the changes [Slide 60], 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.

[Slide 64]

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.

[Slide 65]

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.

[Slide 80]

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.

[Slide 81]

So, what do we want to achieve? Which is where I will be asking you for trying
to do things.

[Slide 82]

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.

[Slide 83]

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!

[Slide 84]

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.

[Slide 85]

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.

[Slide 86]

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

[Slide 87]

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.

[Slide 88]

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

[Slide 90]

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
widget, 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.

[Slide 92]

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.

[Slide 93]

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 try to use it, but most probably you will want to just use Orca
and check quickly what is showing up.

[Slide 102]

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, and 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.

[Slide 103]

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.

[Slide 115]

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

[Excuse me, do you know the current status of Chinese, Japanese, and Korean
support on the Braille display?]

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

Oh you mean if some desktop breaks accessibility support? [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? [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
technically not feasible, so a technical solution to the 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?]

[So you talked about you have to turn on the accessibility in the installer, I
have no idea? [sorry I couldn't hear] You talked about, during the installation,
you have to press s or something to turn accessibility on, I think Apple has it
turned on by default, I mean...]

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.

[Well, I was thinking in a minute, it's no big deal for me if it's turned on, at
my computer start...]

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 with UEFI if that works [...] UEFI, if you boot the installer CD
I honestly don't know, I haven't checked this just now, whether it works if you
boot via UEFI [...]]

Err, I think it's really independent of the firmware. The only think is the
boot menu where we do have to have a beep [yes, that] and that's something I
didn't test myself [so for UEFI we boot grub instead of isolinux] right [I don't
if grub ... beep] grub does have a drive of the PC speaker, so it can beep
actually. Err, I'll just write a note [I you can check that, let me know, and we
can fix it if it's not working].

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]