Welcome to part three in a four part series focusing on four key principles of accessbility in web application development. If you haven't read the previous two parts Perceivability and Operability, go ahead and have a quick look if you're interested in understanding all four principles and how they mesh together.
What Is 'Understandability' And Why Is It Important?
The third principle - understandability, can be summarised as "Making sure the user interface and its operation are not beyond the understanding of the user".
By it's nature, understandability has some overlap with operability. The key difference is that operability mainly relates to how users interact with pages and making sure it's possible no matter what they might use to interact with the application (e.g. keyboard only).
Understandability on the other hand focuses more on whether content and operation of the application makes sense to everyone, especially those with cognitive impairements.
I've actually moved one of the points I made in the last post on operability to here because it has more to do with the concept of understandability.
Idioms, Jargon And Abbreviations
It's easy for some websites, especially those with a technical focus, to rely heavily on unusual words, phrases and abbreviations in their content. It's important for understandability that there be some kind of mechasnism that allows users to find out what these things mean so that they can fully understand the content being presented to them.
Reading Level And Pronounciation
The WCAG (Web Content Accessibility Guidelines) 2.0 state that if a websites content requires a reading ability more advanced than lower secondary education level (about 11-13 years old in the UK) then there must be supplementary content for illustratative and/or clarification purposes or an alternative version of the content in which the content that is written does not require this reading ability. Last year I developeda prototype Wagtail plugin that allows content writers to see a calculated reading level of the text they're writing as they type it - tools like these can save a lot of time and effort.
Ensuring the reading level of your content not only means younger readers will be able to understand it, but that other people who may have difficulties with reading comprehension (perhaps because of a disability or otherwise) will be able to understand it too.
Pronounciation might not seem that important at first, but it plays a bigger role than most people think in how words and their meaning are perceived. The WCAG 2.0 guidelines suggest that if a words meaning is ambiguous without knowing its pronounciation, then either the context it is in or some supplementary information needs to make it clear.
It might be hard to think of an example but there's plenty of words that fit this description, one of which I've used several times in this post already - 'content'. Depending on the context and pronounciation the word content can either mean 'the contained material' or it can mean 'satisfied'.
Something that might not be so obvious is to make sure the language of the page can be determined programmatically. This is important as it allows different user agents (including assistive technologies) to extract and present the page content appropriately. This has a few exclusions such as proper names, words that have no determinable language and technical terms.
The programmatic determination might be made by markup language in the form of elements and attributes that assistive technologies readily make use of or alternatively provided through a special accessibility API that is commonly supported by assistive technologies.
I've included a link at the bottom of this post that has more information on accessbility APIs and recommendations on their implementation. In the future I might write a blog post dedicated to accessibility API development as they're not that well known.
Predictability revolves around making sure that things behave in a way users would expect, or rather not doing things users wouldn't expect.
Navigation And Components
A good example lies within navigation. As a user, you would expect (perhaps subconciously) that the order of links in a sites main navigation bar to stay the same, no matter what page you are on - if every time you clicked a link they all swapped places it would be difficult to predict where you would find the link you desired.
Another key factor is that components, such as buttons, that share the same functionality should be easily identifiable. If you use green buttons to 'submit' and red ones to 'cancel' then you should keep that convention throughout your application. If you suddenly used a green button to 'cancel' and a red button to 'submit' then your user may get confused and do something they didn't intend to.
Predictability also places a focus on making sure that the context of a given page doesn't change unexpectedly, which means they only happen by user input or when it's clear that something else will else will trigger it.
WCAG 2.0 classifies possible changes to context as changes to:
- User agent
- Content that affects the meaning of the page
A basic example of a chanvge of context is opening a new window or tab. Another example of changing context is changing page or anything resembling a routing event - you want the user to have expected this to happen or they may become disorientated.
Input assistance is actually something that most modern developers do pretty well, however it can still be easy to neglect so I'll go over a few simple ways to make sure you're hitting the mark.
Instructions And Help
The first thing you can do whentrying to make sure your input assistance is up to scratch is to provide instructions or adequete labels whenever you include something that requires user input. You see labels used this way a lot nowadays, when was the last time you saw a form that didn't make it clear which box to type your name in and which to type your email address in?
More complex user input situations where you are trying to get a user to provide information or perform a specific series of action may require more than a label, which is where instructions come in. It can also be worth thinking about including diagrams or animations to help illustrate what it is they need to do.
How you handle errors is another common, but equally important detail when designing with user understanding in mind.
An example of good error handling is automatic error identification - when a user inputs data that has errors in it, the errors are flagged up immediately before any kind of submission and an explanation of what's wrong is displayed. You can take automatic error identification a step further by suggesting the actual fix to the user instead of just explaning what is wrong although this isn't always possible.
Whether real-time automatic error identification is used or not, users should always be able to easily ammend and resubmit data that had an error in it, without having to retype data that was ok (passwords and sensitive data are an exception). It's also a good idea when users are entering large amounts of data and/or sensitive (perhaps financial) data that they are provided the opportunity to review and check the data they have entered before its final submission and if they find an error it should be easy to amend.
Its often easy to overlook simply allowing users to undo something if they need to. This can actually be one of the easiest ways to improve understandability without having to come up with ways to make things easier or add additional features to cater for different needs - just make undoing mistakes EASY. If things don't seem straightforward at first glance, sometimes it doesnt matter if it's simply a case of hitting undo as soon as you've made an error.