One of the many titles that we documentarians assume is user’s advocate. This means that we defend the user’s interests, cater for their information needs, and provide them with the right content at the right time. But what if some of them cannot read the help topic because the font is too small and light, or they cannot do a step in a procedure as the instructions are too vague? This means that probably, we have overlooked such thing as accessibility.
Accessibility means that an application or a document is designed in a way that people with a wide range of hearing, sight, movement, and cognitive disabilities can use. However, we, as true user’s advocates, may expand that notion even further and try to create content that would be easy to reach anytime, anywhere, under any circumstances. This may seem like a formidable task, but the easiest way to start working on it is to go back to basics.
First, get acquainted with the Web Content Accessibility Guidelines (WCAG) 2.0. These are comprehensive rules and recommendations on how to create content and user interface, so that they are simple to understand, easy to access, and smooth to navigate.
According to WCAG, there are four principles of content accessibility: perceivability, operability, understandability, and robustness. Let’s have a closer look at each of them.
The user has an alternative option to perceive the content in case the primary one is not working. All the non-text information should have alternative text for images, descriptions, and closed captions. Vice versa, the text information should be dubbed with pre-recorded audio or video.
The user can easily grasp the visual representation of the content: font size and color, overall color scheme, the contrast between text and background, as well as background audio
The user has enough time to perceive and navigate through the content.
The navigation is intuitive and predictable, all the navigation elements have clear labels, so that the user easily finds the needed content and never gets lost.
The user can use keyboard shortcuts to interact with the content. It is another case of providing the user with alternatives: the user can choose not only how to perceive the content but also how to operate it.
Flashing elements should be avoided, as with a certain frequency, they may cause seizures. Overall, flashing elements serve as distractions and make
the user lose focus.
The user can read and understand the information. The content is written in plain and simple language devoid of any jargon, abbreviations, and unusual words.
The UI text is clear and informative. Messages and input validation appear exactly when the user needs them and provide guidance on further steps or suggestions on how to fix a problem.
The screen below is a replica of the security alert interface that lacks both in understandability and operability. It led to Hawaii false missile alert earlier this year. Having received false notifications on the islands being threatened by an incoming ballistic missile, nearly 2 millions of Hawaii residents and guests started taking the actions required in such situations, and several of them got severely injured from the attempt. All this happened because a Hawaii Emergency Management Agency operator had clicked the link marked real instead of the test one.
Can you imagine a reverse situation, when in case of a dire need, the operator clicked the test link, and instead of hiding, people ignored the message altogether? This case is a good example of why the users should be able to work with the content in any way, be it doing an online test while sipping coffee or clicking the correct button while being stressed.
The user can easily apply assistive technologies to the content: screen readers, text-to-speech features, closed captioning, and so on. The content is accordingly prepared and marked up.
Here, you might need the help of software developers to try and test out your deliverable, especially when you write for mobile, as mobile devices usually have built-in TTS engines.
TTS tools are also useful for testing your content for readability. If you listen to your text being read out loud by a TTS engine, you might hear grammar mistakes, notice too long or odd sentences, and assess overall clarity and brevity of your content.
WCAG is a thorough and extensive source that covers all aspects of creating accessible content. For more information, you can refer to the classic style guides, such as MMoS and IBM Style Guide.
Once you decided to improve the accessibility of your content, there are a variety of tools that can help you select the proper means of achieving the accessibility for different types of content and test the accessibility of your deliverable.
Below, you can find the list of the references that should help you navigate the vast accessibility sea with far more ease. If you know some other useful resources not mentioned here, please let me know!
- Apple Accessibility Overview
- GitHub Accessibility Style Guide
- Microsoft Accessibility Overview
- Microsoft Manual of Style (4th Edition). Chapter 4. Accessibility
- The IBM Style Guide: Conventions for Writers and Editors. Chapter 8. Writing for diverse audiences
- W3C Web Content Accessibility Guidelines
- Writing for Accessibility. MailChimp Content Style Guide
- 6 Best Practices for Designing Accessible E-Learning
- 9 Tips to Develop Accessible eLearning
- Accessible Documentation
- Accessibility Evaluation for Web Writers
- Creating Accessible eLearning: What You Need to Know
- Designing for Screen Reader Compatibility
- Dos and Don’ts on Designing for Accessibility
- IT Accessibility Checklist & Tutorial
- The Accessibility Cheatsheet
- What Does “Accessible eLearning” Mean?
- Writing Clearly and Simply
- Accessibility Tools for Windows
- Accessible Color Palette Builder
- Color Contrast Analyzer
- Web Accessibility Evaluation Tool