{ Starting at 28:08 only, sound not available before }

[ Showing brltty X11 virtual braille device ]

... screen reader, but it also has a virtual braille device, which I will use,
and so I'm starting the Debian Installer, telling qemu to simulate a braille
device {-usbdevice braille option}. It will actually use brltty to render this.
And I just boot the normal image, and then it will automatically start the
screen reader inside the installation process, and so we can actually read what
is happening in the installer. Without doing anything. There is just an <enter>
press to be done, but we have added a beep at the boot so that the user knows
when it has to press <enter>.

And also for speech synthesis, I have to ask for it, so I type <s>, and <enter>,
and then it boots with speech synthesis enabled {select the language}, so it is
actually speaking. And it has enabled a text, a really text version of the
installer, which is much more accessible than dialog boxes with all kinds of
things.

So this is it.

[ Slide 85 ]

So, you can have the details on brl.thefreecat.org, but basically, we switch to
text mode and run brltty, so it can access the text mode. For graphicall
accessibility, we would need to set up at-spi and run Orca, we are not there
yet. Maybe the way we would do it is just use a liveCD which has everything set
up, and just tell people "if you want a graphical installation which is
accessible, just use a liveCD", it will be easier, but again that's not supposed
to be the right thing: we should make the main installer accessible.

An important detail: you should remember to enable the same accessibility
features you have enabled during the installation *for the installed system*.
Because if you install everything with braille and speech synthesis etc. and you
boot and you have nothing, then it's really a problem. So it's stupid, but you
have to think about it.

And it is useful to be able to tune this kind of accessibility tools, so for
instance for some braille devices you need some parameters, to manage to drive
some, like you have to specify the protocol because unfortunately it can not be
detected, and things like this. So it is useful to be able to pass parameters
through the command line or preseeding or whatever.

[ Slide 87 ]

And an important, very important thing is: it has to be testable, and integrated
into the testing protocol of your distribution. So for instance in Debian, for
the installer, we have a wiki page, which explains exactly what I've done here,
so how to start brltty, how to start KVM, to actually test that is working. So
that the main maintainers of the installer can actually test the thing during
their normal regression tests. Because you don't need specific hardware, that's
a kind of thing that is important with accessibility, I have implemented a
virtual braille device, both in brltty and in KVM so that people can try braille
without having a braille device, since it is awfully expensive.

[ Slide 89 ]

And yet further... the bootloader. Mostly nowadays it is just not accessible at
all, like grub. But it is improving. We have implemented something to make grub
beep, when we are at the menu. There are some keyboard shortcuts you can add to
the menu, and ideally at least we could beep to know which item is being
selected. Or even just synthesize some ogg file or whatever, and then play it
through the sound card so that the user can get feedback. That way, we don't
have to implement a whole screen reader inside the bootloader, but just some
drivers to play some file, and then we can make at least a bit accessible.
There are still ideas about putting brltty into grub, phcoder is sometimes
working on it, so it's making progress, maybe we will actually see grub
accessible some day. But for now it's not yet.

[ Slide 90 ]

One of the last few points: about bugs. It's something which is difficult. You
all have dealt with bug reports which are always not detailed enough etc. etc.
When accessibility is into question, it's even worse.  And sometimes you would
see users making some suggestions which don't make sense to you, because you
would say that "why would you need that". And so for instance, people have asked
text web browsers to put URLs between brackets, so that they can actually be
noticed, that it's a link. And just implement it, *they* have asked for it
for a reason, because they really need it, and so just implement it. Just as an
option that's fine.

And be patient. About bug reports, the thing is: it's already difficult for
people to use your software, it's even more difficult to know, for them, how
they are supposed to use the software. Just because they can't see it, they will
explain you things the way they see the application, which is not probably the
same as the way you see the application, because they use a screen reader and
you use your eyes. And so you may see things like this in the bug report:
"braille doesn't follow", and you have no idea what that means. So just ask the
user to explain what he means by this, because for me it's obvious: it means
that the screen reader doesn't know which part of the application it is supposed
to show. And this is because the application hasn't put the cursor in the right
place. And this is the kind of process you have to really iterate, discuss, to
be able to actually understand what the underlying issue is.

[ Slide 91 ]

And one thing which is really difficult, is keeping in mind the disability. I
remember very well a discussion where we wanted to enable the framebuffer in the
Debian installer so that chinese etc. can be displayed and accessible, and then
some people said "but the blind user will not be able to tell us in the bug
report that the display on the screen is bogus". Ok, but he doesn't care, so
that's fine! And it's just a stupid example, but yeah, it's some effort you have
to do to remember "ok, this is the way he sees the screen, I have to adapt my
explanations and implementation according to this".

Well, you could just contact local institutes for disabled people etc., to
discuss directly with them. And to see with them what their needs are.

[ Slide 92 ]

More general ideas, for your distribution. Get people involved, so you may have
your, something, your own distribution accessibility list. Make sure that your
website is accessible as well. And integrate accessibility everywhere, just like
any other concerns of your distribution, so in the installation manual, the
maintainer's guide, to your bug reports, etc. Really put accessibility into your
normal process, and then it will, by itself, come up when discussing things etC.

[ Slide 93 ]

Conversely, I've mentioned the accessibility mailing list, it's a good thing to
centralize the knowledge of users, of developers etc., but be sure not to make
this a "side-park", that is as soon as an accessibility issue is raised, then
you discuss on that only. If you do that, then maintainers, the mainstream
maintainers, will not be aware of the issue etc. So the discussion should really
happen on the normal mailing list, and just putting the accessibility mailing
list in copy, so that people can know that "OK, this is happening", and maybe
centralize following the discussion, but the discussions really have to be done
in the normal lists. Just to emphasize even more: discussion is essential so
that the integration is mainstream, and then you have to find compromises. For
instance, I've mentioned the beep that the Debian Installer does at the boot
menu. The discussion has lasted for, three months maybe. Just to determine which
compromise we have: do we enable it all the time ? We didn't, we just enable it
for official releases etc. to avoid disturbing the developers etc. But then,
since the discussion has happened, and is archived, and it's all the normal
people, the maintainers of the thing, which have gone through this, then it is
integrated. I have seen bug reports about the beep of the installer, people
saying "it's disturbing, please drop this", and the answer was immediate from
the team maintaining the installer, and not the accessibility team. And that
meant that it really went into the process, so it is sustainable. Because the
work on this is distributed over the maintainers, and not the accessibility
community.

[ Slide 102 ]

So, to conclude. Quite a few of your users actually need accessibility right
from the start, because yes, they reinstall their PC at 2AM and they don't
necessarily have somebody to view the screen at that time. And in any situation,
so for all kinds of installations, you will at some point need some
accessibility, you don't know when, you don't know where, so just install it by
default, not enabled by default, but at least easy to enable. So please help us
making accessibility maintream! Thanks.

Are there questions?

{...} I guess... so an economical reason to... So Apple... So an economical
reason for this, probably because they saw that people get older, and a lot of
people get older, I don't know, maybe, yes ? {...} Yeah, there are some laws in
the US which say "you have to make your software accessible". It was part of a
discussion for the software to be used in the administration in the US, that it
has to be accessible, so indeed, they have done it themselves. But Microsoft is
supposed to do it as well, but they never really made an effort this way, so
there is still something. Microsoft really never implemented accessibility
themselves, they were just pushed by some other companies, or states.

{...} Yes, that's a problem indeed, but, during the developement of the
software, you would need to test accessibility right at that stage, and that's
why I would push for integrating testing with accerciser right into the process
of writing an application. Because otherwise, yes, people will test
accessibility features only when the software is released, and of course it will
be bad...

{...} So can we make accessibility testing automated? You can test the technical
part of it, and still it's maybe not so easy because you have to put somewhere
that this information I have added to my software, it is visible in acceciser.
Maybe you can automate it. So at least from a technical point of view, maybe it
will be accessible, but then from a usability point of view, maybe it will not,
because of logical ordering etc. So you can not escape actual testing with
real users, but at least technical testing is a good thing. Because if somebody
really has to use the software, at least if it's technically accessible, it will
be really tedious, but at least he will be able to use it. With some help, and
learning by heart how to do it, but at least he will be to do it. But for proper
usability, then you need really real tests.