Day 70: How to Fail WCAG Level AA, Part 1

The last three days I’ve reviewed failures for WCAG Level A within Perceivable, Operable, and Understandable and Robust. Now it’s time to step up our expectations and look out how we’re all fairing at the middle conformance level: Level AA.

Things I accomplished

  • Read through Perceivable success criteria (Level AA) techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures.

What I learned today

Within the Perceivable principle, there are 11 additional success criteria to meet Level AA conformance within the latest WCAG recommendation (2.1).

5 SC within WCAG 2.0:

  • 1.2.4 Captions (live)
  • 1.2.5 Audio descriptions (pre-recorded)
  • 1.4.3 Contrast (minimum)
  • 1.4.4 Resize text
  • 1.4.5 Images of text

6 more SC added in WCAG 2.1:

  • 1.3.4 Orientation (new to 2.1)
  • 1.3.5 Identify input purposes (new to 2.1)
  • 1.4.10 Reflow (new to 2.1)
  • 1.4.11 Non-text contrast (new to 2.1)
  • 1.4.12 Text spacing (new to 2.1)
  • 1.4.13 Content on hover or focus (new to 2.1)

Examples that fail base conformance

SC 1.2.4 Captions (live):  In Level A, pre-recorded video with audio required captions. Level AA conformance fails when no open/closed or synchronized text stream is provided with captioning during live synchronized video with audio. This affects people with hearing impairments.

SC 1.2.5 Audio descriptions (pre-recorded): In Level A some sort of alternative (AD or text) needs to be provided for videos. Level AA conformance fails when there is no audio description track provided. This presents a challenge to users who may not be able to see the video.

SC 1.3.4 Orientation (new to 2.1): The user is prevented from using landscape view within a web app that does not essentially need to remain in portrait view. This affects people who magnify the screen and choose to view webpages in landscape.

SC 1.3.5 Identify input purposes (new to 2.1): No input data type or instructions for restricted data input are conveyed to the user. This affects people who use screen readers and some people with cognitive disabilities.

SC 1.4.3 Contrast (minimum): Background color and foreground text color have a contrast ratio of under 4:5:1 which makes it hard for people with visual impairments to perceive.

SC 1.4.4 Resize text: When text is resized within the browser at 200%, text is clipped. This makes reading your text difficult for people with visual impairments.

SC 1.4.5 Images of text: An image with text was used, even though it could have been presented in the same way with true text and use of CSS. This greatly affects people who magnify or zoom into their screen and the image pixelates.

SC 1.4.10 Reflow (new to 2.1): Media queries are absent. Content forces user to scroll horizontally and vertically. This presents a challenge to people who need to enlarge text or zoom into the screen.

SC 1.4.11 Non-text contrast (new to 2.1): Low contrast between text box and its background. No border is present. Like SC 1.4.3, this affects anyone with a visual impairment, including colorblindness.

SC 1.4.12 Text spacing (new to 2.1): Content boxes are restrictive in size and don’t allow for text spacing to be adjusted by the user without text being clipped. This greatly affects people with visual impairments, dyslexia, and cognitive disabilities.

SC 1.4.13 Content on hover or focus (new to 2.1): Custom tooltip is not persistent nor dismissable. This greatly affects people who magnify their screen.

In conclusion

I had to cut the list of Level AA SC in half since there are 20 additional criteria, in total. I’m feeling a little more confident about my organizations efforts to achieve Level AA, and am happy to see that other people are paying attention to color contrast and reflow issues. Pertaining to the Perceivable principle, I don’t think it takes to much effort to step up a level to remove even more barriers for people of all abilities.

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!

Day 68: How to Fail the Bare Minimum of WCAG Operable

Yesterday I got a head start on looking through the Level A conformance fails within WCAG’s perceivable principle. To keep that momentum going, I’ll be traversing through the other “bare minimum” recommendations to make sites mostly accessible with minor challenges. Today my sights were set on Operable.

Things I accomplished

  • Read Operable 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 14 bare minimum (Level A) success criteria recommended by W3C in order for websites to be operable (keyboard, mouse, touch, voice, switch). That’s almost half of Operable’s success criteria! These success criteria are, as follows:

  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (new in WCAG 2.1)
  • 2.2.1 Timing adjustable
  • 2.2.2 Pause, stop, hide
  • 2.3.1 Three flashes or below threshold
  • 2.4.1 Bypass blocks
  • 2.4.2 Page titled
  • 2.4.3 Focus order
  • 2.4.4 Link purpose (in context)
  • 2.5.1 Pointer gestures (new in WCAG 2.1)
  • 2.5.2 Pointer cancellation (new in WCAG 2.1)
  • 2.5.3 Label in name (new in WCAG 2.1)
  • 2.5.4 Motion actuation (new in WCAG 2.1)

When these fourteen operable success criteria are met, it enables people who use assistive technology and adaptive strategies to access, navigate, and interact with your static and dynamic content.

Examples that fail base conformance

SC 2.1.1 Fail: Several projects I’ve worked on have implemented hover-only focus styling effects or tooltips/pop-ups that excluded keyboard users.

SC 2.1.2 Fail: Modals can be tricky to create. When the keyboard user has no way to close the modal (Esc or Tab to close button) and get back to the content, this SC doesn’t pass.

SC 2.1.4 Fail: Creating single-character keyboard shortcuts without giving the user control to deactivate or change those shortcuts can greatly affect keyboard and speech input users.

SC 2.2.1 Fail: I am guilty of the client-side meta redirect! I know now that setting a timer of any kind requires extra consideration for people who need more time to make decisions and understand what’s going on. There is no user control in this situation.

SC 2.2.2 Fail: Carousels, the bane of my existence, can easily fail this success criteria if it doesn’t have a pause, stop, or hide mechanism. It’s taking choice away from any user. Additionally, it makes content less perceivable by people with visual or cognitive disabilities.

SC 2.3.1 Fail: I’ve seen video ads, fixed a web page, that are not only distracting, but have a flashing when its trying to grab a users attention. If the contrast is high and lasts more then 3 flashes, it’s a fail. Not only does it fragment attention for people with cognitive disabilities, but could create a severe reaction for people with photosensitive seizure disorders.

SC 2.4.1 Fail: No additional links are provided to skip repetitive content or navigate to different regions of the page. This creates an exhaustive experience for keyboard users tabbing through that web page.

SC 2.4.2 Fail: This is a current issue I’m battling. A web page doesn’t have a unique title or descriptive title that identifies the pages purpose or intent.

SC 2.4.3 Fail: I’ve seen some bad tabindexing, which ruins the relationship between keyboard (or screen reader) navigation and understanding content’s logic.

SC 2.4.4 Fail: This is a recent fail I’ve found in a recent accessibility audit. An image is linked, but there is not alternative text given to that image to let a screen reader user know what it’s purpose is.

SC 2.5.1 Fail: Custom complex gestures (requires multiple touch points) for touch devices is difficult for people with motor disabilities and those who use assistive technology that cannot equate these actions.

SC 2.5.2 Fail: No room for touch error was enabled. People with visual, cognitive, and motor disabilities could suffer from accidental button activation or disorientation when inadvertently taken to another part of the site.

SC 2.5.3 Fail: Visible linked text is different from a hidden accessible name (i.e. title or aria-label), which becomes an unknown hidden voice command for people who use speech input to operate controls and navigate the webpage. It also confuses understanding of content for screen reader users.

SC 2.5.4 Fail: No alternative means of control activation other than device motion (e.g. shaking or tilting) is available. This can exclude people with motor disabilities.

In conclusion

This was a lot to digest in under two hours. However, these base recommendations are so critical in order for people with disabilities (and everyone else) to be able to operate, navigate, understand, and appreciate a site and its services. I cannot afford to glaze over them, but rather advocate for at least this bare minimum in sites I collaborate on.

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.

 

Day 58: Identifying A11y Issues for Keyboard Users

Through studying WCAG (Guideline 2.1) and other web accessibility documentation and articles, I know that keyboard navigability and interoperability is important for a wide variety of users. Some important ideas to focus on when creating websites and keeping keyboard accessibility in mind:

  • Actionable elements (links, buttons, controls, etc.) must receive focusable via keyboard (WCAG SC 2.1.1);
  • All focusable elements need a visible border or highlight as a focus indicator (WCAG SC 2.4.7);
  • Logical (expected) tabbing order is set up appropriately (WCAG SC 2.4.3);
  • No keyboard traps, like poorly developed modals, have been created (WCAG SC 2.1.2).

The best way to test for keyboard accessibility? Test with a keyboard! It’s one of the easiest and cheapest ways to find out if you’re blocking someone from accessing your content. Critical (yet basic) keys to use:

  • Tab
  • Enter
  • Spacebar
  • Arrow keys
  • Esc

If any of those keys fail you when it comes to expected behavior for controls and navigation, it’s time to start digging into the code and figuring out what’s preventing that expected and conventional behavior.

That being said, I’ve started looking at section two of the WAS Body of Knowledge to fill in any gaps I have about identifying accessibility issues, starting with interoperability and compatibility issues. I’ve had a lot of practice checking for keyboard accessibility due to its simplicity, but I leave no stone unturned when it comes to studying for this exam and making sure I’m not missing more gaps in my web accessibility knowledge.

Things I accomplished

What I learned today

Today I didn’t learn much more on top of what I knew already, since I’ve had a lot of practice checking for keyboard accessibility due to its simplicity. However, I leave no stone unturned when it comes to studying for this exam and making sure I’m not missing more gaps in my web accessibility knowledge. Plus, I’m always eager to take the opportunity to advocate for keyboard testing as a reminder to designers and developers that not everyone uses a mouse and even well-written code can produce a different experience than initially expected.

One thing I did learn:

  • “A common problem for drop-downs used for navigation is that as soon as you arrow down, it automatically selects the first item in the list and goes to a new page.” (Keyboard Access and Visual Focus by W3C) I’ll have to watch out for this one I audit other sites, since I have not created a drop down with that type of behavior yet, myself.

Day 29: Making Dynamic Content Perceivable

WCAG 2.1 Success Criteria (SC) 4.1.3 and 1.3.2 are just two good reasons that we, as designers and developers, should be mindful of how and where we add new content while a user is interacting with our website. Today I spent an hour to see how deep I could dig into the concept of making dynamic content on a page perceivable to people who use assistive technology. I didn’t get as far or learn as much as I’d hoped, but I have included in this post a few of the resources I found helpful during my search.

As an aside, one fun thing about this journey has been revisiting familiar websites and running across familiar names in the web accessibility circle.

Thing I accomplished

  • Searched for articles and videos about making dynamic content perceivable, as well as managing DOM order, which both seem to go hand in hand.

What I learned today

  • When adding or updating content, be sure it’s appended after the point of focus the user is at. That makes sense, as many users (not just screen reader users) will likely not go backward in the flow of content.

Resources

Day 12: WCAG Reinforcements and ARIA Conformance

Time spent pursuing web accessibility knowledge: 2 hours.

Things I accomplished

  1. Watched a Deque webinar about WCAG compliance and measuring digital accessibility success. (I see another blog post in my future…)
  2. Submitted a support request to a vendor my work subscribes from, written with the intent of what a web accessibility specialist may recommend (identify the problem, point to references, and offer a tangible solution)
  3. Read ARIA’s conformance text.

What I learned today

I got so much out of Glenda Sims’ “Accessibility and Compliance” webinar! So many things to think about when evaluating how we measure the success of digital accessibility (what yard stick to use), the levels of goals to achieve, and evaluating our own intentions. This will be a future blog post, for sure, as well as a brief presentation at my next in-house accessibility meeting.

Part of the ARIA spec I read today was a little less inspiring. However, it did make me do a double-take on what parts of the spec are normative and non-normative. That’s something I grasped quickly in the WCAG spec, but not as quickly in the ARIA spec. I’ll need to look closer at this documentation to be sure I understand it enough to check off that bullet point of the WAS Body of Knowledge. So, in short, I learned that I don’t always know what I think I know. Not a new lesson, right?

Resource new to me

  • Poet Training Tool: learn when and how to write alternative text for images; practice writing alternative text

An Overview of WCAG’s Fourth Principle: Robust

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

Introduction

On that note, I’ll introduce you to WCAG’s fourth and shortest principle: Robust. This short, and likely understated, principle boils down to creating flexible content and interfaces so that everyone can access your website now, and in the future, in ways and methods you can’t plan for. Technology gets updated, outdated, and revived quickly in the 21st century. We, as developers, can’t plan for everything, but we can make strides to be forward-thinking with our code.

The fourth Web Content Accessibility Guideline‘s says: “Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies.” 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 flexible and more inclusive, inviting more people to interact with it in a way that maybe different than our own. “Robust” 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 use your website with very few hurdles.

Guidelines

To dig a little deeper, how can we ensure that everyone can understand the services and information we have to offer? Step down a level, from subjective to objective, via its guideline and success criteria. The one Robust guideline says that your entire webpage should be:

  • compatible

Success Criteria

Digging deeper, we find this guideline offers its own goals (success criteria) to target common accessibility problems. To sum up the 3 goals that the criteria are aiming for:

  • markup should be parsable (valid and complete)
  • a name, role, and value should be assigned (to custom elements)
  • status messages about changes or alerts should be announced, even without focus on that element

I encourage you to check out all the success criteria, now that you are more confident in understanding the guideline within the fourth principle. Additionally, read How to Meet WCAG, which is add value to your understanding and clear 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’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 10 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 Robust principle. I’ve only read through his first form pattern about registration forms, but it reinforces the importance of semantic markup. Clear markup benefits all users.

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.

Introduction

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.

Guidelines

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.

Conclusion

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)