Posted on by Ela Gorla in Design and development, Standards
Tags: Assistive Technology, WCAG
Most people working in digital are aware of the Web Content Accessibility Guidelines (WCAG) and know they can help make digital products work for everyone. However, the way the guidelines are discussed often leads to mixed assumptions about what they cover and how they should be used.
WCAG is recognised internationally as the standard for digital accessibility. They are often mentioned in organisations’ accessibility policies and referenced in many laws and regulations worldwide. Our WCAG primer provides an overview of the guidelines and how they’re structured.
In this post, we look at some of the most common misconceptions about WCAG and explain how they fit into everyday design, content, and development decisions.
When the very first version of the guidelines (WCAG 1.0) was published in 1999, the internet was largely synonymous with websites. As a result, the guidelines were pretty much focused on web content built with HTML.
This is no longer the case. The current version of the guidelines, WCAG 2.2, is applied to all digital content from websites to web applications, native apps, and digital documents. While some techniques in WCAG may refer to a specific technology (HTML, ARIA, PDF and so on), the principles, guidelines, and Success Criteria (SC) are technology-agnostic.
Let's take a look at the very first SC in WCAG 1.1.1 Non-text Content:
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose [...]
This applies to all forms of digital visual content, from photos on websites to infographics in PDFs and icons in native apps.
Regardless of the type of digital product or technology you work on, you can and should apply WCAG to it.
When thinking about accessibility, some people assume it's all about screen readers.
Screen readers are one of the most well-known assistive technologies out there. They help many people, including people who are blind, have low vision, and some people with thinking disabilities, access web content. You can see some screen readers in action in our browsing with a desktop screen reader and browsing with a mobile screen reader blog posts.
Some SC in WCAG 2.2 focus on coding practices that make digital content work well with screen readers and other assistive technology. But WCAG go far beyond screen reader support. The SC cover a wide range of accessibility needs, including visual design, media content, clear language, and keyboard access.
This means that applying WCAG is relevant to everyone in a digital team, including content writers, UX and UI designers, and media producers.
As WCAG contains requirements around the use of colour, images, and multimedia content, some people believe accessible websites and apps must have a flat black-and-white text only design, with minimal use of images, multimedia, and a basic layout.
But minimalist websites and apps can actually be inaccessible for some people. Images and multimedia content are an important aspect of accessible products, as they can make information easier to understand for some people with thinking disabilities. Colour can also help reinforce meaning and help people identify items such as headings and links, as well as understand information.
Accessibility is not about removing elements that may be inaccessible to some, it's about using them in an inclusive way and providing alternatives when necessary.
On the TetraLogical website, we use bold colours, plenty of images, and our homepage even includes an animation. However, we make sure that people accessing the website can customise their experience to best suit their needs and preferences. For example, a Pause button allows people to pause the homepage animation, and our content adjusts as expected when people change colours and font sizes in their settings.
WCAG-compliant websites don't need to be "basic". They need to be adaptable.
WCAG 2.2 contains 86 Success Criteria, each assigned to one of three conformance levels:
You may think your products should meet all 86 SC. This is not the case.
Most organisations should aim to achieve Level AA compliance. This means complying with 69 SC. By meeting Level AA compliance, your products will be accessible to most people with disabilities.
Level AAA SC cover more advanced requirements, to address the needs of specific groups of disabled people. Only organisations offering products or services specifically to those groups of people are required to implement them.
For example, SC 1.2.6 Sign Language (Prerecorded) requires that:
Sign language interpretation is provided for all prerecorded audio content in synchronized media.
Providing sign language interpretation for video content greatly benefits Deaf people whose first language is sign language. Organisations whose main target audience includes Deaf people should make sure all their video content offers sign language interpretation. Other organisations are encouraged to do the same when feasible; however, in some cases it may be too costly or not achievable.
As stated in WCAG 2.2:
It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.
Focus on achieving Level AA conformance across your products and services first. You can then look into Level AAA to identify those additional requirements you can implement to further improve your products. You can learn more about Level AAA in understanding WCAG 2.1 Level AAA.
WCAG covers a wide range of requirements that will help you reach technical accessibility. For example, WCAG-compliant products support keyboard access and work well with screen readers and other assistive technology; they use colour combinations that meet a minimum contrast ratio; provide alternatives for images and multimedia content; and so on.
This is all key to inclusive products, but it's only an aspect of it. To be truly inclusive, websites and apps must make it easy for everybody to:
Applying WCAG together with usability and inclusion best practices, such as the Inclusive Design Principles, will allow you to build truly inclusive products.
Conducting inclusive usability testing is also key to ensuring your websites and apps are easy and enjoyable for everyone to use.
Find out how our Assessments can help you validate your products' conformance with the Web Content Accessibility Guidelines (WCAG), or learn how our Consultancy service can help your organisation reach accessibility in the long term.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。