Welcome to this talk about LibreOffice Accessibility and how it's implemented on the
different platforms. My name is Michael, I'm a LibreOffice developer working for the document
foundation with primary focus and accessibility.
Okay, first let's start with a definition of accessibility. That's from Wikipedia. Accessibility
is the design of products, devices, services, vehicles or environments, so it's
to be usable by people with disabilities. The concept of accessible design and practice of
accessible development ensures both direct access that means unassisted and indirect access,
meaning compatibility with the person's assistive technology, for example computer screen
readers. And that second aspect is what this talk will focus on, how assistive technology
can interfere with LibreOffice or can interact with LibreOffice. So if a person is for example
initially impaired or blind, how they can still use LibreOffice. One sample scenario of using
an assistive technology, a screen reader in this case is for example if we have a dialogue like
the one that shows up when you close a document while still having changes that are not saved,
and the screen reader will read out the text of the dialogue. Do you want to save the changes?
And then the user can interact with the dialogue using the keyboard, for example the tab key
to move between the buttons and then LibreOffice sends an event on the via the accessibility
to protocol of the platform. The screen reader receives that event and then it can ask for additional
information and then allowance for example cancel a button. So the objects have different
attributes like a name and a role and states and so on. So there are certain specifications
that describe what they can have. But the screen reader gets that information can then announce
it for example cancel a button or okay button and so on. So that's on the high level.
The interesting bit is how that works, how does LibreOffice transmit that information to the screen
reader and that's platform specific. For a simple case and overview we have some kind of
application that's using some UI toolkit. The simple application is just built out of
toolkit widgets and the toolkit takes care of everything and makes the application accessible by
translating that to whatever accessibility protocol is used on the next windows, macOS,
and maybe even more platforms and the screen reader assistive technology can interact with that.
So it goes both ways. In that case the application doesn't actually have to
know what the platform does but the toolkit takes care of everything. That's the nice scenario
which we don't have in LibreOffice unfortunately. So in our case it's a bit more complex.
This is simplified diagram. We have the application again as in the previous diagram and we do have
widgets of course and these widgets can be native toolkit widgets. We don't have a single toolkit
but we support different tool kits on Linux. We have GTK3, GTK4 or QTE5, QT6. In this case when we use
native widgets and the toolkit takes care of it and translates it to the platform accessibility
protocol which is ATSBI on Linux. We don't always use native toolkit widgets. If we don't then
we have to do all of that stuff ourselves. So we do not need to know what does the platform do on
windows and macOS. We don't use any UI toolkit but we actually translate everything ourselves.
We support the iAccessible iAccessible 2 protocol and windows and the inaccessibility protocol on macOS.
And we have an internal accessibility API which is the X-Accessible API. So whatever we want to
expose in the platform layer internally uses the accessible API for example our widgets or we see
our widgets. They use that API or support that API and then we have accessibility bridges,
let's translate that to the platform protocol for example iAccessible 2 on windows or an
inaccessibility on macOS. On Linux we use the toolkit again so we have this internal API but
then we use whatever the toolkit provides. For example GTK4 has an API I'll go into that in the next
slides and let's translate it to ATSBI again so the platform protocol. For QTE it's basically the same
for GTK3 as an intermediate layer which is ATK but I'll get into that in a little more soon.
So like about the platforms again so for windows and macOS as I mentioned we do all of the stuff
ourselves we support we implement an accessibility bridge which directly implements iAccessible 2 on
windows. We do not support UIA natively that's a new protocol but there's some basic support by some
MSAAUIA proxy so windows comes with some automatic bridge so we have some basic support for UIA as
well. On macOS we directly implement the inaccessibility protocol as I mentioned so we have a
bridge that us this by itself. On Linux as I mentioned we do have different UIA variants that we support
so depending on what UIA variant is used the ways a little different. In all cases the platform
protocol is the same which is ATSBI as I mentioned before. For GTK3 which is currently the most
accessible UIA variant in Linux we use native widgets so all of this native widget automatically
is translated by the toolkit but the other bit is the document and our document content is not
built out of widgets but that's all custom accessibility implementations so somehow we also need to
get the semantics of the document to the screen reader and the interaction for example if you move
between paragraphs then the screen reader should be notified that another paragraph is focused
now and can read out what's the text there for example and for that for GTK3 use the ATK toolkit
which is also what GTK itself uses internally and that translates it to the platform accessibility
protocol which is ATSBI as I mentioned. For GTK4 it looks a little different because GTK4
dropped all of the accessibility stuff that GTK3 had and they started something new. The intern so
GTK no longer uses ATK, GTK4 no longer uses ATK but it implements the ATSBI protocol directly
or there's also since recently another option to use access kit which is a gun and a library that
does it but that's the translation and also supports macOS and windows but the default is still
the GTK interl implementation right now and the not so nice thing currently is that because ATK
was dropped and there's a new API in GTK we need to do things differently which by itself is not a
problem and there's a GTK accessible API for application so leaf office can implement that API and if
it does the then GTK takes care of translating things to HSPI and Linux the main problem is that currently
this API doesn't provide everything we need so we currently cannot expose all of the document
content the way we would have to. Most important thing or one of the main things is we can't
notify about focus changes so when the user changes from one paragraph to another the screen
read it just won't notice because the developer office can notify because GTK just likes the
IP API to do that there's some discussion with upstream but there's some things that are missing
for that reason we don't use GTK for by default anywhere right now so we still default to GTK free
on the GNOME independent of the version. For QT we also have some accessibility API which is Q
accessible interface and funds which bridges to HSPI directly that's been some recent improvements in QT
so QT6 has most of the API we need and there's some things missing at least I know of high
polling support but I'm quite optimistic we can work together with the QT project to get this in some
someday so GTK free currently is still the most accessible variant but I'd say QT6 is getting closer
and I'm quite optimistic where we can get that pretty accessible if we put some more work into that.
Some more things of interest I mentioned that HSPI is a protocol used in Linux at the moment but
there's also some proof of concept accessibility stack called Newton that's major place HSPI at some point
the main idea is that it's push based approach so the application always pushes and each
and there's no need for the assistive tooling to query and information
what is to be known is that it's also mentioned it doesn't really know yet how to deal with
big documents for example so that's an open point but it's interesting to to keep an eye on that
and see how it goes and one of the main things I want to say is that in order to be really
accessible that's something that deep profits can do by itself so even if we implement all the
protocols very nicely there might be things on the toolkit level or on the assistive technology
level that expect things differently so actually making deep profits accessible is an effort that
needs to involve all of the projects of the components and I really thank for working together
with all the people in the different projects works really well and for all the support I get there
and the input so I really want to say big thanks to everyone involved and both in the tool
kits and libraries and also on the assistive technology side really really thankful for all the people there
that's it so far there's some links if you're interested in learning more about
the accessibility you're getting involved there's some links in the presentation
it's in in the foster system so you can get it there thanks a lot for your attention
and if you have any questions you can ask me afterwards