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
  • Use alternative text or a visible caption/description
  • Supplement color-coding with other coding information (shapes, texture, etc.)
  • 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
  • Use understandable text with intent, functionality, or destination of the hyperlink
  • 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
  • Assign headers to columns or rows
  • 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 69: How to Fail the Bare Minimum of Understandable and Robust

Today I’m concluding Level A conformance evaluation, looking at the Understandable and Robust principles of WCAG.

Things I accomplished

  • Read Understandable and Robust 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 or read about.

What I learned today

There are 5 bare minimum (Level A) success criteria recommended by W3C in order for websites to be understandable (readable, predictable). These success criteria are, as follows:

  • 3.1.1 Language of Page
  • 3.2.1 On focus
  • 3.2.2 On input
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions

There are 2 bare minimum (Level A) success criteria recommended by W3C in order for websites to be robust (compatible for assistive tech and adaptive strategies). These success criteria are, as follows:

  • 4.1.1 Parsing
  • 4.1.2 Name, role, value

When these seven success criteria are met, it enables people of different abilities, no matter what aids they use, to understand and continue using your online content and services.

Examples that fail base conformance

SC 3.1.1 Fail:  A lang attribute is not present on the html element. The language of the web document needs to be explicitly defined for screen readers and browsers.

SC 3.2.1 Fail: Link opens a new tab. This should be avoided if not critical for the user because it can be disorienting to people of all abilities. I still see this a LOT for links, in particular, where no alternative of additional warning text is provided.

SC 3.2.2 Fail:  Form submitted ‘onchange’ rather than allowing the user to submit the form when they were actually done. This impairs people from completing forms accurately and at their own pace.

SC 3.3.1 Fail: No descriptive error text was provided for required fields to help user know why their form was unable to submit.

SC 3.3.2 Fail: No label was associated with an input control by using ‘for’ and ‘id’.

SC 4.1.1 Fail: I’ve recently run across a few of these failures! They usually come down to typos. For instance, if quotes or brackets aren’t closed, or no space is left between attributes, it can create an incomplete picture for assistive technologies and browsers.

SC 4.1.2 Fail: No role, name, or state were provided on a custom component control with a div or span.

In conclusion

Though this evaluation was shorter, I recognized several things I knew to cause accessibility problems, but I didn’t realize how bare minimum they were in this specification and how long they’ve been around (none are new in 2.1). I would be bold enough to say that all of these are easy failures to avoid and come at no real cost to the developer who knows what she’s doing. Now, if you’ll excuse me, I have a few bare minimum things to fix in my code this week…

Tomorrow I’ll start looking at the next level up, which is a common goal for many organizations, including my own. I’ll find out if we’re meeting that goal or not!

An Overview of WCAG’s Third Principle: Understandable

3 guidelines. 17 success criteria (including 5 Level A conformance. 5 Level AA conformance. 7 Level AAA conformance). And several ever-changing techniques that are sufficient, advisory, or a failure. As I pointed out in my Perceivable principle and Operable principle reviews, these stats are just one way the World Wide Web Consortium’s (W3C) “Understandable” principle within the current Web Content Accessibility Guidelines (WCAG)  2.1 recommendation can be broken down.


On that note, I’ll introduce you to WCAG’s third principle: Understandable. As stated earlier, it has several components, so to speak, but it all boils down to giving everyone the opportunity to successfully understand the content and interfaces on your website. No matter a person’s education, native tongue, or prior experiences, your website should be relatively easy to understand when they read text, interact with form controls, or perform an interactive task.

The third Web Content Accessibility Guideline‘s says: “Information and the operation of user interface must be understandable.” Of course, this is a generally defined idea, leading up to more objective goals (success criteria) and techniques.

This principle offers us suggestions and insights to successfully make our websites more inclusive, inviting more people to interact with it in a way that maybe different than our own. “Understandable” models a way for us to be considerate of people who think differently, move differently, and perceive differently than ourselves. No matter the physical and cognitive differences among us, everyone should still be able to understand your website with very few hurdles.


To dig a little deeper, how can we ensure that everyone can understand the services and information we have to offer? Trail down through the levels within this principle, from subjective to objective, via its guidelines and success criteria. The Understandable guidelines say that your entire webpage should:

  • be readable
  • be predictable
  • include input assistance for forms

Success Criteria

Digging even deeper into those 3 guidelines, we find each guideline offers its own goals (success criteria) to target common accessibility problems. Rather than writing out all 17 criteria, which could be blog posts in and of themselves, I’ll sum up a few of the guidelines to include some goals that the criteria are aiming for:

  • define a language for the whole page; and parts of the page when different languages are used
  • help people understand complex information with summaries, expanded abbreviations and definitions, or other simplified text alternatives
  • keep your labels and input interactions consistent and predictable
  • offer help text for forms to help prevent input errors
  • clearly point out input errors and how to resolve them

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


Regardless of how you take your next steps, I hope you’re becoming more confident to dive into WCAG documentation and its supplemental materials and guides to help you better understand web accessibility. I can’t emphasize enough that, despite all the technical specs, taking a moment to empathize with people who have different levels of abilities than your own is so important. 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 9 of my 100 Days of Accessibility journey to learn all things web accessibility. The best way I retain information is to share with others, so I spent my “study” time today writing this post to advance my knowledge, and yours, too.

As an aside resource that I’m currently reading, Form Design Patterns by Adam Silver (Smashing Magazine) is reinforcing my assimilation of the Understandable principle. I’ve only read through his first form pattern about registration forms, but it reinforces the importance of input controls being predictable and reinforced with clear labels, help text, and error prevention. In the end, it benefits all users to make forms better!

As an aside code experiment to reinforce “Understandable”, and a chance try some code new to me, I put into action W3C’s H62 technique: Using the ruby element to assist with pronunciation.

Day 8: WCAG Understandable

It’s Friday! And I’ve managed to balance my time just enough to dedicate to study for a week straight. I’m trying not to bounce around too far afield, so I’m back at studying WCAG, acknowledging I’m past the halfway point.

At this point, I’m gaining a lot more confidence in myself and the hope of passing this test. I should interject that I’ve been actively learning about web accessibility over the past year and a half just through Googling, applying that mindset to every project I touch, and listening to accessibility experts.

Things I accomplished

What I learned today

  • No guidelines or success criteria were appended to the Understandable principle within the WCAG 2.1 update.
  • I’ve found that many of these success criteria are well-applied across the web. At least in web projects I’ve collaborated on.
  • I found one app on my iPhone that is inaccessible, but at least they tell on themselves in a “secret message for screen readers” and recommend a different app. (Spoiler: it’s Libby, and they recommend using Overdrive instead)