Making The Web More Accessible
so that we can all benefit from it
What is accessibility?
Accessibility can be viewed as the “ability to access” and benefit from a system. The sense considered here refers to the design of products, devices, or services so as to be usable by people with the widest possible range of abilities, operating within the widest possible range of situations. This is about making things accessible to all people (whether they have a disability or not).
The concept of accessible design and the practice of accessible development focuses on enabling access for people with disabilities, or special needs by ensuring both “direct access” (unassisted) and “indirect access” meaning compatibility with a person’s assistive technology. However, research and development in accessibility brings benefits to everyone.
Accessibility is not to be confused with usability, which is the extent to which a product can be used by specified users to achieve specified goals with effectiveness and satisfaction in a specified context of use.
What is the impact?
Everybody experiences accessibility barriers when there is a mismatch between their needs and their environment. The experience of the mismatch can be permanent, temporary, or situational.
For example (1. using only one arm | 2. not being able to hear):
- Permanent: having one arm | being deaf
- Temporary: having an arm injury | having an ear infection
- Situational: carrying heavy groceries | wearing noise-canceling headphones
If you design a product, such as a voice-activated speaker, people with limited hand mobility and those who are multi-tasking (cooking, driving), can also use it. It is called the curb-cut effect.
ℹ️ The curb-cut effect gets its name from physical curb cuts, the areas of the sidewalk that slope down to road level. They were adopted in cities worldwide to help people in mobility devices get on and off the sidewalk. However, many people benefit from them, including cyclists, parents with strollers, travelers with rolling suitcases, and pretty much anyone else with a set of wheels.
How do individuals use assistive technologies?
Assistive technologies (ATs) are specialized devices, hardware, and software that go beyond what can be accomplished with mainstream products to address accessibility barriers.
Personalization features such as high contrast and inverted colors can help users with low visual acuity and light sensitivities. When people are unable to perceive visual information with modifications, screen readers and braille displays can output into other modalities. Screen readers convert information into sound and braille displays into tactile information.
It’s possible to change how users interact with devices by changing how they receive input. For example, users who experience tremors may hit keys unintentionally, so they can change the key speed and hold duration. People can also use head tracking, eye gaze, and voice control as alternatives to the keyboard and mouse.
What the frack is WCAG?
To help people consider what is needed to make sites more accessible, the World Wide Web Consortium (W3C) created the Web Content Accessibility Guidelines (WCAG).
The top four accessibility principles are:
- Perceivable (content can be presented through different modalities: sight, sound, and touch)
- Operable (content can be interacted with in different ways, not just by using a mouse or specific gestures)
- Understandable (content is predictable, clear, and helps users with interactions)
- Robust (content supports a wide presentation across a variety of user agents and different types of assistive technologies)
No matter how much technology changes, these core principles will always hold. Within each principle, there are several guidelines, and within each guideline are specific, testable success criteria.
But just like following laws doesn’t guarantee ethical behavior, following web accessibility guidelines doesn’t guarantee inclusive design. It just satisfies minimum requirements.
Create perceivable content
People who can’t see to perceive illustrations, image links, icons, and charts require alternative text descriptions. These descriptions can be added to the HTML code and can be read by assistive technologies.
All videos should be captioned for users who can’t hear, and all audio content, like podcast episodes or meeting recordings, should have transcripts.
⏯ These days, many video players, allow you to automatically add captions to your content. The issue with automated captions is that they don’t follow best practices for creating an easy reading experience. They don’t include punctuation, often have incorrect spelling, and sometimes get the text entirely wrong. So always quality-check automated captions for accuracy add punctuation, adjust breaking points where needed, and add important non-speech information using square brackets.
A heading hierarchy is one of the seemingly simplest, yet most important things you can do to make your content accessible.
Identify headings in the markup, so that assistive technology users can scan the structure of the page and jump from heading to heading. It’s a much more efficient way to navigate. A good heading hierarchy functions as a map and helps users quickly understand the structure of your content, scan the page, and find the information they’re looking for.
Another important thing to keep in mind is that unlike visual presentation, assistive technologies need to linearize content because, with sound and braille, only one thing can be communicated at a time. When the content is linearized, it should still appear in a logical order, so the code order should match the visual order.
Lastly, you should never rely on one specific type of sensory cue.
Avoid instructions like “press the big blue button’” or “you will hear a beep once the test is finished,” since these instructions would be useless to people who need to adapt them to another modality.
Ensure your interface is operable
Every interactive element on the site should be operable with a keyboard, not because everyone who can’t use mouse or touch interactions will be a keyboard user. Keyboard operability translates well into other alternative modes of interaction, and screen reader interactions are often keyboard-based.
The amount of time people need to accomplish a task is very different from person to person! If you have any moving or auto-updating content, give people the option to stop it or get it out of the way entirely.
This one is simple: don’t have anything that flashes at more than three flashes per second as it can trigger seizures in some people.
Make your site understandable
Legibility is how easily you can recognize letters and tell them apart. Readability is the ease of reading words across a sentence or paragraph.
Some typefaces have letters that look very similar to each other, such as the capital letter O and the number 0, or the lowercase letters g and q. Legible fonts can be especially helpful for users with reading disabilities, but it makes it easier for everyone to read and understand the text.
One way to test a typeface on character ambiguity is to use the Il1 test. Try it for yourself! Pick a few typefaces you’re using and type out the capital letter I, the lowercase letter l, and the number 1 next to each other. Legible fonts will be designed in a way that makes it easier to differentiate these characters. In typefaces with poor legibility, the characters can look virtually identical.
You can improve legibility and readability by choosing typefaces with open apertures and counters, making sure there is enough space around the text, and have a uniform stroke.
Screen readers need to know what language they’re reading in order to pronounce it correctly. It also helps browsers display the right alphabetical characters. Define the language of your content programmatically, both for the whole HTML page and paragraphs of text that appear in a different language (for those pieces of text separately).
Keep repeating elements consistently (like navigation) from page to page. If there are elements that serve a similar function, they should be labeled, look, and behave the same way.
Important visual elements should have enough contrast with the background.
Designers often find accessibility requirements around color restrictive and worry that they can’t use specific colors or combinations if they want to make their designs accessible. While it’s true that accessibility requirements pose some constraints, they never limit which colors you can use in your palette, only how you use them.
Whatever colors you use in your work, make sure that at least some combinations have high enough contrast. The WCAG 2.1 require a contrast ratio between text and background of at least 4.5:1 for regular text, and 3:1 for large (18pt) and bold text (14pt) at level AA.
⁉️ Have you ever filled out a form that was returned with a bunch of fields highlighted in red, but no explanations why? It can be very frustrating. Try to be as specific as possible about the information you need users to enter.
Color can be effective for drawing user's attention to specific areas on the page and helping users identify different types of information at a glance. However, color cues are not helpful to users who are blind or perceive color differently. While you shouldn’t shy away from using color, to design inclusively, you need to make sure additional cues are also available.
Only use color as a secondary cue for communicating information.
Build a robust web content
Firstly, you should make sure that there are no validation errors in your markup. Markup errors like duplicate IDs or stray start and end tags can prevent assistive technologies from properly communicating information.
Secondly, make sure that all elements on the site, especially any custom components, have assigned roles, states, and properties.
How to manage accessibility testing?
Accessibility is a team effort! Every person in an organization needs to do their part in ensuring that products meet accessibility requirements. That includes developers, designers, product managers, content creators, and QA testers. Not everyone needs to be an accessibility expert, but everyone should know what accessibility considerations apply to their role. Visual designers should check their color contrast and pick accessible typefaces. UI designers should be mindful of different interaction modalities. Developers should make sure they are using accessible markup. Content creators should check that their materials are structured clearly and provide descriptions for images. Product managers should define accessibility requirements when planning a project and check that they are met.
It is better to test accessibility as you go and approach it as an iterative process.
There are many automated testing tools but most of them will identify the same types of issues. Automated testing tools are very limited. Interpreting the results will always require human judgment.
Here are some tools you can try:
- Lighthouse (Chrome)
- Axe (Chrome)
- WAVE (Chrome and Firefox)
- HeadingsMap (Chrome)
- Nu Html Checker
- TPG Colour Contrast Analyser
- VoiceOver (Mac users only)
- NVDA screen reader (PC users only)
WCAG Based Report
For all issues found by automated checkers, make sure to go through them manually before including them in your report.
If you’re evaluating a site as a whole, it can be helpful to organize your findings based on WCAG success criteria. You can create a table with the following columns:
- Success criterion name and number: identify the criterion by name and its reference number, and include a link to the WCAG document for convenience.
- Overall status: meets requirements / requires minor fixes / requires major fixes
- Comments: Details about your findings along with specific examples, screenshots, and recommendations wherever possible. When in doubt, describe the issue you’re encountering and who you think may be impacted.
Ideally, we will think about accessibility from the beginning of the design process and communicate it across teams. In reality, designers still don’t think enough about accessibility. Developers implement patterns based on visual designs without necessarily having enough information about the intended behavior. Product owners don’t always know what to look for to determine whether they have something accessible.
Thinking about accessibility needs to happen across several different roles and departments, so communication is key! The best solutions will vary depending on the project, organization, and amount of collaboration between departments. As much as possible, try to integrate this work with processes and practices that are already in place.
This is an easy, six-hour course that will make you an expert on accessibility for the web 💪