path: root/Events/XDC2014/XDC2014ThibaultAccessibility.mdwn
diff options
authormperes <mperes@web>2014-10-05 18:59:04 -0700
committerxorg <>2014-10-05 18:59:04 -0700
commitb3f136dafafe38ba705fdfd1dbccb5a904e95e0f (patch)
treee8818f49892c95db74925166cd3f1933c83eff34 /Events/XDC2014/XDC2014ThibaultAccessibility.mdwn
parent3741520727f457a4367cf45638fb4258920150d8 (diff)
Diffstat (limited to 'Events/XDC2014/XDC2014ThibaultAccessibility.mdwn')
1 files changed, 5 insertions, 0 deletions
diff --git a/Events/XDC2014/XDC2014ThibaultAccessibility.mdwn b/Events/XDC2014/XDC2014ThibaultAccessibility.mdwn
new file mode 100644
index 00000000..99839412
--- /dev/null
+++ b/Events/XDC2014/XDC2014ThibaultAccessibility.mdwn
@@ -0,0 +1,5 @@
+# Samuel Thibault - Where does accessibility plug into the graphical desktop stack?
+Yes, it does make sense for a blind user to use a graphical desktop. More generally, it has to be accessible to a very wide range of handicaps, so we need to make sure that accessibility tools can plug into the stack to get, modify or inject information, so as to compensate the user's disabilities.
+I will briefly remind the path of an 'a', from pressing the keyboard key to the application, i.e. the input part, and then from the application up to its rendering on the screen, i.e. the output part. I will then explain how various tools plug into various places. On the input side, there are virtual keyboards, braille keyboards, AccessX keyboards,... and infamous issues between keycodes and keysyms, which we could perhaps take the opportunity to fix with Wayland. On the output side, there are magnification tools, color modifiers,... and last but not least, screen readers, for which I will explain the accessibility bus (at-spi) basics.