Accessibility Principles for ICT (WCAG)

Accessibility is the successful access that people with disabilities have to content and spaces. As I mentioned at the end of Accommodation versus Inclusive Design, I concluded that accessibility is a mismatch between the design and a user’s needs. On the web (or with ICT – information and communication technology) we can create that match by starting with W3C’s web content accessibility guidelines (WCAG). The 4 principles of WCAG are:

  • perceivable: broadening the sensory experiences to include sight, sound, and touch,
  • operable: all interactive components and navigation are navigable and usable,
  • understandable: content, component functionality, and design are easy to understand, and
  • robust: content & functionality is compatible with a variety of browsers, devices, and assistive technologies.

Challenges on the web

I won’t go into further detail about all its success criteria just because I’ve written quite a bit about them while studying for the WAS exam. However, I do want to mention some common challenges that people face when on the web, and how accessible design can help designers and developers be aware of how to address these barriers.

Problem area
Solution(s)
Images
  • Use alternative text or a visible caption/description
Color
  • Supplement color-coding with other coding information (shapes, texture, etc.)
Contrast
  • Foreground color should stand out (high contrast) against the background color
Video & audio
  • Include captions and transcripts with video and audio files
  • Include audio description with video
Links
  • Use understandable text with intent, functionality, or destination of the hyperlink
Headings
  • Create a logical outline with the headings to make it well-structured and navigable
Keyboard access
  • Make each interactive component on the page reachable by the keyboard
  • All interactive components should create a logical tabbing order
  • Focus should be visible on interactive components
Tables
  • Assign headers to columns or rows
Forms
  • Explicitly assign a label to every form input
Dynamic JavaScript
  • Explicitly assign a name, role, state and/or properties
  • Assign point of focus when widgets are created
PDF documents
  • Create tags for all structures in a PDF

Universal design can help

Universal design creates products and environments that the vast majority of people can use, taking into account the natural physical diversity among people. Universal design doesn’t just think about people with disabilities, it thinks about a lot of people. By expanding our view from accessible design to universal design, we can make a more usable experience for a lot more people.

Stay tuned for my next post that will go further into universal design, its origins, and its solutions in the context of the physical world.

Additional reading

Day 67: How to Fail the Bare Minimum of WCAG Perceivable

The next few days are going to feel like review. And, yet, the next few days should bring satisfaction of putting some of this knowledge to use.

Today I landed on looking over WCAG’s perceivable principle again in order to focus on the success criteria at the base conformance level, and dug into sufficient and failure techniques. My intention at this point in my journey was to approach this with another person’s perspective, and better understand how content and components might inadvertently be “invisible” to anyone who has a visual or auditory impairment or makes use of assistive technology.

Things I accomplished

  • Read Perceivable success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered.

What I learned today

There are 9 bare minimum (Level A) success criteria recommended by W3C in order for websites to be perceivable (seen, heard, touched). These success criteria are, as follows:

  • 1.1.1 Non-text content
  • 1.2.1 Audio-only/Video-only (pre-recorded)
  • 1.2.2 Captions (pre-recorded)
  • 1.2.3 Audio description or media alternative (pre-recorded)
  • 1.3.1 Info and relationships
  • 1.3.2 Meaningful sequences
  • 1.3.3 Sensory characteristics
  • 1.4.1 Use of color
  • 1.4.2 Audio control

When these nine perceivable success criteria are met, it enables people with visual impairments and hearing impairments to enjoy your content and interactive components.

Examples that fail base conformance

SC 1.1.1 Fail: Customized radio buttons in a survey were invisible to me when I was using Windows High Contrast Mode. That’s because they used a background-image to replace the actual radio button, which was also set to opacity=”0″. This failure results in excluding people with visual or cognitive impairments who use HCM or custom stylesheets.

SC 1.2.1 Fail: Audio files of a recorded meeting do not have a transcript or long description that provides equivalent information in text format for people who have a hearing impairment.

SC 1.2.2 Fail: So often do I see recorded video with sound, but no captions are provided. As a note, YouTube does provide auto captioning which can be sufficient to meet SC 1.2.2, but could result as a failure if the captioning is not accurate and could leave out important information. A manual check may be necessary. This failure excludes people with hearing impairments.

SC 1.2.3 Fail: Also, another common fail. People don’t realize this is not a nice to have feature. Leaving out audio description in a video that has a lot of undescribed actions within the video is a fail at WCAG’s most basic level. This can exclude people with visual impairments.

SC 1.3.1 Fail: Another recent fail I found in an ongoing accessibility audit was the discovery of tables with out row or column headings identified. The relationship of the data isn’t explicit and may exclude people with visual impairments.

SC 1.3.2 Fail: Related to the prior fail of SC 1.3.1, I also found tables that were used for layout rather than relational data. This can confuse people who use screen readers (visual and cognitive impairments) when a table is read aloud, but the content’s relationship is meant to convey something else.

SC 1.3.3 Fail: I see this failure a lot in content I receive to post online. Within the content, a spatial location is inserted (e.g. “the photo to the right”). This is not only meaningless to people with visual impairments. It also is meaningless to mobile users who see a different layout on their smaller screen, but that isn’t an accessibility issue.

SC 1.4.1 Fail: Surprisingly, I still run across input error messages that stand out in red, but don’t offer any other indicator that the user has made an error. This can exclude people with visual disabilities from submitting forms.

SC 1.4.2 Fail: The days of inserting background music on a webpage seem far behind us, but what about those ads that autoplay on a webpage? If the autoplay doesn’t have a pause or close button, the page fails SC 1.4.2. I haven’t run across this fail personally, but it would interfere with a screen reader users interaction with the page due to the uncontrollable interruptions. Not to mention, how annoying that would be to everyone else visiting the site.

In conclusion

I’m horrified that many of the most basic success criteria still fail on a regular basis across the web. None of these are even new in WCAG 2.1. What really astounds me is how easy and inexpensive most of these techniques are to follow. Captions and audio descriptions aside, since those are usually outsourced and need to be budgeted, the other seven leave no excuses, in my mind. We need to do better to make the bare minimum part of business (development) as usual, and not even consider them an accessibility issue, but rather as best practice in content creation, design, and development.

 

An Overview of WCAG’s First Principle: Perceivable

4 guidelines. 29 success criteria (including 9 Level A conformance. 11 Level AA conformance. 9 Level AAA conformance). And so many more sufficient, advisory, and failure techniques that are ever changing. This is just one way the World Wide Web Consortium’s (W3C) “Perceivable” principle within the current Web Content Accessibility Guidelines (WCAG) recommendation can be broken down. But, wait, there’s so much more documentation to follow! However, looking at it that way can suddenly leave one feeling intimidated, exhausted, and uninspired to learn even just this small segment of the golden standard of web accessibility.

Sadly, I get the impression that many web developers, such as myself, feel this way when referring to this documentation. We go in, quickly find what we need, and get out as quick as possible before the abyss of text and jargon overwhelm us. Or, we find a non-normative siteto help us understand the documentation and never once visit the normative documentation (there’s nothing wrong with that, by the way).

I’m not here to judge you, but rather I am on a long road to better understand the whys and hows of web accessibility, so that I can become a better developer, designer, and person. On that journey, I can only hope to impart some of what I’ve gained and inspire you to take your own journey, no matter the length.

Introduction

On that note, let me introduce you to the principle labelled as Perceivable. As stated earlier, it appears to have a ton of components, so to speak, but it all boils down to giving everyone the opportunity to access your application and content by the sense that is dominant for them. For instance, ironically, I rely heavily on my vision to pull in information around me (though I’m visually impaired), but supplement with hearing and touch to fill in the gaps. Lucky me, in such a visually dominant world we live in. Virtually, I have to enlarge print, zoom into pages, and minimize business on the page (yay, for Reader View!). However, I recognize that not everyone is like me. There are people who rely heavily on hearing or touch to interact with their environment. Additionally, there are others who can see much better than I can. And, yet, we all live in the same world, trying to access the same Internet.

The first Web Content Accessibility Guideline‘s says: “Information and user interface components must be presentable to users in ways they can perceive.” Take note, this is just the general idea with goals that is more objectively defined in the success criteria and techniques.

To me, this principle offers us some low hanging fruit to successfully make our websites more inclusive, inviting more people in, who arrive with a different means to interact than our own. Whether someone sees (visual, screen), hears (audio, screen reader), or feels (Braille output) in order to read a blog, buy a plane ticket, or learn a new skill, it shouldn’t matter. They should still be able to partake in all those things.

Guidelines

To dig a little deeper, how can we ensure that everyone can access the variety of services and information on the web? Trail down through the levels within the principle, from subjective to objective, via their guidelines and success criteria. The Perceivable guidelines say that content and components should:

  • provide text alternatives
  • have specific considerations for time-based media (audio and video)
  • be adaptable through structure and formatting
  • be distinguishable in various contexts

Success Criteria

Digging down further into these 4 guidelines, we find each guideline offering it’s own criteria to target potential accessibility issues. Rather than writing out all 29 criteria, which could be several blog posts in themselves, I’ll expand upon the guidelines to include what some of the key criteria are aiming for or why:

  • provide text alternatives to items that aren’t text already (non-text), therefore, giving your users the ability to access information through their chosen medium or format
  • couple video and audio, whether live or pre-recorded, with text (captions, transcript) or audio (audio description)
  • allow for diverse user choices that may affect your design and define clear connections between content on the page; this includes flexible screen orientation, defined input types, and using semantic HTML
  • ensure all content is “visible”, whether it’s providing good color contrast, appropriate foreground and background audio contrast, or creating more white space between text and elements on a page.

I encourage you to check out all the success criteria, now that you are more confident in understanding the guidelines within the first principle. If that page still looks too intimidating, try reading How to Meet WCAG, which is more approachable and provides clearer techniques that help you visualize how to meaningfully apply what you’ve learned.

Conclusion

Regardless of how you take your next steps, I hope you are less afraid to dive into WCAG documentation and its supplemental materials and guides to help you understand web accessibility. Despite all the technical specs, take a moment to sit back and empathize with people who have different levels of abilities than your own. Ask yourself, “How could my website prevent a person with a visual, hearing, physical, or cognitive impairment from entering in and walking away with what they came for?” In the end, it’s the empathizing and relating to your wider audience that will make your accessibility efforts a success, rather than all the vast technical memorization and compliance, in which you devoted your time.

An aside

This is Day 5 of my 100 Days of Accessibility journey to learn all things web accessibility. The best way I keep information in my brain is to share with others, so I spent my “study” time today writing this post, so that I could better assimilate the information in a more permanent way, while offering you a step forward into understanding web accessibility a little better.

If you’re trying to learn more about web accessibility, you don’t have to do anything as extravagant or dramatic as I’m doing. Today I just discovered Learning A11y, which provides a list of resources to help you get started learning. We’re all headed for the same destination here, but our learning styles and journey may vary.

Day 3: WCAG Perceivable, Part 2

Time spent studying today: 1 hour. Again, another weekend day that I successfully allotted time for study. I’ve been through three rounds of 100 Days of Code, a 9-month course on Udacity, and one round of 100 Days of A11y. I’m no stranger to dedicating time, figuring out a process, and sacrificing blocks of time I could’ve spent with family. However, I’ve seen what I can accomplish and how I can progress, so that gives me some confidence in continuing to put time aside to prepare in-depth for this challenging exam.

Things I accomplished

  • Closely read through all of the perceivable principle’s success criteria
  • Memorized the 4 guidelines under the perceivable principle:
    • Text alternatives
    • Time-based media (audio, video)
    • Adaptable
    • Distinguishable
  • Added to my POUR spreadsheet to include more techniques

What I learned today

9 out of the 29 success criteria in the first WCAG principle are Level A. It’s like reading, “these are just the basics, folks, which gets you almost a third of the way there”. Yet if they’re so basic, why aren’t all web designers and developers trained to meet the bare minimum to create websites that are better for everyone? Is it really so much to ask for alternative text for images, captions for video, or volume controls for audio?

Other new-to-me tidbits:

  • Logos and brand names are exempt from Contrast criterion (SC 1.4.3) and Images of text (SC 1.4.5).
  • Captions and images of text are exempt from the new Resize Text criterion (SC 1.4.4).
  • There’s a suggestion for appropriate audio contrast when it comes to foreground and background noise (see SC 1.4.7)

Day 2: WCAG Perceivable, Part 1

Day 2… a weekend day, which can make it harder to make time to set aside for studying. I did it, though, spending roughly an hour and a half working through documentation, mulling over only part of the first WCAG principle, and working toward visualizing the different guidelines, success criterion, and techniques. I didn’t get as far as I would’ve liked either, yet this is the deepest work I’ve ever done at combing through the WCAG docs.

Things I accomplished

  • Read through the Perceivable¬†principle in WCAG 2.1 documentation (normative and non-normative).
  • Started a spreadsheet to visualize relationships between principles, guidelines, success criterion, and techniques. Specifically I mapped out the perceivable principle.
  • Discovered¬†techniques that failed to meet criterion within the perceivable principle.
  • Dug into helpful solutions to common situations (satisfactory techniques) via W3C’s “How to Meet WCAG 2.1“. Seriously, this resource is extremely helpful for all those situations I’ve had to figure out how to be more inclusive, and the documentation is there to back up my decision when I have to present it to my team!

What I learned today

In the process of trying to memorize guidelines and success criterion, I reinforced the image of the layers that exist within WCAG:

Additionally, looking closer at each criterion helped me to identify the additions made to WCAG 2.0’s first principle:

  • Orientation
  • Identify input purposes
  • Identify purpose
  • Reflow
  • Non-text contrast
  • Text spacing
  • Content on hover or focus

When reading through the description about text alternatives, I ran across a concept new to me: “simpler language” is considered a text alternative under Guideline 1.1. Also, there are some identified exceptions to the text alternative guideline. Those exceptions apply to:

  • controls or input fields
  • time-based media
  • tests/exams
  • specific sensory experiences
  • CAPTCHA
  • decorative images or typography