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.