CPWA Certified!

5 weeks after sitting for the CPACC exam (end of December), I received an e-mail congratulating me on passing the Certified Professional in Accessibility Core Concepts (CPACC) certification exam, established by the International Association of Accessibility Professionals (IAAP). What a great way to end my work week! Once again I’d managed to exceed the pass score (and my expectations) with a score of 731 on a scale of 200-800.

At the end of 2018 I began my certification journey, starting with the WAS exam. Setting aside 100 days to study to be a Web Accessibility Specialist, I claimed my WAS certification in May 2019. I was ecstatic and invigorated. If I could do that, maybe I could go ahead and fulfill my desire to go all the way for CPWA (Certified Professional in Web Accessibility) by studying for the CPACC. I’d have to take a break over the summer to put focus back on other parts of my job. My intentions didn’t waiver, and I received support, once again, from my employer to study for and take the CPACC exam in mid-December 2019.

45 days of self-directed study, working through Deque’s CPACC certification courses, asking questions to experts, and digging through online resources truly paid off when it came to achieving my ultimate goal. During that study I felt that the generalized information wasn’t as easy to consume as the technical information, and that I may just fail on the second half. Despite my ups and downs, I persevered in determination.

Special thanks, once again, to so many who helped me get this far:

  • IAAP for giving me another opportunity to further my education and improve my craft,
  • the Alaska State Libraries, Archives, & Museums for supporting my continuing education,
  • the State of Alaska webmasters and our ADA coordinator who cheered me and expected so much of me,
  • my friends with disabilities who openly received more of my questions,
  • my family for being supportive and understanding that this is something I needed to spend time on at home,
  • Deque University for awarding me a scholarship, enabling me to take their courses, and
  • the Twitter, Slack, and LinkedIn web a11y (accessibility) communities for answering my questions and cheering me on; there are just too many names to mention without leaving someone out!

I wish I could list all the specific individuals that cheered and encouraged me all the way, but I’d feel bad about leaving out a name.

If you’re still considering getting certified at any level… do it! Not so much for the certificate, but for the chance to deepen and broaden your own understanding of web accessibility and people with disabilities. Do it to make yourself a better web designer and developer. You can do this. Stay motivated, understanding that the more you know and practice, the more you’re helping build a better web for everyone.

I am now Amy Carney, Certified Professional in Web Accessibility (CPWA), and I am still learning. Web accessibility is my passions, so contact me through my blog if you have web accessibility questions or want to share your own lived experience. Or just say “hello” to me on Twitter where I talk about this stuff a lot. For now, I’ll be out here, doing the work, and hoping to inspire a few other people to join in, helping to change minds and policies. And maybe even do some celebrating after this huge accomplishment.

A reflection on my CPACC journey

Let me start by saying, Wow! What a whirlwind this second round of studying felt like. I think it’s because I dedicated only 45 days, rather than 100 days. Do I think I needed 100 days to study for this? Probably not. And yet, 100 days (or at least 70) would have let me spread out the material more. Most days I felt like I was cramming in a lot of information, and spending 2-3 hours each day walking through Deque coursework, Coursera videos and text, IAAP Body of Knowledge sections, and visiting recommended online resources. All the while trying to keep myself organized, stick to my self-imposed schedule, and output what I learned into concise blog posts about each topic covered in the CPACC Body of Knowledge. The exam showed me that I improved my understanding, but I still struggle in some areas.

It will be 4-6 weeks before I receive word of whether I am CPACC certified or not, but the following are my observations and feelings after I sat for the exam.

What I sailed through

WCAG and its POUR principles were, by far, the easiest thing for me to test well in. How could I not? I’d already (over)prepared for the WAS (Web Accessibility Specialist) exam and passed with a very satisfactory score. I wasn’t just trying to earn a certification; I was out to learn as much about web accessibility as I could. And I did. WCAG was a huge part of my learning earlier this year. To add to that, I work with those principles on a daily basis. I evaluate my own web design and development work by asking myself if my organization’s content is perceivable, operable, understandable, and robust for people with disabilities. It’s a part of me now, so I knew going in that I didn’t have to spend much time studying that information. Again, I’m not saying I passed, but the POUR questions on the exam took me the least amount of time to mull over. Thank you, WAS Certification!

Universal design (UD). This one I worried over. The CPACC Content Outline gave me the first clue that these principles and concepts needed my attention and time. Did I want to spend a lot of time on them? Not really. And yet, I heeded the outline’s implications, and took the advice from a few other people who earned their certification already. It didn’t make sense to me at the beginning to be deeply familiar with UD, but by the end I was glad I was. Not only did it help me answer questions about the principles and application of the principles, but it motivated me to ask my own questions about the key differences between accessibility, universal design, and inclusive design. Thank you to everyone who contributed to a conversation on this topic, and verified what I was learning.

An honorable mention:

  • theoretical models of disability: not to say that I aced all of those questions, but I feel like I have a better grasp on these perspectives and have started adjusting my own attitudes and language accordingly (a whispered “thank you” to the person on Twitter that keeps ranting about ableism.. you know who you are, and I’m listening;

Looking back just now, I see that most of my strengths currently reside in the “Accessibility and Universal Design” section of the outline.

What I tripped over

Despite the time I put into learning and the advice I took, I still experienced several dreadful moments during the exam, when I would read a question repeatedly, and cringe, thinking, “I’ve made a mistake! I was not ready for this at all.” As a matter of fact, the first two questions were like that, which was not a good way for me to start the exam. I can’t remember exactly what they were, but I do recall some of the topics I found myself questioning my own answers on several occasions.

Universal design in learning. This one I studied for. I even sketched out my own matrix before realizing there was one online through CAST’s website. I think it was just the text-heavy content that I didn’t memorize. I understand the underlying thinking behind it, but I started doubting if I’d truly incorporated it into my thinking. I’m still certain I couldn’t rattle off most of that information, if it wasn’t presented to me in multiple choice format. Oddly enough, learning about UDL got me thinking a lot of how to teach my co-workers about it since some of them create online coursework and webinars.

Laws. Thanks to the warning of others, I made sure I spent time with this section. However, I still couldn’t quite manage to recall some of the names and details of some of the international laws (I won’t deny I’m American-centric). It’s something I’ll continue to struggle with when someone inquires about other countries and the standards and laws they’re following. On a positive note, knowledge about the UN Declaration of Human Rights, UN Convention on the Rights of Persons with Disabilities, and their impact on legislation will forever stick with me.

Data trends. This one I knew I’d struggle with. Not because of numbers, but more due to my convoluted understanding of what I actually needed to know. How many people have a disability? I got this. You want more details and specifics. Umm… I know the perfect resource to direct you to! But, no, this information is not in my head. If I’m trying to build a case for accessibility, I’d like to be more confident in this area.

Types of disabilities. I thought for sure this was one I’d sail through. And I did with a several of those questions. However, there were a few that made me question my own competency about the people we’re doing this for. I thought I knew a lot about conditions and their causes, but I am now convinced I’m not paying enough attention to the what and why of disabilities. I may have focused too much on their challenges and how to solve them.

Organizational management and governance. This was another topic that I questioned myself on. I worried a little about this one because I didn’t get to that material until a few days prior to the exam. Additionally, I hadn’t finished my blog post about that section prior to the exam either, so I didn’t give myself the chance to internalize it well. I spent time changing and re-changing some of my answers about these, too, because the things I (thought) remembered well didn’t match the language that was used in the exam. On a positive note, I was grateful for this section because it gave me affirmation that my organization is on the right track to maturing its accessibility processes.

Reflecting over the areas I was uncertain about, I had already identified these same areas during my study time, and knew they could still trip me up during the exam. Thankfully, multiple choice questions gave me some leeway in identifying what I was familiar enough with. And taking time to review all my answers (maybe more than once), before submitting them, restored some confidence in that I had still learned quite a bit about accessibility. Enough to have (felt like) I answered most of the questions correctly

When my results come, I’ll know for sure how much I understood within the other CPACC Certification Outline sections: “Disabilities, Challenges, and Assistive Technologies” and “Declarations, Standards, Laws, and Management Strategies”.

This is still not the end (for me)

Throughout this process (CPACC, WAS, and even earlier), I’ve felt fortunate that I haven’t yet experienced burnout. Taking a break between certifications was a good choice on my part. Dedicating a lengthy amount of time to study and internalize was a good choice. Choosing to study accessibility with definitive goals to reach was a good choice. Meeting accessibility experts and champions, listening more to things people with disabilities have to say, and pushing along my organization’s progress… these were all unexpected bonuses along my journey.

But hear me when I say, I’m still learning. I’m still taking it all in. I still have stories to hear from people with disabilities. I am still addressing my own ableist thoughts and actions, despite living with my own impairment (disability) all my life. I still want to do better. More. I like being a web designer. I like taking accessibility head-on and making it a part of what I design and build. It’s not a burden or extra for me because I see it as an improvement to my craft. Web design is accessibility. Web design is usability. Web design is inclusive. The web is for everyone. For everyone.

As I say farewell, for now, my hope is that it’s not the end for you either. I’ll be back here when I have some results to share. In the meantime, I have a lot more learning and work to do. Talk to me on Twitter or LinkedIn about your own accessibility journey, learning, and successes (or fails). We’re all in this together. All of us.


I Passed!

A little over 6 weeks (mid-May) after sitting for the WAS exam (early-April), I received an e-mail congratulating me on passing the Web Accessibility Specialist certification exam, established by the International Association of Accessibility Professionals (IAAP). WOW! That truly made my day. Not only had I passed, but I did well with a score of 729 on a scale of 100-800. I was excited and reassured that I did understand web accessibility after putting in the time to study.

It was over 2 years ago that I started this journey of learning about web accessibility and exploring the POUR principles (Perceivable, Operable, Understandable, Robust) by the World Wide Web Consortium (W3C). Even back then, I had challenged myself to spend 100 consecutive days trying to glean from professionals and online documentation. Let me tell you, it was slow going then, and I felt as though I hardly got anywhere. This second 100 days was different. I had a goal and an outline to go by.

After discovering IAAP’s WAS certification and their Body of Knowledge document outlining what technicalities a web accessibility consultant should know, I was going big or going home. OK, I wasn’t going to quit if I didn’t earn their certification, but I would have doubted my own abilities and understanding. Anyhow, I convinced my employer to support my endeavor by financing my exam and allowing me to spend some work time on a weekly basis to study.

100+ days of self-directed study, working through Deque’s WAS certification courses, asking questions to experts, and practicing coding techniques and evaluation concepts truly paid off when it came to achieving my goal. Upon receiving my results, I felt like I may have over-studied for the exam, but walked away with a richer experience and knowledge-base than was expected of me. I had no regrets.

Special thanks to so many who helped me get this far:

  • IAAP for giving me a goal line and a clear pathway to get there,
  • the Alaska State Libraries, Archives, & Museums for supporting my continuing education,
  • the State of Alaska webmasters and our ADA coordinator who inspired me to find answers to all our pressing accessibility questions,
  • my friends with disabilities who humored my questions and opened up to me about barriers they encountered, which motivated me to do better,
  • my family for being supportive and understanding that this is something I needed to spend time on at home,
  • Deque University for awarding me a scholarship, enabling me to take their courses, and
  • the Twitter, Slack, and LinkedIn web a11y (accessibility) communities for answering my questions and cheering me on; there are just too many names to mention without leaving someone out!

If you’re just starting your own journey into accessibility and feel overwhelmed or confused, don’t be. There’s a whole community of people willing to help, guide, and cheer for you! And the fact is, we are all still learning because there is no real one-size-fits-all way of writing code and crafting experiences. You can do this. Stay motivated, understanding that the more you know and practice, the more you’re helping build a better web for everyone.

Learn from me, but go beyond me. Talk to experts. Talk to people with disabilities. Experiment on your own. Put what’s new to you into practice as often as you can. And, most of all, believe in yourself and the mission to enable more people to equally use the web.

I am now Amy Carney, Web Accessibility Specialist, and I am still learning, too. Web accessibility is one of my passions, so contact me if you have web accessibility questions, want to share your own story, or are looking for a presenter for your conference or meetup. In the meantime, I’ll continue to build upon my own learning and credentials by preparing for IAAP’s CPACC certification, and educating others when the opportunity arises.

A reflection on my 100 Days of A11y

One week ago I sat for IAAP’s (International Association of Accessibility Professionals) Web Accessibility Specialist (WAS) certification exam. After 200+ hours of self-guided study, spanning over 100+ days — through sickness and in health — plus 13 Deque prep courses, I met the exam head-on with optimistic yet nervous energy. Would the studying and coursework be enough to pass? Had I actually learned the core principles and technicalities that would allow me to answer confidently and feel as though I qualify as a specialist?

I can’t say for certain if I passed because it takes 4-6 weeks for me to hear back on the pass or fail result. However, I can say with certainty that all of this was not a total fail. I put in the time to learn in-depth about web accessibility principles, guidelines, and technical specifications. I took several chances to teach others about web accessibility. Additionally, I was inspired to keep advocating for accessibility and continue learning so I can create better experiences for people on the web.

Why did I do it?

This is one of the first questions people ask me after they heard about my desire to take the exam or the 100 days I committed to pursue web accessibility knowledge. To this, my reply was simply, “because I want to learn web accessibility at a greater depth than I what I know now. This exam gives me study materials and a goal post.” To add to that, I’ve learned from my two rounds of 100 Days of Code that I could learn a lot and accomplish much if I’m accountable throughout a 100-day period. That type of commitment forced me to be systematic and pushed me into forward motion.

As a matter of fact, Nicolas Steenhout interviewed me about it on his A11yRules podcast:

  1. E76 – Interview with Amy Carney – Part 1 (26 minutes)
  2. E77 – Interview with Amy Carney – Part 2 (16 minutes)

How did I do it? A timeline.

No journey is complete without some sort of pre-planning and external support. My planning began with garnering support and acquiring permission to spend time on this project with the return on investment being improved accessibility for their sites, as well as sharing the knowledge statewide. On November 28, 2018, I approached my boss about taking the WAS exam with the support of my division behind it. It didn’t take long to get his approval, as well as our director’s approval.

Based on that approval, I started Day 1 of my Web Accessibility Specialist journey on November 30, 2018 with the intention to take the exam on April 3, 2019. That plan would allow me four whole months of self-guided study, and address any bumps that may come up along the way. Every single day (except for Christmas Day), I spent 1-2 hours of my time either reading articles, watching videos, delving into documentation, or picking apart accessible code. Each of these were all discovered by using the WAS Body of Knowledge [Word doc] as my guide for topics to explore. Alongside my studying, I took time to journal (blog) each day to keep myself accountable and share with others the discoveries I’d made, hence the very existence of the 100 Days of A11y website you are pulling this article from.

On February 21, 2019, in the midst of my self-guided study, I was awarded a year’s membership to Deque University. This gave me access to all their courses, which included the thirteen courses that would prepare me for the WAS certification exam. Within a few days of enrollment, I started working through the pertinent courses with intention to work through all thirteen in order to fill in any gaps, plus act as review for what I’d already learned.

It wasn’t until February 22, 2019 when I finally finished working through the WAS Body of Knowledge. By that time I’d gotten a good handle on the Web Content Accessibility Guidelines (WCAG), discovered the Authoring Tools Accessibility Guidelines (ATAG) for the first time, and revisited the Accessible Rich Internet Applications (ARIA) specification and its recommended practices. Additionally, I had the opportunity to try out new code by creating accessible JavaScript components and create an evaluation report about a website’s accessibility.

On March 3, 2019, I began reading A Web for Everyone by Sarah Horton and Whitney Quesenbury. Though this was by my own choice and interest, rather than a recommended read from a list, it greatly benefited me at this point in my journey. The points they really brought home about the people we design for and the experiences we build were perfect timing. Each idea for inclusive design was well-received, thanks to the knowledge about WCAG and people with disabilities that I’d built up prior to entering into their text.

It was on March 10, 2019 that I completed my 100 days of self-guided study for the WAS exam. For the next 5-6 days I took a break from such a time-consuming commitment. That break period allowed me to take advantage of some sunny weather with my family before diving full-force into the Deque courses that still lay ahead.

April 2, 2019, the day before my exam, I finished the final course on Deque that I needed in order to feel more prepared for the WAS exam. It was a long course, but ever-so-necessary, since it reinforced what I needed to know about testing sites for accessibility.

At last, exam day had arrived. On April 3, 2019, I sat for the exam with my designated proctor. In under an hour, I was able to answer all 75 questions, some of which I may have missed. I walked away with much relief, mixed with a sense of affirmation that I had indeed learned something over those last four month. To me, it had all proven to be a success.

What did I take away from all this?

People are the reason

As I mentioned in one of my journal posts, the point of all of this comes down to people. Accessibility is specifically aimed at people with disabilities. Without that core understanding, the resources I tapped into would have been un-relatable and useless. The biggest thing I gained from this was the expansion of my perception. My accessibility mission starts first with understanding who is accessing the web and how they may interact with it. It’s important for me to grasp that we do not all share the same contexts, environments, and experiences. Nor do we all respond the same way to the same website.

Resources are ripe for the Googling

Over two years ago when I was digging around the Internet, trying to figure out were to start on web accessibility with only WCAG in mind, I felt so lost. I think that was partly due to the fact that I found some websites very unfriendly and uninviting. Any time I googled “WCAG” it brought me to the normative documentation or the Web Accessibility Initiative (WAI) site. Both made me leave rather quickly.

That being said, I am happy to report that several things have changed since then, and more homegrown contributions have popped up on the web. For one, the WAI website‘s recent redesign is so much more inviting to someone like myself. Additionally, I’ve found a whole community on Twitter that hashtags accessibility (#a11y). Those people led me to personal blogs or other people’s articles and online talks, including Inclusive Design 24 and A11ycasts on YouTube. Later, I was able to join a Slack group centered on dedicated topics of web accessibility. All of these things have been fabulous, informative, and inviting. I am grateful that so many conversations and open knowledge-sharing is happening online that I can partake in or at least lurk around to listen.

Web accessibility is no different than any other part of front-end development. We can’t possibly memorize every single detail. The critical part comes down to building up the right toolbox for ourselves, and bookmarking the resources that we need to consult often.

Don’t re-invent the wheel: use code examples

To fill up that toolbox, look back at the resources that I tapped into, which were also generous in offering up code examples. What’s one thing we designers and developers crave the most when learning accessibility? Code snippets! We want to see how someone else successfully made their component or pattern accessible in real life. I like to play with code and try to build things creatively myself (as do many of us), but I also draw comfort from knowing others have worked on this and found a good solution that provides an equal experience for a wider audience.

Thank you to anyone who has unabashedly shared what they’ve learned and how they made it work. Your HTML, CSS, and JavaScript are much appreciated.

Also, I should mention ARIA as being relevant to my code endeavors and improvements, since I was forced to learn much of it during my self-guided study and Deque courses. It was the kick in the pants I needed to dig deeper into it’s documentation suite and get to know it’s full use and purpose. ARIA can still feel a bit complicated, but at least I understand it so much more than I did four months ago.

Testing and evaluation are a necessary skill

Not only have people offered up their code snippets, but some dedicated individuals have also presented what they’ve found when testing on specific platforms and user agents (browsers) with various assistive technology. This is truly the step forward that I think people like myself have been missing out on.

Studying for the WAS exam really pushed me forward in this area. It’s a skill, and it’s an important one. As someone who is deeply invested in providing a good user experience (for everyone), I was lacking in full understanding of how to test the sites I was building or maintaining. The WAVE toolbar and other automated tests were just not enough. The WAS Body of Knowledge not only made clear that I needed a fuller understanding of testing tools, but also that I needed evaluation methodologies, which I was completely clueless about beforehand. Thanks to their suggested list of various testing tools and techniques and WCAG-EM, I feel a lot better equipped to scrutinize each experience I’m providing to the public. It’s become part of my own workflow in design and development now.

I can’t turn back

It’s too late for me. I’ve swallowed the red pill and now I can’t go back to living in blissful ignorance and the illusion that everyone can easily use the sites I make. No longer can I be happy with un-semantic HTML elements, poor CSS design choices, and it-works-with-my-mouse JavaScript. To make matters worse, I may be alienating myself because I can’t help but bring it up and point out current problems. My Twitter feed is a prime example of my web accessibility knowledge and opinions running over a once placid profile. If that’s too overwhelming, you could ask my co-workers about me, but you’re bound to hear the word “accessibility” in that conversation.

What exactly is a Web Accessibility Specialist, again?

The WAS Body of Knowledge says that to be considered a Web Accessibility Specialist, one must understand how to:

  1. create accessible content, using WCAG, ARIA, and ATAG,
  2. identify accessibility issues, utilizing manual and testing tools, and
  3. remediate accessibility issues by offering evaluation and reports.

But what about assumptions we make when deeming who is an expert and who is not? For instance:

  • Can she recite any WCAG success criteria by number when quizzed?
    Maybe, if she spends every day evaluating with those success criteria.
  • Does she have every ARIA pattern memorized, ready to compare on examination of another’s source code?
    It’s possible. A few people are code geniuses.
  • Are all screen reader keystrokes memorized and performed fluidly by this alleged specialist?
    Doubtful, but some native screen reader users might be apt at this.
  • Will her site evaluation and report say the same thing another specialist’s report says?
    Unlikely, but miracles do happen.

Is a certification necessary? Maybe so or maybe no. In short, I think that IAAP is on the right track. There are a lot of things to understand, know, and consider in order for someone to be valuable as an accessibility consultant. It heavily depends on the direction a person is going with this certification. Consultant work for web accessibility is very important work, and it requires someone who is serious and committed to that subject matter. Certification is just one way to show that commitment.

So, what about the rest of us who just want to be better web designers and developers? Is there value in learning all these things with or without the certification? Yes! Becoming better at those three things (creation, identification, remediation) will make you better at your craft. It already has made me better at mine.

What’s next?

Perhaps I did (or didn’t) pass the exam. When the results come back, I will be excited if I did pass, and disappointed if I did not. But all is not lost. I accomplished what I set out to do, which was to become more knowledgeable about the why and the how of web accessibility.

On that note, I want to reiterate that it doesn’t end here for me. There is still so much I haven’t explored, tests that I haven’t run myself, and fixes on personal and business sites that I haven’t corrected yet. And if that weren’t enough, I plan on sitting for the Certified Professional in Accessibility Core Competencies (CPACC) certification exam this Fall so that I can earn credential as a Certified Professional in Web Accessibility (CPWA).

In the meantime, I have a lot of work to do. Find me on Twitter, LinkedIn, or Github if you are interested in or want to talk web accessibility.

Day 100: WCAG and Motor Disabilities

Last official study day! I’ll continue to review my notes, WCAG, screen reader shortcuts, and work through Deque courses, but I will not feel obligated to post everyday after this. Summary of 100-day journey still to come.

A couple days ago, I covered WCAG and hearing impairments, so today I reviewed WCAG again to so how it benefits people with motor impairments that want to use the web.

Things I accomplished

What I reviewed

  • WCAG success criteria that benefit people with motor impairments;

What I learned from it

The following lists target WCAG success criteria that benefit people with motor impairments.

Level A

  • 1.3.2 Meaningful sequence
  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (v2.1)
  • 2.2.1 Timing adjustable
  • 2.2.2 Pause, stop, hide
  • 2.4.1 Bypass blocks
  • 2.4.3 Focus order
  • 2.5.1 Pointer gestures (v2.1)
  • 2.5.2 Pointer cancellation (v2.1)
  • 2.5.4 Motion actuation (v2.1)
  • 3.2.1 On focus
  • 3.2.2 On input

Level AA

  • 1.3.4 Orientation
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.4.5 Multiple ways
  • 2.4.7 focus visible
  • 3.3.4 Error prevention (legal, financial, data)

Level AAA

  • 2.1.3 Keyboard (no exception)
  • 2.2.3 No timing
  • 2.2.4 Interruptions
  • 2.2.5 Re-authenticating
  • 2.2.6 Timeouts (v2.1)
  • 2.5.5 Target size (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.5 Change on requesst
  • 3.3.6 Error prevention (all)

Day 99: Semantic Elements and Their Quirks

Today I worked on finishing a Deque course about semantic code. All my time got wrapped up in the fascinating aspects of which HTML is read aloud and easily navigable, and which elements are ignored by screen readers.

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • tables
    • lists
    • iframes
    • elements announced & unannounced
    • parsing & validity
  • Navigation keyboard shortcuts for screen readers;

What I learned from it

I’ve been mixing up the purpose to the caption element and the summary attribute for tables. Caption is the accessible name of the table, so it shows up in a list of tables provided by a screen reader. The summary attribute was deprecated in HTML5. Caption should be short, even when including a brief summary. Summary replacements include:

  • putting the table in a figure element, and using figcaption with table aria-labelledby to associate the table with the summary
  • adding an id to a separate paragraph and adding aria-describedby to the table element to point to that p id.

When using iframes, include a title attribute, and ensure the embedded page/content has a title element. Screen readers like JAWS vary in behavior as to which one they read. Also, as a note to myself, I need to start defining the type of content within tthe iframe title attribute, like starting the title with “Video”, so it’s clear what they are accessing.

HTML elements that we can’t rely on screen readers to read aloud, therefore, should provide additional cues for important information:

  • strong
  • em
  • q
  • code
  • pre
  • del
  • ins
  • mark

These have given me a lot to think about and stresses the importance of testing my sites on a few different screen readers and platforms.

Wrapping a code element with a pre element is appropriate, and helps the visual presentation of code blocks.

Day 98: WCAG and Hearing Impairments

Yesterday’s learning about how WCAG benefits people with visual impairments pushed me forward into more WCAG overview to see how it benefits people with hearing impairments (deaf and hard of hearing). Deafblind benefit from using the combined design techniques of visually impaired and hearing impaired.

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • links (WCAG 2.4.4, A & 2.4.9, AAA)
    • navigation between pages (WCAG 3.2.3, AA & 3.2.4, AA)
    • navigation on page
  • Navigation keyboard shortcuts for screen readers.
  • WCAG success criteria that benefit people with hearing impairments;

What I learned from it

Tips from Giles Colborne’s book Simple and Usable (as quoted in Web for Everyone:

  • simplicity is good science and good interface design
  • simple designs put complexity in its place
  • observe real people to learn what’s needed
  • designing for multiple devices supports accessibility

aria-describedby and aria-labelledby WILL access content that is inside a container hidden using aria-hidden="true".

aria-labelledby, aria-describedby, aria-label, and hidden text are some ways to let a screen reader user know of current page. Or use aria-current=”page” which has some support.

The following lists target WCAG success criteria that benefit people with visual impairments. The main concern for hard of hearing is to provide text or sign language alternatives to any sound provided.

Level A

  • 1.1.1 Non-text alternatives
  • 1.2.1 Audio-only & Video-only
  • 1.2.2 Captions (pre-recorded)
  • 1.2.3 Audio description or media alternative (pre-recorded)
  • 1.3.3 Sensory characteristics

Level AA

  • 1.2.2 Captions (live)

Level AAA

  • 1.2.6 Sign language (pre-recorded)
  • 1.2.8 Media alternatives (pre-recorded)
  • 1.2.9 Audio-only (live)

Day 97: WCAG and Visual Impairments

Yesterday’s learning about how WCAG benefits people with cognitive disabilities inspired me to look over WCAG again to see how it benefits people with visual impairments (blind and low vision).

Things I accomplished

What I reviewed today

  • Semantic structures that screen readers (and sometimes everyone):
    • page title (WCAG 2.4.2, A)
    • page and parts language (WCAG 3.1.1, A & 3.1.2, AA)
    • landmarks (WCAG 4.1.1, A)
    • headings (WCAG 1,3,1, A & 2.4.6, AA & 2.4.10, AAA)
    • links
  • Navigation keyboard shortcuts for screen readers.
  • WCAG success criteria that benefit people with visual impairments;

What I learned from it

The support among screen readers is better for the simple two-letter language codes (like “en” for English) than for the localized language codes (like “en-au” for Australian English).

Screen readers list forms only if marked as role="form" (the <form> element will be ignored in landmark lists).

The name of a link is calculated as follows (in order of precedence by screen readers):

  1. aria-labelledby
  2. aria-label
  3. Text contained between the opening <a> and closing </a> elements (including alt text on images)
  4. title attribute (note that this is considered a last resort method for screen readers to find something; it should not be considered a primary technique for giving names to links)

If headings have images, the alt text will be show up in the headings list. Linked images (whether HTML img or CSS background image) can be assigned aria-label or aria-described by. Spans can hide extra meaningful content for screen readers. All these alternatives make me wonder how that impacts people with cognitive disabilities or people who use speech recognition. It’s so important to design for more than one disability.

There are so many success criteria for this disability, compared to cognitive disabilities, but I imagine that’s because it is more objective and measurable. The following lists target WCAG success criteria that benefit people with visual impairments.

Level A

  • 1.1.1 Non-text alternatives
  • 1.2.1 Audio-only & Video-only
  • 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
  • 2.1.1 Keyboard
  • 2.1.2 No keyboard trap
  • 2.1.4 Character key shortcuts (v2.1)
  • 2.2.2 Pause, stop, hide
  • 2.4.1 Bypass blocks
  • 2.4.2 Page titled
  • 2.4.3 Focus order
  • 2.4.4 Link purpose (in context)
  • 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
  • 4.1.1 Parsing
  • 4.1.2 Name, role, value

Level AA

  • 1.2.5 Audio description (pre-recorded)
  • 1.3.5 Identify input purposes (v2.1)
  • 1.3.4 Orientation (v2.1)
  • 1.4.3 Contrast (minimum)
  • 1.4.4 Resize text
  • 1.4.5 Images of text
  • 1.4.10 Reflow (v2.1)
  • 1.4.11 Non-text contrast (v2.1)
  • 1.4.12 Text spacing (v2.1)
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.4.5 Multiple ways
  • 2.4.6 Headings and labels
  • 2.4.7 Focus visible
  • 3.1.2 Language of parts
  • 3.2.3 Consistent navigation
  • 3.2.4 Consistent identification
  • 3.3.3 Error suggestion
  • 3.3.4 Error prevention (legal, financial, data)
  • 4.1.3 Status messages (v2.1)

Level AAA

  • 1.2.7 Extended audio description
  • 1.2.8 Media alternatives (pre-recorded)
  • 1.3.5 Identify purpose (v2.1)
  • 1.4.6 Contrast (enhanced)
  • 1.4.8 Visual presentation
  • 1.4.9 Images of text (no exception)
  • 2.1.3 Keyboard (no exception)
  • 2.2.4 Interruptions
  • 2.4.8 Location
  • 2.4.9 Link purpose (link only)
  • 2.4.10 Section headings
  • 2.5.5 Target size (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.5 Change on request
  • 3.3.6 Error prevention (all)

Day 96: WCAG and Cognitive Disabilities

Even as I’m learning about design, it still comes down to me focusing more on people, their abilities, and the way they interact with the web. As usual, some learning leads to more questions, and more discoveries.

Things I accomplished

What I reviewed today

  • WCAG success criteria that benefit people with cognitive disabilities;
  • overview of ATAG, Part B (Authoring Tool Accessibility Guidelines):
    1. Fully automatic processes produce accessible content
    2. Authors are supported in producing accessible content
    3. Authors are supported in improving the accessibility of existing content
    4. Authoring tools promote and integrate their accessibility features
  • design considerations for various disability categories
  • accessibility-first mindset:
    • avoid exclusive design patterns
    • embrace diversity
    • create inclusive design

What I learned from it

The following lists target WCAG success criteria that benefit people with cognitive disabilities.

Level A

  • 2.5.1 Pointer gestures (v2.1)
  • 2.5.3 Label in Name (v2.1)
  • 2.5.4 Motion actuation (v2.1)
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions

Level AA

  • 1.3.4 Orientation (v2.1)
  • 1.3.5 Identify input purposes (v2.1)
  • 1.4.10 Reflow (v2.1)
  • 1.4.12 Text spacing (v2.1)
  • 1.4.13 Content on hover or focus (v2.1)
  • 2.5.6 Concurrent input mechanisms (v2.1)
  • 3.2.3 Consistent navigation
  • 3.2.4 Consistent identification
  • 3.3.3 Error suggestion
  • 3.3.4 Error prevention (legal, financial, data)

Level AAA

  • 1.3.6 Identify purpose (v2.1)
  • 2.2.6 Timeouts (v2.1)
  • 2.3.3 Animation from interactions (v2.1)
  • 3.1.3 Unusual words
  • 3.1.4 Abbreviations
  • 3.1.5 Reading level
  • 3.1.6 Pronunciation
  • 3.2.5 Change on request
  • 3.3.5 Help
  • 3.3.6 Error prevention (all)

Day 95: Designing an Accessible User Experience, Part 3

Today’s dedicated accessibility time was spent finishing walking through the topic of designing an accessible user experience, per continuation of Part 2.

Things I accomplished

  • Continued Deque’s “Designing an Accessible User Experience” course. 85% complete.
  • Continued reading A Web for Everyone. 8% complete.

What I reviewed today

  • Ability + Barrier = Disability;
  • Design + Accessibility = Inclusive Design;
  • UX for blind: audio-structural experience and interaction;
  • JAWS keystrokes (Insert + F3, Insert + Ctrl + R);
  • UX for deafblind: tactile-structural text-only;
  • UX for deaf: silent-visual;
  • Cognitive disabilities

What I learned from it

It’s usually best to keep the number of landmarks to a relatively short list, because part of the point of landmarks is to make it faster and easier to find things. The more landmarks there are, the less they help make things faster or easier

The most unique challenge for deafblindness is multimedia content. Solutions:

  • think text-first
  • create a simple design
  • use semantic structure
  • offer control over timing
  • use common words/phrases
  • apply screen reader techniques

WebVTT is one of the most versatile caption formats because users can set preferences like color, size, and font at system-level, which can trickle to browser-level.

WCAG 2.1 adds in some consideration for cognitive disabilities, but there is so much more to be considered, yet can’t be quantified as success criteria. Challenges to understand when considering a variety of traits under the cognitive disabilities category:

  • complex concepts
  • abstraction
  • sarcasm and satire
  • self versus others
  • problem-solving and critical thinking
  • speed
  • memory
  • attention
  • reading
  • speech and language
  • math
  • behavior
  • visual perception

Horton & Quesenbery constructed 9 design principles for incorporating accessibility into a website or application:

  1. people first: designing for differences
  2. clear purpose: well-defined goals
  3. solid structure: built to standards
  4. easy interaction: everything works
  5. helpful wayfinding: guides users
  6. clean presentation: supports meaning
  7. plain language: creates a conversation
  8. accessible media: supports all senses
  9. universal usability: creates delight

Best statement of the day

“The more you can think in terms of the semantic structure, the more successful you will be at creating a good user experience for screen reader users.”

Day 94: Designing an Accessible User Experience, Part 2

“Learning directly from users with disabilities can be one of the most valuable things you can do as a part of the design process.”

Today’s dedicated accessibility time was a continuation of Part 1 on the topic of designing an accessible user experience.

Things I accomplished

  • Continued Deque’s “Designing an Accessible User Experience” course. 67% complete.

What I reviewed today

  • A barrier is exclusion. Exclusion is the failure to meet an accessible design challenge;
  • Plan for accessibility from the beginning and throughout the project;
  • Common design failures:
    • no semantic markup
    • custom widgets without ARIA
    • custom widgets without keyboard focus management
    • poor color contrast
    • visual-only cues for form validation;
  • Test with real users;
  • Disability is a spectrum;
  • Accessible design is often inclusive;

What I learned from it

Referring to statistical probability in math, if you were to target your design at users who fall in the middle of the normal bell curve, you would meet the needs of only 68% of your users. Admittedly, designing for the edge cases requires more skill and planning than designing only for the normal user, but the return is much greater, too.

Best statements of the day

“Knowledge is power… and opportunity… and responsibility. ”

“People with disabilities are in the minority, but that doesn’t make their characteristics irrelevant to the majority.”

Related resource

Day 93: Designing an Accessible User Experience, Part 1

Now that the party is over (my presentations have been given), I’m back on track to going through WAS certification courses on Deque and reviewing information that’s pertinent to my upcoming exam in April. As of today, I’m officially one month away from taking IAAP’s Web Accessibility Specialist certification exam.

Things I accomplished

What I reviewed today

Websites that don’t follow accessibility guidelines and principles are often inaccessible, but they can still be inaccessible (unusable) if only the guidelines are followed and usability testing is not implemented.

Guidelines are a mix of objective (easily testable) and subjective (harder to test).

What I learned from it

Consideration of cognitive disabilities is most neglected when it comes to content creation and website development. Why? Measuring successful access is hard because it’s subjective.

Universal (Inclusive) Design

In 1997, a set of universal principles [PDF] was developed by architects to encourage inclusion of everyone’s needs in the design of buildings and products. Each principle has its own guidelines. The seven principles are:

  1. Equitable use: useful and marketable to people with diverse abilities;
  2. Flexibility in use: accommodates a wide range of individual preferences and abilities;
  3. Simple and intuitive use: easy to understand, regardless of user’s experience, knowledge, language skills, or current concentration level;
  4. Perceptible information: effectively communicates necessary information to the user, regardless of ambient conditions or the user’s sensory abilities;
  5. Tolerance for error: minimizes hazards and the adverse consequences of accidental or unintended actions;
  6. Low physical effort: can be used efficiently, comfortably, and with minimum fatigue;
  7. Size and space for approach and use: provides appropriate size and space for approach, reach, manipulation, and use, regardless of user’s body size, posture, or mobility;

These sound a lot like Web Content Accessibility Guidelines principles and criteria, don’t they?

After reading these, I’m reminded of why it can be so easy to confuse the terms “inclusive” and “accessibility”. Accessibility usually does benefit everyone, but is specifically focused on including a particular group of people (those with disabilities). However, inclusive design is a loftier goal that takes advantage of the fact that designing universally, or with a wider audience in mind, does benefit everyone. I, personally, need to correct myself to use each term appropriately.

An A-ha Moment

Content creators, designers, and developers (all creative people) must be open to feedback about their creation. If not, their product will always fail to be inclusive or accessible. Even people who have been mastering their craft need feedback. Otherwise, the product is just for them and no one else.

I still need to check myself and not take feedback or perceived criticism as a personal attack. Receiving another person’s perspective is actually a building block. My confidence lies in being adaptable and open to revisions for a better end-product, and mastering my craft of design. The joy of creating ultimately relies on the joy of sharing it with others. Very rarely am I a creating art for me, but rather I am hoping to design something that’s usable, beneficial, and enjoyable for other people.

Best statement of the day

“Setting a goal of making things “good enough” for compliance isn’t always good enough for real people. Push the boundaries to create experiences that people with disabilities actually enjoy, not just experiences they merely tolerate.”

The runner up quote from Deque

“Accessibility problems are the result of biased design decisions.”

From A Web for Everyone

“Instead of pretending that hidden away in a vault somewhere is a perfectly “normal” brain, to which all other brains must be compared … we need to admit that there is no standard brain…”

Day 92: A Day of Two Presentations

Whew, what an exhausting day! After presenting two different accessibility sessions at the Alaska Library Association conference today, I’m beat. The amazing part was the active engagement from participants, and the ability to still learn something from the co-presentation I was a part of.

Things I accomplished

  • Co-presented about accessible workstations in libraries, with my part focused on people with disabilities who may come into their library.
  • Presented about creating Word docs and PowerPoint slides with accessibility in mind.
  • Completed Deque’s MS Word Accessibility course.

What I reviewed today

  • U.S. law for people with disabilities
  • accessible electronic content (Word and PowerPoint)

What I learned

The Americans with Disabilities Act (ADA) was written in a such a way to benefit everyone. Whether born with a disability or acquired later in life, it’s there to serve us all.

I knew about the Word’s export to HTML feature, though I don’t like it. What I didn’t know is that there is another save for web option: Web Page, Filtered. This removes all that excess (ugly) code that forces formatting as inline styles. Styles are separated. I haven’t given it a try yet, but will give it a try later on this week.

Day 91: Accessible Word Docs

Yesterday I learned that documents like Word and PowerPoint are considered non-web documents under Section 508. However, WCAG (minus 4 success criteria) should still be applied to these files to ensure accessibility.

I’ve done several trainings, workshops, and one-on-one training sessions to educate others about digital document accessibility, but I always feel like I learn something new when I take other people’s courses and workshops. Plus, this is the perfect preparation for me to give another workshop about accessible digital documents.

Things I accomplished

  • Practiced my Accessible Digital Documents talk for tomorrow.
  • Worked through 60% of Deque’s MS Word Accessibility class.

What I reviewed today

Adding structure and semantics to Word docs to increases its accessibility and usability. Structures and semantic elements to focus on when creating a Word document:

  • headings
  • table of contents
  • language
  • headers & footers
  • floating objects
  • footnotes and endnotes
  • abbreviations and acronyms
  • columns
  • links
  • superscripts & subscripts
  • page numbers

Styles should not be used to convey important meaning. This includes using bold, italics, strike-through, and highlighting.

What I learned from it

Turns out my knowledge of Word doc accessibility was challenged a bit. I’d heard that Word documents offered specific accessibility perks compared to other formats like PDF, when used appropriately. However, Deque proved that wrong. Word docs and PDFs each present accessibility challenges to VoiceOver users. Their point being that creating online content within HTML is the most accessible, which I did know already.

I tested a .docx file on Mac by opening it up in Pages. Semantics still remained. However, testing that same file on my iPhone with Previewer, those same semantics didn’t carry over.

Something else I learned that had to overwrite old thinking was that all text formatting is not read (by default) by screen readers. I knew styling was ignored, but I didn’t know screen readers went as far as ignoring bold, italics, strike-through, and highlighting, unless otherwise changed in the user settings. The best way to draw attention to key points and important items is to literally include those words in the text. As a perk, that method can draw attention for sighted users with reading or cognitive disabilities.

On the topic of text styling, I learned that drop cap letters are read weird by screen readers. The drop cap letter is read separately from the rest of the letters of the word.

Special characters are not all understood by screen readers either. Including explanation alongside those characters increase their accessibility.

Use Text Effects, instead of Word Art, which is an object that is out of the flow of the document. This increases accessibility of pretty text for screen readers. Use caution with Text Effects, though, because it could decrease accessibility for people with low vision.

Day 90: Section 508 and the ADA

I’ve had an accessibility-heavy week! However, it’s not without it’s rewards. I’ve found that sometimes on these journeys, ideas start to synchronize, articles relevant to what I’m questioning start to emerge in my Twitter feed, and people approach me about ideas or questions they have that spur me on further. In line with a talk I’m giving this weekend and the classes I’m taking through Deque, the U.S. laws that protect the civil rights of people with disabilities kept coming into question in my mind. It’s only appropriate that I spent a little bit of time with those fundamentals today.

Things I accomplished

  • Updated my presentation slides about people with disabilities.
  • Updated my presentation slides about accessible digital documents.
  • Completed Deque’s class “Section 508: Fundamentals of the Law and Technical Standards”.

What I reviewed today

The Americans with Disabilities Act of 1990


  • Title I (workplace)
  • Title II (state and local government services)
  • Title III (public accommodation and commercial facilities)
  • Title IV (telecommunications for speech and hearing impaired)
  • Title V (federal enforcement of ADA)

[Federal] Rehabilitation Act of 1973 (amended in 1998)

  • Section 501 (federal employment)
  • Section 502 (enables role of Access Board, which defines ICT and accessibility standards)
  • Section 504 (federally-funded programs and services, including schools)
  • Section 508 (refreshed in 2018; federally-funded information and communication technology), usually enforced with 501 or 504.

What I learned from it

Federal laws were instated to protect people with disabilities, as well as present an example to state and local governments, plus private entities. Laws focus on physical and electronic access.


  • Architectural Barriers Act (ABA)
  • Americans with Disabilities Act (ADA)
  • Section 504 of the Rehabilitation Act


  • Section 508 of the Federal Rehabilitation Act
  • Americans with Disabilities Act (ADA): for state and local governments
  • Section 255 of the Telecommunications Act

The ADA is essential a blanket civil rights law that protects the equal treatment of people with disabilities. Many lawsuits are championed with the ADA.

The Section 508 refresh specifically references WCAG 2.0, Level AA:

“E205.4 under Electronic Content indicates the accessibility standards for electronic content shall conform to WCAG 2.0 Level A and AA Success Criteria and Conformance Requirements”

However, non-web documents and non-web software are not required to meet four criteria:

  • 2.4.1 Bypass Blocks
  • 2.4.5 Multiple Ways
  • 3.2.3 Consistent Navigation
  • 3.2.4 Consistent Identification

There are some ICT exceptions in Section 508. These exceptions are:

  • Legacy ICT (“Safe Harbor”; created before January 17, 2018 and compliant with previous 508 standards)
  • National Security Systems (weapons or intelligence)
  • Incidental Federal contracts
  • ICT functions located in maintenance of monitoring systems
  • Undue burden or fundamental alteration (significant difficulty or expense, or alters the fundamental nature of the ICT)
  • Best Meets (a balance between Section 508 and agency needs, if compliant ICT is not available commercially)

The only exceptions to agency official communication (as opposed to public facing) being compliant with Section 508 are any records maintained by the National Archives and Records Administration (NARA) obsolete to Federal recordkeeping statutes.

Whew! And there’s still so much to learn…