In my web use, I’ve noticed a growing trend to add instructions to more experiences on the web. This week it was more than 250 words on reading a table on a financial web site and another couple hundred words on a calendar control for an airline company.
Most often, this is coming in the form of an ARIA-Label or other hidden text, aimed at explaining how to use the experience with a screen reader in particular. This is typically scoped to some sort of custom control that the site has opted to use.
On the surface, this might sound great. We have some complex experience and want to give users some tips so we’ll jam in a set of instructions. We don’t want to clutter the visual experience with information that isn’t relevant if you are not using a screen reader though, so we’ll hide this info with some web technique we’ve learned about from someplace.
As someone who’s created a number of training videos and other learning content over the years, I recognize the importance and helpfulness a good set of instructions can provide. That said, if you are building an experience where for whatever reason, you find it necessary to add instructions directly into the content, please press the pause button and ask more than once why these instructions are needed.
Often I have found that it is a case that as a “workaround” for not following accessibility guidance instructions are viewed as the solution.
Explaining why you had to break the rules, dressed up as user assistance, does not excuse the rule breaking. In addition, you can write all the instructions you want but that’s no guarantee a user is going to read them.
Even if such instructions are justified, jamming them directly into the middle of the task flow is far from ideal. It seems great on first, second and maybe third use. By about the fifth time you’ve had to use some screen reading command to skip past all these instructions though, you are starting to feel held captive to this inefficient experience.
When talking about accessibility, I will typically share some form of this topic in my presentations. Without fail, audiences will always say that the experience with lengthy instructions seems more accessible when I first compare experiences with and without these sorts of instructions. Then I toss the curve of asking how the same experiences would compare after ten uses of the two. The answers are strikingly different.
This is not to say innovation and creativity are not part of an accessible experience. The exact opposite is true. However, ask yourself if basic tasks such as picking dates, reading a table of information or many other experiences that are common on the web, are the best place to create a control unique to one web site. You are asking users to learn something new specific to your experience and toss out years of learning they’ve likely accumulated when common controls and design patterns are not used.
At minimum, ensure as I say, you press pause and ensure you understand why you are making the choices you are. Put the user front and center and recognize that the user likely wants to get something done, not learn how to use your web site.
If you find you are in a situation where instructions are still warranted, find alternatives to an essay of user education attached to a control. Help links are one great alternative. Find a way, whatever options you choose, to allow a user to stop having to sort through instructions once they are familiar if you absolutely have to use them.
Comments