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.


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.


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.


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 4: WCAG Operable

Moving onto the second WCAG principle: Operable! 1.5 hours dedicated to studying today.

Things I accomplished

  • Read through all the Operable guidelines, success criteria, and sufficient techniques.
  • Added to my WCAG 2.1 POUR spreadsheet to include Operable.
  • Started drafting a blog post to sum up the perceivable principle as though I were explaining its what, why, and how to developers. Coming soon!

What I learned today

  • SC 2.2.2: “For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it” Carousels, I’m looking at you! I’ve never thought to create a hide option. Something to explore further, since it only makes sense to me to provide that kind of flexibility to users.
  • Guideline 2.5: Input Modalities. This was completely new to me! Of course, all those guidelines were added as part of the WCAG 2.1 upgrade, so I imagine that’s why. Admittedly, I’ll need to read about these more in-depth, as I’m not quite finding an immediate application to projects I’ve worked on in the past.
  • My undeveloped opinion: it would seem to me that 2.5.5 Target Size would be a no-brainer (in usability) and not nice-to-have AAA conformance level. I mean, it really benefits everyone (mobile users), right?

Making progress

Though I’m only two principles into WCAG, I’m actually surprised how much I already know and have applied in my web design/development work over the last 5 years. It goes to show that the best way to learn this stuff is working with others who know it, apply it, and care about it. It also hasn’t hurt to lurk in conversations about web accessibility on Twitter, Slack, and listserv emails. Those two factors have helped me advance forward, alongside the fact that I have close friends and family with various disabilities, who have helped me relate to the challenges many people face when navigating online.

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
  • decorative images or typography

Day 1: Initialization and WCAG Introduction

And here I go! To start off my journey to earn my Web Accessibility Specialist certification, I had to get myself in gear, get organized, and just start.

Things I accomplished

  • Launched this WordPress blog to make myself accountable to commit daily to web a11y study.
  • Set up a Google Calendar to keep myself on track to complete 80% of study materials by March 10, 2019, and beyond to April 3rd, when my exam happens (see my “How to Succeed” widget.
  • Read through WCAG 2.1 introduction non-normative).

What I learned today

Pyramid with 4 Principles as the foundation, 13 Guidelines, Success Criteria, and, lastly, Techniques.

  • WCAG layers of guidance include:
  • WCAG 2.1 updated 2.0 to be more inclusive of:
    • users with cognitive or learning disabilities,
    • users with low vision, and
    • users with disabilities on mobile devices
  • 17 new success criteria were appended to WCAG 2.0:
    • 1.3.4 Orientation (AA)
    • 1.3.5 Identify Input Purpose (AA)
    • 1.3.6 Identify Purpose (AAA)
    • 1.4.10 Reflow (AA)
    • 1.4.11 Non-Text Contrast (AA)
    • 1.4.12 Text Spacing (AA)
    • 1.4.13 Content on Hover or Focus (AA)
    • 2.1.4 Character Key Shortcuts (A)
    • 2.2.6 Timeouts (AAA)
    • 2.3.3 Animation from Interactions (AAA)
    • 2.5.1 Pointer Gestures (A)
    • 2.5.2 Pointer Cancellation (A)
    • 2.5.3 Label in Name (A)
    • 2.5.4 Motion Actuation (A)
    • 2.5.5 Target Size (AAA)
    • 2.5.6 Concurrent Input Mechanisms (AAA)
    • 4.1.3 Status Messages (AA)
  • An overhaul of WCAG is coming in a few year. In the meantime, 2.1 is the current recommendation, and 2.2 will be recommended shortly after that, before the new changes happens.

Journey to Learn All Things Web Accessibility Begins

“The more that you read, the more things you will know. The more that you learn, the more places you’ll go.”
Dr. Seuss, I Can Read With My Eyes Shut!

Thanks for coming! I’m here to learn web accessibility at a greater depth, so that I can become a Web Accessibility Specialist. In 100 days I plan to be (mostly) prepared for IAAP’s Web Accessibility Specialist certification exam. Along the way, I’d like to share with you what I learn each day.

Join me on my journey to learn about all things web accessibility from W3C documentation to user stories.