My colleague Claire Kearney-Volpe and I have recently been co-teaching
HTML and CSS to students who are visually impaired.
One of the benefits of learning coding today is the fact that it can
be done without having to install anything: using sites like JS Bin,
CodePen, and Mozilla Thimble, people can tinker with code on their web
browser, and even publish it instantly online with the click of a button.
Unfortunately, however, these sites are inaccessible to screen reader
users.
This is because the editors use sophisticated widgets to provide real-time
syntax highlighting of the user’s code, which, for reasons that are
outside of the scope of this blog post, are impenetrable to screen readers.
Even popular desktop code editors like Atom and Sublime Text have the
same problem.
Because of this, a standard HTML <textarea> widget is far more preferable
than a fancy syntax-highlighting one.
That said, there’s also a lot of information loss in a <textarea>: for
example, it’s very hard to know what line number the cursor is on,
which is crucial for making sense of error messages. It’s also impossible
to convey any of the information that syntax highlighters make
easily perceivable, such as whether some text is part of a
code comment or an HTML tag.
As a way to remedy some of these issues and provide a simple code
editing environment for our students, I created a rudimentary online
code editor and publishing platform called Pode.
In its current incarnation, users can create HTML pages with Pode,
publish them to URLs, and share them with anyone. Pretty basic, but
unlike the alternatives, it’s all fully accessible via screen reader.
However, Pode does have a few affordances specific to visually-impaired
users that I think are worth mentioning.
Accessible context-sensitive help
Ctrl + H can be used at any time while editing
to announce information about the context surrounding the user’s
cursor position. For example, suppose the cursor is at the
beginning of the word “neato” in the following HTML code:
<p>this is <strong>neato</strong>.</p>
If the user presses Ctrl + H there, a
screenreader will announce the following:
Cursor is on line 1, inside a STRONG element inside a P element.
If the user moves their cursor to the left, their screenreader
will say this:
Cursor is on line 1, inside an opening STRONG tag inside a P element.
This is made possible via integration with slowparse, an HTML
parsing library I worked on during my time at Mozilla.
An accessible throbber
To enable a quick development feedback loop, I added a
Ctrl + S shortcut that saves
the user’s code and re-publishes it while preserving their current
cursor position.
Sighted users can easily see that their content is being saved through the
display of a throbber, or an animated icon indicating that their
browser is currently working on something in the background.
While the ARIA standard does define a way for pages to indicate to
screen readers that the user’s browser is busy, I found that many
screenreaders don’t seem to actually support it. I also thought that
there might be an opportunity to add some audio feedback that could
help sighted users, too.
Interestingly, back in the age of floppy disks, users did have
audio feedback telling them that their computer was busy doing
something: the mechanical sound of their floppy disk whirring. So I
found a Creative Commons-licensed floppy disk drive sound
and made it play while saving occurs. Specifically, it plays for at
least one second, and loops until saving is finished.
I should also note that our students are generally people who remember
using computers in the days of floppy disks, so the audio feedback
actually means something to them. This may not be the case for younger
users, in which case the feedback might be confusing, unless perhaps
they recognize the sound from old movies.
In any case, I’m looking forward to adding more features that aid
visually impaired users in the future. Feel free to explore the
source code on GitHub or try Pode now.