Welcome to the second post in a 4 part series on four key principles of accessibility in web application development. It's been a long time since part 1 so feel free to go back and refresh your memory a bit before reading this post.
Keeping it Simple
Operability, is perhaps the most important of all the four principles. Not to be confused simply with use-ability (with which there is substantial crossover) - operability in practice means that any user should be able to navigate and use our web application just as well as anyone else regardless of technical competence and any disabilities or disadvantages they might have.
At the same time as being one of the most important principles, operability is also one of the most difficult to get right. It can take some meticulous planning and work to make your site work well for everyone.
I’ll give an example, as it’s the best way to illustrate what kind of hurdles you might face in the development of your application. For some people with disabilities related to or causing reduced mobility, it can be hard to use a mouse and so they navigate the web using only a keyboard. This can be tricky to get right for a developer as it requires you to carefully plan and execute the flow of focus on the page (when you hit tab on a page it will cycle through elements in order of focus and will ignore any that you have explicitly told it not to focus on).
Try to remove the need for any kind of timed elements in your application that require the user to quickly make an action. If you can’t remove a timed element because it is integral to its purpose then you should at least try to slow it down, or give the user the ability to slow it down by hitting a toggle or similar. For instance, this can apply to something like a live twitter feed, if it updates very quickly your user might not be able to interact with the posts before the next update therefore rendering it inoperable to them.
User input elements are another place where you can make a huge difference to the user experience and accessibility with relatively little effort. In general, any element that requires user input should have an accompanying label or help text. Also, if there’s an error during input or after a form submission it should be made absolutely clear to the user what went wrong, why and what they can do about it - if anything.
Quality of Life Features
Sometimes it's the little tweaks and additional features that make using a website or application that much smoother for all of us.
If you've ever read a long article on a mobile device or been scrolling down through a website with infinite lazy load functionality (like twitter), you'll know that it can be really handy when you're presented with a "Back to Top" button. For people with reduced mobility these can be even more valuable as it takes a lot less effort to click that one button than scroll or drag back up to the top of the page.
Screen Reader Compatibility
If you've read the first post on helping users perceive content you may remember that I briefly touched on screen-readers and why you might need to take them into account when building your website/web app. Screen-readers allow visually impaired people to audibly experience what you're trying to show them. It's possible to kind of pick and choose what you allow a screen-reader to 'see' so that you can provide the best experience for that user. There's no hard and fast steps for this one, just keep in mind that not everyone will literally see your content so anything you build in to help operability needs to also translate well to a screen-readers output.