My 36th week at Learners Guild in Oakland, California, has just ended, and the program I entered lasts 40 weeks, so there are only 4 weeks left before I complete it.
My fellow Learners and I in this closing phase of our training are getting serious about planning for the next stages in our software-development careers. Massively applying for jobs, rehearsing technical interviewing, and studying in-demand technologies are the main strategies being pursued. I’m applying currently for only a few jobs, and in most cases I’m telling the employers what’s deficient in their web interfaces and why they seem to need my help to cure those maladies. If they don’t care enough about such problems to respond, they don’t deserve my services.
I’m no longer doing practice interviews or drilling on solutions to algorithm problems, because I’m skeptical about working for an organization that screens applicants by putting them under time pressure at a whiteboard.
So I’m mainly doing what I came to Learners Guild to do: learn.
As reported the last 2 weeks, my current study topic is accessibility, also known as a11y. This week I got around to taking one of my already completed projects and making it more accessible.
I chose Calculator, about which I first blogged back in the early days of my Learnership. Back then accessibility wasn’t much on my mind. And that’s true for most software. So, taking an existing application and figuring out how to make it more accessible is good practice for doing web accessibility work in the real world.
The inspiration for this project is the venerable Macintosh OS X Calculator. If you entered “8 – 6” onto it, it would look like this:
If you did the same thing with my Calculator, you’d see this:
Right off the bat, you are starting to see some accessibility differences:
- My characters are larger and bolder, and they stand out from their backgrounds more clearly.
- My Calculator shows your entire recent sequence of inputs, while the Mac’s hides the “8 -”, forcing you to remember it.
- When you press a button on mine, the button becomes marked and stays that way, so if you ask to repeat your last input (which you can do by pressing the space or enter key) you know which input you’ll be repeating, so you can predict that you’ll get “8 – 66”, then “8 – 666”, etc. On the Mac Calculator, you can input “8 – 6” and then repeatedly press the return key, and you’ll get a different result every time, but nothing in the display tells you that you are repeating the “- 6”.
There are more accessibility features that you can’t see in the picture:
- If users need a bigger calculator, they can enlarge it in their browsers in the normal manner to any size they want, and it continues to look and work the same. The Mac calculator has no size-modification feature.
- If you hover your mouse over a button, you see a description of what it will do and what keyboard keys can do the same thing. The Mac Calculator has this, but my original one didn’t.
- If you do something that makes it nonsensical to press a particular button next, that button becomes disabled, and it grows dark. So you are never tempted to input something invalid. The Mac Calculator’s buttons all look enabled, even when they do nothing.
- If you are using your tab key to move from button to button, the order is a logical one, not one based on position, so a blind user, expecting to hear “four” after “three”, would hear that, and not “delete”. The tab key does nothing in the Mac Calculator.
- User mistakes can be corrected. If you input “34018.505 × 44” and you then notice that you should have written “34018.605” instead of “34108.505”, you can delete the last 5 inputs and continue by typing “605 × 44”. The Mac Calculator would let you delete the “44”, but nothing past that.
For more details, including how these features satisfy various international accessibility standards like WCAG and ARIA, you can look at the documentation, but this will impart the flavor.
You can use my Calculator on Github.
Many other accessibility features simply don’t apply to an application like this. For example, multi-page accessible websites give users an option to automatically skip over repetitive headers. Accessible sites with rotating picture carousels let users stop the motion.
But, although my Calculator didn’t cover the entire accessibility landscape, I found it very helpful to transition from reading about web accessibility to actually adding more accessibility to a real application.
Of course, in order to do this, I needed to keep (re)reading, and in one case I was able to not only consult the WCAG 2.1 authority, but also improve it, by recommending a less ambiguous formulation of one of its standards, which the authors adopted.
Next week I’ll probably try to develop an entirely new application, with accessibility built in from the ground up.