Human Factors and WCAG 2.1
The Web Content Accessibility Guidelines (WCAG) 2.1 from the World Wide Web Consortium (W3C) is the main guideline that web developers and designers should look to for accessible design requirements. Within WCAG 2.1, four basic design principles are described in relation to accessibility. To help make these four principles easy to remember, they use the acronym, “POUR”. This article breaks down the components of this acronym stands, as it applies to the real world.
https://www.equalweb.com/html5/Web/1116/wcag2-1.png
“P” is for Perceivable
Perception is the gateway for all things related to human performance. In regards to physical or digital design, this usually includes what we see, hear, and feel. Less frequently, it might also include what we smell and taste.
(Side note: perception spans beyond these five “Aristotelian” senses. Far beyond, in fact. Others include things like our sense of temperature, pain, time, and balance — just to name a few.)
When it comes to user experience, the user fundamentally starts their interactions with perception. For example, they must perceive (i.e., see, hear, feel) that a switch is present before they think further about how to act upon it. Likewise, they must be able to accurately detect the letters in a sentence before they can comprehend what the instruction is telling them to do.
Perception and User Experience
Yet while perception is the “simplest” concept in the POUR acronym, designing a system to be perceivable is no easy feat. In fact, this is the category where designers and developers experience the most user issues and complaints — especially in the domain of accessibility.
Common complaints related to “perception” include:
- “The text was too small, so I misread the letters in the word.”
- “The checkout icon had poor contrast with the background, so I didn’t see it right away.”
- “The image didn’t have alt text assigned to it, so I didn’t know what the image was showing.”
- “The button wasn’t labeled as a button according to my screen reader, so I didn’t know to click it.”
Users with a visual impairment need your website or app to offer audio options for all text-based content, navigation elements, buttons, and graphic content. Screen reader technologies need to access and read back all text, rather than just a selection of what a sighted user can see. Similarly, color palettes must lend themselves to those with a color vision deficiency. Those with a hearing impairment must have sufficient audio cues (i.e., loud enough, meaningful sounds, timely audio feedback).
“O” is for Operable
Once elements are perceived in a user interface, users need to have some way of interacting with it. For disabled communities, this spans beyond our notion of normal “interaction” to include alternative input methods and technologies. In this sense, an “operable” design is one that is flexible and input agnostic. Meaning, one person could choose to interact with it through a keyboard (only), while another might only use voice commands. No matter what input method the user selects, the workflow and final result should be the same.
Common complaints related to “operable” include:
- “The icon was too small, so I couldn’t click it in the right spot.”
- “The image carousel changed too quickly, so I couldn’t click the one I wanted.”
- “The website navigation didn’t support keyboard use, so I couldn’t go anywhere.”
Users with a visual or cognitive impairment need enough time to interact with time-based assets on a website (i.e., image carousel). Keyboard-only users need websites that allow full interaction with just the “tab”, “enter”, and arrow keys. Those with a fine motor disability need large enough icons and widgets to forgive some error when clicking with a mouse or finger.
“U” is for Understandable
Text and graphics need to be simple and straightforward. A novice user and an experienced user should (ideally) perform equally well on tasks on your digital platform. Sentences should be concise and meaningful. Forms need to follow a cohesive workflow. Drop-down menus shouldn’t nest information too deeply, or in ways that conflict with the average user’s mental model of the system.
Common complaints related to “understandable” include:
- “The web link was a string of random characters, so I didn’t know what it meant.”
- “The time between when I pressed the button and when I received feedback was too long, so I didn’t know if my attempt was successful.”
Users with a cognitive disability shouldn’t experience confusion over words that are beyond their reading level. Those who use a screen reader need to the website or app to provide meaningful descriptions of links, images, graphs, and videos.
“R” is for Robust
Websites and apps should work equally well across platforms or devices. Within reason, companies should not force users to use one form of technology (i.e., web browser) to access their content. One of the best strategies to ensure your website or app is robust is to use clean, concise code, since it’s more likely to work across platforms.
- “I only use Mozilla Firefox, so I couldn’t use the extension that was only developed for Chrome.”
- “My smartphone holder is fixed in landscape mode orientation, so I couldn’t use the website since it only allows portrait mode orientation.”
Final thoughts
The WCAG 2.1 does a good job of laying out the principles of accessible design for digital platforms. However, it’s not prescriptive. It won’t tell you exactly how your design should be handled for your specific use scenarios and user capabilities. Keeping the POUR acronym at the heart of your design and development strategies will help you remain proactive about incorporating accessible design early and often in your product’s development.
