Before I tell you why Emacs is an amazing piece of software and how it
helps me save a tremendous amount of time, I should tell you more
about the reality of being blind and using a computer.
* How do the blind use a computer?
The blind use the computer using what's called a screen reader. A
screen reader does what its name says, it reads the screen. It does
that by calling operating system and application APIs that give it
information. For example, when I press tab, I land on a control, and
the screen reader asks the application the type of that control, its
label, and its state. So for example, if I land on a checkbox, what
I'd hear would be, "I agree with all the stuff I didn't even read
checkbox not checked".
* What are the problems that screen reader users run into?
As you can imagine, the biggest problem for a blind person is using an
application written by a developer that didn't implement the right
APIs. These applications can be inaccessible on many levels. Maybe
the controls have no labels, so you just hear that you're on a
checkbox and it's not checked, and you don't know what will happen if
you check it. It could make your computer explode, or could move all
the money in your bank account to Uganda – you just don't know.
The next level is when you don't even know that you are on a checkbox,
because the control doesn't implement a way of retrieving its type, or
its label, or its state. This is even more scary, you don't know what
will happen if you press enter. It could just tick a checkbox, or
click a submit button to send all your details to the authorities!
It gets even worse! The highest level of inaccessible application
(which exists much more than you would imagine) is an application that
doesn't let you do anything with the keyboard! So, when you press
tab, nothing happens at all!
* Can a blind person who knows how to code fix these problems?
Now, most of the time on the Mac or Windows you don't have access to
this application's code to go fix it. If you're lucky enough to be on
GNU/Linux, you will probably have much bigger accessibility problems
that you'll have to fix first, and you'll need to know C++, understand
all the system-level concepts, and have a coding environment that
actually works, first.
So, if you're really dedicated, you can totally go and fix the code so
that it provides the right information. Most of the time though, the
application will be using a library like QT or Electron, which doesn't
even support all the accessibility APIs. So, you as an application
developer, have no easy way of making your application accessible,
other than switching to a completely different library, which is,
understandably, too much work.
* How does this situation affect a blind person's productivity?
The thing is, when you're hired as a developer or anything really, you
are always, directly or indirectly, competing with a sighted person.
At the end of the day, your employer wants to know if it's worth
paying the same amount of money as a person who is sighted. So it
becomes very important for a blind person to protect their
productivity.
When you have to use applications with varying amounts of
accessibility, your productivity suffers. Imagine if every single
thing you have to do in an application takes ten seconds more than it
does for a sighted person. At the end of the day, you have lost at
least an hour or two, and you always feel like you're lagging behind.
But this is not the worst thing. The worst thing is that you don't
have control over any of these pieces of software. If you are dealing
with a company that listens to its users and adequately prioritizes
accessibility issues, which is the best case scenario, you will have
to wait for weeks for them to fix that issue. In the mean time, you
are falling further and further behind.
If you're dealing with a company that doesn't care as much, you have
only two options: export your data completely and move somewhere else,
or deal with the inaccessible interface and lose even more time. Most
of the time, you have to go with option number two.
The scary thing is that this category of software, software that makes
you slow but you have to use because there is no other option, makes
up the majority of my day. To give you some idea, stuff like JIRA,
Google Docs or Sheets or Slides, Trello, Gitlab, Facebook's Workplace,
and many others fall into this category. IntelliJ IDEs are completely
inaccessible, and other IDEs like Eclipse go through periods of being
really accessible, then inaccessible, and so on, depending on what the
priority for the company happens to be.
Now, you might think, why don't we create software specially for the
blind? The thing is that this way of thinking is not scalable.
Making a document editor and spreadsheet and issue tracker and IDE and
everything exclusively for the blind would mean that the software
blind people can access would be way behind the mainstream.
So, what should we do? Well, most people are trying to make
implementing accessibility easier and easier, so that it only takes a
few minutes to add accessibility to any feature. Some people are
educating developers on how easy it is nowadays to make any software
accessible. Some companies are spearheading accessibility in their
products. However, there is still a long way to go. And, as a blind
user, I'd have to suffer in the mean time.
* What about Emacs?
Now, Emacs itself is just a piece of software that hasn't done
anything for accessibility. However, Emacs' power lies in the fact
that it is customizable. It provides all the building blocks for
anyone to make it accessible, and in 1994, Dr. T. V. Raman started
doing just that.
Remember when I said that most software needs to implement the API to
tell a screen reader about controls and their labels and states?
Well, imagine if you could write a script that runs inside the
software itself, pulls that data out and speaks it. This would be
basically a screen reader that is running inside that software and
making it accessible from the inside.
That's what Raman created, and it's called Emacspeak.
* How does Emacspeak help me?
Emacspeak is an Emacs package which uses Emacs' own functions to
retrieve information and speak it, and it runs by advising most of
Emacs' functions. That means, for example, when I press C-n, instead
of asking an application's APIs to provide the selected line in a text
box as a screen reader would, it runs after `next-line' and uses
`buffer-substring' to get the current line and speaks it.
It sounds very simple, but the implications are huge. For example,
because Emacspeak is inside Emacs, it can take display options into
account and not speak invisible portions. In org-mode, it can tell
you that the current line is collapsed and you can expand it by
pressing tab. In programming modes, it can tell you the indentation
level, which a very few screen readers can do. It can play tones or
speak in different voices depending on if the current line contains
something that is bold. All of these stuff it can do because it's
running inside Emacs, which makes it very easy to retrieve information
about what's being shown on the screen.
This means that almost everything in Emacs is spoken with a very high
degree of accessibility by default.
But that's not all.
* What if something in Emacs isn't accessible?
You all probably know that the code inside Emacs is readable. If you
know Emacs Lisp, you can read and understand most of what's happening.
That also means that if something doesn't work for me, if it is not
accessible, I can either make my own accessible replacement that calls
that functionality, or I can do what Emacspeak does and advise that
function.
For example, `org-capture' is not accessible because it asks me to
press a key to indicate what I'm capturing. The reason is that it's
waiting for a key press, so when I press any key to read the buffer,
it stops.
So, all I needed to do was to make my own function, `capture-todo'
that would call `org-capture' with the `t' flag for TODO, and bind
that to a key.
If it was any other application, I would have to ask someone to tell
me what the screen says, write down what I need to do in a file or
memorize it, and refer to it every time I forgot.
* How else does Emacs make me more productive?
But still, Emacs helps me in a lot of other ways.
One thing is navigating quickly to where I want to go. For example,
YAML is a mark-up language that depends a lot on indentation. Even
though Emacspeak tells me how many spaces a line is indented by, if I
wanted to find something in a YAML file that is indented one level
less than the line I am at, i would have to press down arrow, listen
to the indentations in the line, press down arrow again, listen to the
indentation again, and so on. It would take me a long time to get to
the line with less indentation, whereas for a sighted person, it would
probably be as easy as scrolling down until they find a line that is
indented less.
However, because of Emacs' nature, I can write a function that does
the skimming for me faster than any human could, and drop me at the
line with less indentation.
Another thing that Emacs helps me a lot with is that it's fast. The
fact that I can do anything with a keystroke means that I don't have
to use my screen reader to look for controls in an application.
An example of this is Omnifocus versus org-mode. Omnifocus is a
wonderful application for GTD practitioners: it lets you create TODO
lists, assign them to projects, review your day or your week, and so
much more.
Org-mode allows you to do the same things, but it takes a long time to
set up. You have to figure out how you will mark projects, where you
will store them, how you will assign a TODO item to a project, how you
will pull in your calendar data, and so on. It's easy once you've
gone through the pain, but it's way faster to start with Omnifocus as
opposed to org-mode.
However, once I set up org-mode, I was way more productive in it than
Omnifocus. It only took me a few keystrokes to move an item from my
inbox to a project, from project to project, from projects to
archives, and so on, because everything has a keystroke. It's very
easy for me to see what my team is working on, and follow up with
people when deadlines are approaching. It helps me take notes in
real-time when someone in my team does something great, so that I can
thank them and mention it in their performance review.
And if something doesn't exist and doesn't have a keystroke, it's very
easy to use the existing functionality as building blocks and write
something which makes me extraordinarily faster.
* Conclusion
As I said in the beginning of this talk, my aim here is to tell you
all how Emacs is helping me be way more productive and get a lot more
done, and to applaud all of you for making Emacs better and better
every day.
Thank you.
# LocalWords: APIs Emacspeak Raman API IDE org IDEs IntelliJ todo
# LocalWords: Gitlab Trello Docs TODO JIRA QT linux YAML Omnifocus
# LocalWords: GTD inbox
