![\"Filter](\"https://100daysofa11y.com/img/screen-shot-2019-02-09-at-8.56.18-am.png\")
Y'all, I PASSED!!! Officially certified by @IAAPOrg as a Web Accessibility Specialist. #100DaysOfA11y paid off. Feeling proud and accomplished. Thank you so much to those of you who encouraged me and supported my endeavor. #a11y #WebDevLife\n
— Amy Carney (@click2carney) May 18, 2019
\nA 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.
\nIt 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.
\nAfter 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.
\n100+ 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.
\nSpecial thanks to so many who helped me get this far:
\nIf 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.
\nLearn 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.
\nI 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.
\n", "date_published": "2019-06-03T17:00:00Z" },{ "id": "https://100daysofa11y.com/2019/04/10/100-days-of-a11y-doesnt-end-here-a-reflection-and-summary/", "url": "https://100daysofa11y.com/2019/04/10/100-days-of-a11y-doesnt-end-here-a-reflection-and-summary/", "title": "A reflection on my 100 Days of A11y", "content_html": "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?
\nI 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.
\nThis 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.
\nAs a matter of fact, Nicolas Steenhout interviewed me about it on his A11yRules podcast:
\nNo 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.
\nBased 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.
\nOn 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.
\nIt 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.
\nOn 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.
\nIt 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.
\nApril 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.
\nAt 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.
\nAs 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.
\nOver 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.
\nThat 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.
\nWeb 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.
\nTo 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.
\nThank 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.
\nAlso, 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.
\nNot 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.
\nStudying 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.
\nIt'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.
\nThe WAS Body of Knowledge says that to be considered a Web Accessibility Specialist, one must understand how to:
\nBut what about assumptions we make when deeming who is an expert and who is not? For instance:
\nIs 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.
\nSo, 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.
\nPerhaps 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.
\nOn 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).
\nIn 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.
\n", "date_published": "2019-04-10T17:00:00Z" },{ "id": "https://100daysofa11y.com/2019/03/10/day-100-wcag-and-motor-disabilities/", "url": "https://100daysofa11y.com/2019/03/10/day-100-wcag-and-motor-disabilities/", "title": "Day 100: WCAG and Motor Disabilities", "content_html": "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.
\nA 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.
\nThe following lists target WCAG success criteria that benefit people with motor impairments.
\nToday 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.
\nI'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:
table in a figure element, and using figcaption with table aria-labelledby to associate the table with the summaryid to a separate paragraph and adding aria-describedby to the table element to point to that p id.When using iframe, 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:
\nstrongemqcodepredelinsmarkThese have given me a lot to think about and stresses the importance of testing my sites on a few different screen readers and platforms.
\nWrapping a code element with a pre element is appropriate, and helps the visual presentation of code blocks.
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.
\nTips from Giles Colborne's book Simple and Usable (as quoted in Web for Everyone:
\naria-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.
\nYesterday'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).
\nThe 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).
\nScreen 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):
\naria-labelledbyaria-label<a> and closing </a> elements (including alt text on images)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.
\nThere 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.
\nEven 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.
\nThe following lists target WCAG success criteria that benefit people with cognitive disabilities.
\nToday's dedicated accessibility time was spent finishing walking through the topic of designing an accessible user experience, per continuation of Part 2.
\nIt'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
\nThe most unique challenge for deafblindness is multimedia content. Solutions:
\nWebVTT 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.
\nWCAG 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:
\nHorton & Quesenbery constructed 9 design principles for incorporating accessibility into a website or application:
\nThe 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.\n
Learning directly from users with disabilities can be one of the most valuable things you can do as a part of the design process.\n
Today's dedicated accessibility time was a continuation of Part 1 on the topic of designing an accessible user experience.
\nReferring 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.
\nKnowledge is power... and opportunity... and responsibility.\n
People with disabilities are in the minority, but that doesn't make their characteristics irrelevant to the majority.\n
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.
\nWebsites 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.
\nGuidelines are a mix of objective (easily testable) and subjective (harder to test).
\nConsideration 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.
\nIn 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:
\nThese sound a lot like Web Content Accessibility Guidelines principles and criteria, don't they?
\nAfter 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.
\nContent 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.
\nI 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.
\nSetting 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.\n
Accessibility problems are the result of biased design decisions.\n
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...\n
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.
\nThe 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.
\nI 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.
\n", "date_published": "2019-03-03T04:52:00Z" },{ "id": "https://100daysofa11y.com/2019/03/01/day-91-accessible-word-docs/", "url": "https://100daysofa11y.com/2019/03/01/day-91-accessible-word-docs/", "title": "Day 91: Accessible Word Docs", "content_html": "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.
\nI'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.
\nAdding structure and semantics to Word docs to increases its accessibility and usability. Structures and semantic elements to focus on when creating a Word document:
\nStyles should not be used to convey important meaning. This includes using bold, italics, strike-through, and highlighting.
\nTurns 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.
\nI 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.
\nSomething 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.
\nOn 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.
\nSpecial characters are not all understood by screen readers either. Including explanation alongside those characters increase their accessibility.
\nUse 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.
\n", "date_published": "2019-03-02T05:58:00Z" },{ "id": "https://100daysofa11y.com/2019/02/28/day-90-section-508-and-the-ada/", "url": "https://100daysofa11y.com/2019/02/28/day-90-section-508-and-the-ada/", "title": "Day 90: Section 508 and the ADA", "content_html": "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.
\nCovers:
\nFederal 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.
\nPhysical:
\nElectronic:
\nThe ADA is essential a blanket civil rights law that protects the equal treatment of people with disabilities. Many lawsuits are championed with the ADA.
\nThe Section 508 refresh specifically references WCAG 2.0, Level AA:
\n"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"
\nHowever, non-web documents and non-web software are not required to meet four criteria:
\nThere are some ICT exceptions in Section 508. These exceptions are:
\nThe 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.
\nWhew! And there's still so much to learn...
\n", "date_published": "2019-03-01T06:10:00Z" },{ "id": "https://100daysofa11y.com/2019/02/27/day-89-writing-a-real-accessibility-evaluation/", "url": "https://100daysofa11y.com/2019/02/27/day-89-writing-a-real-accessibility-evaluation/", "title": "Day 89: Writing a Real Accessibility Evaluation", "content_html": "Today I had the joy of practicing what I've been learning over the last 88 days. I've been itching to work through a formal evaluation, and this real opportunity came up.
\nFirst, I gathered the details that I'd written down. Next, I walked through the WCAG-EM Report Tool to reaffirm my findings, as well as add to them. Lastly, I composed a formal evaluation of the features that were not in conformance with WCAG 2.1, Level AA.
\nThe base outline of my evaluation:
\nThe process of evaluation can take a quite a bit of time, especially for someone who is new. I had to re-read many WCAG success criteria over again, limit my scope, and deeply think about what techniques were sufficient, advisory, or failures. Additionally, I encountered some bad practice and some not-so-optimal coding solutions, but refrained from delving into those since they are were not part of the aim of conformance. It was a true learning experience, and one I hope to refine over the next few years!
\n", "date_published": "2019-02-28T05:47:00Z" },{ "id": "https://100daysofa11y.com/2019/02/26/day-88-presentation-prep-humanizing-people-with-disabilities/", "url": "https://100daysofa11y.com/2019/02/26/day-88-presentation-prep-humanizing-people-with-disabilities/", "title": "Day 88: Presentation Prep - Humanizing People with Disabilities", "content_html": "Today I spent a lot of time preparing for a library conference talk about accessible spaces and being mindful of people with disabilities. So, rather than go into further study with Deque courses or deep-diving into accessibility laws (as originally planned), I decided to blog about the presentation I prepared for.
\nMy presentation is actually a co-presentation. Speaking alongside two other people, my part will specifically focus on the "who" of creating accessible workstations and spaces. Hopefully, the following outline will fit into a 15-minute time frame:
\nThe overall intent of my talk is to humanize disabilities. What I really enjoyed about today's preparation was the opportunity to talk with other people about their disabilities, and hear about the barriers they've encountered that made them feel disabled. The most fascinating part was that, out of the three people I interviewed, no one considered themselves disabled or having a disability. Only when they encountered a challenge or a complete roadblock did they consider themselves as having a disability.
\n", "date_published": "2019-02-27T05:22:00Z" },{ "id": "https://100daysofa11y.com/2019/02/25/day-87-guidelines-laws-and-myths/", "url": "https://100daysofa11y.com/2019/02/25/day-87-guidelines-laws-and-myths/", "title": "Day 87: Guidelines, Laws, and Myths", "content_html": "My intention today was to complete the first Deque course within the WAS certification prep program. I did do that, but not without being led to more resources that I need to read through. I've done a little research into US laws, but I need to read them again, plus read other laws mentioned in what I reviewed today. Looks like tomorrow's study session is laid out for me.
\nCompleted guidelines, laws, and myths sections of Deque's Accessibility Fundamentals.
\nPrinciples, guidelines, and authoring practices help create an accessible interaction between user and website or application. These guidelines and practices ensure that a variety of disabilities are taken into consideration.
\nI covered these more in detail on my own, which I've journalled on this site, but Deque does a decent job of getting the learner started with the basic principles and guidelines, and points them to official specifications. I'll admit, I need to go back and spend some serious review time to go over all these.
\nWeb accessibility laws usually fit into one of the following eleventyNavigation:
\nparent: "WAS"
\ntitle: "Day "
\ntags:
The Web Accessibility Initiative (WAI) has a comprehensive list of international accessibility policies. Additionally, PowerMapper has a list of government accessibility standards.
\nInaccessible web sites are not just inconvenient for people with disabilities, they are blocking.\n
A continuation of Part 1 as I work through the Deque courses and review who I am doing this work for.
\nDisabilities that I reviewed today through the Deque course:
\nHow they may interact:
\nDeveloper considerations:
\nReview Day 55: Users with Auditory Disabilities.
\nHow they may interact:
\nDeveloper considerations:
\nMotor disabilities includes a wide spectrum of varying degrees and characteristics of physical experiences, challenges, and strategies. Specific disabilities include: cerebral palsy, ALS, quadriplegia, or missing limbs. Review Day 54: Users with Motoric Disabilities.
\nHow they may interact:
\nDeveloper considerations:
\nThe causes of speech disabilities range from learning, motor, or auditory disabilities, autism, brain injury, stroke, cancer. They may or may not have full use of their voice and how they use that voice. Some issues can be categorized as stuttering, cluttering, apraxia, dysarthria, speech sound disorders, or non-vocal.
\nHow they may interact:
\nDeveloper considerations:
\nCognitive disabilities cannot be easily defined due to its wide spectrum. Some characteristics may include: limited comprehension, low tolerance for cognitive overload, limited problem-solving skills, short-term memory loss, attention deficit, difficulty reading, and difficulty understanding math. Review Day 53: Users with Cognitive Disabilities. It is the most common disability, due to its wide spectrum.
\nHow they may interact:
\nDeveloper considerations:
\nThis could be caused by a cognitive disability or an another underlying reason. Review Day 52: Users with Reading Difficulties.
\nHow they may interact:
\nDeveloper considerations:
\nHow they may interact:
\nDeveloper considerations:
\nA person deals with two or more disabilities.
\nHow they may interact:
\nDeveloper considerations:
\n...if you don’t understand the challenges that people with disabilities face when using ICT products and services, you don’t _really_ know accessibility. Knowing what challenges people face is central to knowing how to reduce or eliminate challenges.\n
— Karl Groves, What does it take to call yourself an accessibility expert?
\nThat about sums it up for me after working through the WAS Body of Knowledge. The only way one can evaluate websites well is to remember who could be using our sites and how their engagement and experience may differ from our own. That's basic UX (user experience) design, but with a focus on users with disabilities, which still encompasses a wide range of people and engagement strategies.
\nI'm trying to bring my focus back to the "who" part of my training. Without keeping them in the front of my mind, I will not be able to properly advocate for accessibility. Deque's course highlights the following disabilities:
\nToday I read through their explanations about various visual impairments. I found it helpful to revisit things I learned about in the past about users with low vision and identifying issues for keyboard users.
\nHow they may interact:
\nDeveloper considerations:
\nLow vision is a spectrum. It varies in degrees and characteristics.
\nHow they may interact:
\nDeveloper considerations:
\nThis is not an either-or characteristic either. Degrees of color identification vary from person to person.
\nHow they may interact:
\nDeveloper considerations:
\nEighty-four (84) days in, and I made it to the end of the WAS Body of Knowledge (BOK)! I'm ready to go back through all my blog posts (journaling) to review things that I'm so nervous about forgetting by April. This will include pouring over the W3C's Web A11y Evaluation Background Reading materials. I'll also spend the last few weeks of these 100 days to work through the Deque courses that apply to this certification, and tie together ideas that will help me be a better Web Accessibility Specialist (WAS) in practice.
\nToday's study session felt less productive, due to the topic implying review and application of all the things learned to be a WAS. However, the day did not go by without some positive steps toward taking the exam.
\nA specialist or expert in web accessibility should have a solid understanding of:
\nAdditionally, I think this person needs to bolster their project management and communication skills. Not only will they know what they're talking about, but help educate and encourage the people they are helping with evaluation and remediation. A teacher and project manager, of sorts. Accessibility Pro Certified: To Be or Not To Be is a wonderful article that takes into consideration the idea of certification and what makes an accessibility pro or expert.
\nIn order to recommend remediation strategies, a specialist has to understand:
\nThis last study topic section in the BOK made me reflect back on all the considerations that go into prioritizing remediation, which often comes down to a balance of user and business impact. It circles back nicely to the start of the BOK, where I need to fully understand what accessible content is and how inaccessible content impacts users with disabilities.
\n", "date_published": "2019-02-23T03:13:00Z" },{ "id": "https://100daysofa11y.com/2019/02/21/day-83-prioritizing-remediation-of-a11y-issues/", "url": "https://100daysofa11y.com/2019/02/21/day-83-prioritizing-remediation-of-a11y-issues/", "title": "Day 83: Prioritizing Remediation of A11y Issues", "content_html": "During today's study session, I walked away with a lot of new-to-me information and useful steps to apply to my current work.
\nWhen starting an accessibility remediation project, start with a site's core functionalities. Determine the issue's origin (markup, style, functionality), then prioritize accessibility issues by severity of:
\nWCAG conformance levels and success criteria are not the way to determine priority of remediation.
\nAs mentioned in my notes about manual versus automated testing tools, it's always best to target low-hanging fruit to begin quickly resolving issues.
\nWhen receiving an audit to proceed to remediation, people want to know:
\nRemediation is a hard lesson to learn in realizing that if things are made accessible from the start, less time and money is wasted.
\nTime is money. Just because you save time taking down inaccessible materials, time is added (technical debt shifted) to help desk lines or other resources.
\nI really liked Michigan State University's accessibility severity scale:
\nRemediation procedure levels by Karl Groves:
\nAccessibility does not happen by accident. It has to be purposefully planned, built, and tested for accessibility.\n
Today's study session led me back to usability testing. This seems to be critical when it comes to adding it to our testing toolbox to check for usability and accessibility issues that escape conformance checks, alongside automated and manual testing tools.
\nPersonally, this is one of the areas I struggle with implementing. I love reading about usability testing and case studies that people document, but I've not yet taken the opportunity to try doing this myself. Usually because it has it's own added cost, as well as awkwardness to set up testing with a specific group of people. Maybe this will be my motivator to make some connections and start a plan to make this happen this year.
\nRead:
\nThe guidelines are not all-inclusive. Some good accessibility techniques may not be in WCAG because:
\nBefore bringing in users for testing, do some preliminary checks and fix known issues in order to better discover underlying accessibility and usability challenges that were not detectable by software or manual checks.
\nIncluding users in testing doesn't have to be a full-blown usability study. Informal evaluations and brief interactions with feedback can be very helpful. Additionally, informal evaluations can happen throughout the product's lifecycle, rather than formal usability studies that usually occur near the end of development. Bonus: informal interactions can help us all see the person clearer rather than a case study.
\nNever assume that feedback from one person with a disability speaks for all people with disabilities. A small-scale evaluation (only a few people within a study) is not enough to draw solid conclusions with statistical significance, even though valuable insight occurs. Try to include a variety of disabilities: auditory, cognitive, neurological, physical, speech, and visual with different characteristics. If possible, include older people, as well.
\nToday I went into my study time with the intent to list out pros and cons of automated versus manual accessibility testing. Instead I walked away with a comparison of what each had to offer, and understanding that both are valuable when used cooperatively during website and web app development.
\nSubmitted my request to take the Web Accessibility Specialist certification exam in early April via private proctor.
\nRead:
\nCreated a comparison table to jot down ideas about manual and automated testing (see under What I learned today).
\n| Manual Testing | \nAutomated Testing | \n
|---|---|
| Slower process | \nFaster process | \n
| Mostly accurate | \nSometimes accurate | \n
| Easier to miss a link | \nGuaranteed check of all links | \n
| Identifies proper state of elements | \nAutomated user input can miss state | \n
| Page by Page | \nSite-wide | \n
| Assurance of conformance | \nMisleading in assurance of conformance | \n
| Guidance for alternative solutions | \nYes/No (boolean) checks and solutions | \n
| Human and software | \nSoftware | \n
| Context | \nPatterns | \n
| Finds actual problems | \nLists potential problems | \n
| Appropriate HTML semantics | \nHTML validation | \n
| Accurate alt text | \nExistence of alt attribute | \n
| Heading hierarchy | \nHeadings exist | \n
| Follows intention of usability | \nFollows WCAG success criteria | \n
| Test is/isn't readable | \nProgrammatic color contrast | \n
| Exploratory | \nAutomated | \n
| Part of the testing process | \nPart of the testing process | \n
| Appropriate use of ARIA | \nPresence and validity of ARIA | \n
| In real life | \nHypothetical | \n
| Identifies granular challenges of usability | \nQuickly identifies low-hanging fruit and repeated offenders | \n
Deciding on testing methods and tools shouldn't be an either-or mandate. Each has their strengths and weaknesses. Using both methods should be a part of every testing process. Why not strengthen your product's usability by incorporating tools from each methodology into your process?
\n", "date_published": "2019-02-20T04:51:00Z" },{ "id": "https://100daysofa11y.com/2019/02/18/day-80-manual-a11y-testing-tools/", "url": "https://100daysofa11y.com/2019/02/18/day-80-manual-a11y-testing-tools/", "title": "Day 80: Manual A11y Testing Tools", "content_html": "Yesterday I browsed through automated accessibility testing tools. Today, per their mention in the WAS Body of Knowledge, I discovered some manual accessibility testing tools that offer more insight into problems that can't be caught in automated reports. These tools go beyond the easy checks, like color contrast, headings, and keyboard access, that I'm used to checking for.
\nTomorrow I hope to dig in a bit deeper to compare the difference between automated and manual testing, along with the drawbacks of each.
\nManual testing tools, much like automated testing tools, offer reports and automated tests for all audiences within the development process to get a start on addressing accessibility issues. The advantage that manual tooling provides is that it offers additional guidance and education to fix problems that cannot be systematically evaluated through automated checkpoints. However, no tooling replaces human judgement and end-user testing.
\nManual testing tools can include:
\nAnother observation about manual testing tools, they may take more time to work through results, but there are many more of these tools that are free to use compared to automated full website testing.
\nThough I found that many manual testing tools seem to fall with between the development and testing, there are some system-wide tools that help earlier on in the life cycle. Color Oracle is one such application that can assist designers during the earlier design process before any code is written. It takes colorblindness into consideration at the beginning of the site's life cycle.
\nRan across an accessibility basics article by Microsoft, and loved this catchphrase:
\nAccessibility is a built-in, not a bolt on.\n
Moving onto another section in the WAS Body of Knowledge, quickly approaching the end. I'm postponing going over the "Test for End-user Impact" section in order to work through the "accessibility testing tools" section. The summary says it all for me:
\nNo accessibility software tool can find all the accessibility issues on a web site, but software tools can expedite the process of finding accessibility issues, and increase the overall accuracy when supplemented by a skilled manual evaluation of the same content.\n
Or, as the Web Accessibility Initiative (WAI) sums it up:
\nWe cannot check all accessibility aspects automatically. Human judgement is required. Sometimes evaluation tools can produce false or misleading results. Web accessibility evaluation tools can not _determine_ accessibility, they can only _assist_ in doing so.\n
I hadn't considered this before, but not all tools are meant to target one audience (developers). Each tool is created with a specific audience in mind, whether it be:
\nThere are SO many options. How intimidating for anyone trying to decide what software, plug-in, or consultant to use!
\nAutomated testing involves different considerations based on audience, need, conformance standard and level, site complexity, and accessibility experience. Various types of automated testing include:
\nIt strikes me that using a combination of tools with differing purposes could help speed up the process and ensure accuracy even more. By no means, would they replace manual checks and end-user testing, but it's incentive to not pick just one tool to do a job meant for several tools.
\n", "date_published": "2019-02-18T06:22:00Z" },{ "id": "https://100daysofa11y.com/2019/02/16/day-78-learning-about-orca/", "url": "https://100daysofa11y.com/2019/02/16/day-78-learning-about-orca/", "title": "Day 78: Learning about Orca", "content_html": "Orca is an open source screen reader for Linux. This is my first time to read about it. Hopefully, I'll have a chance to actually experiment using it. However, I'll need to set up a Linux distribution that works with it first.
\nNot only did I learn about Orca, but I also got sucked down the Linux rabbit hole in order to better grasp that OS, its distributions and desktop environments, and additional "universal access" for people with disabilities. However, that topic could take another week to work through.
\n", "date_published": "2019-02-17T06:23:00Z" },{ "id": "https://100daysofa11y.com/2019/02/15/day-77-experimenting-with-window-eyes/", "url": "https://100daysofa11y.com/2019/02/15/day-77-experimenting-with-window-eyes/", "title": "Day 77: Experimenting with Window-Eyes", "content_html": "Window-Eyes is a screen reader that appears to have fallen out of the mainstream use. According to WebAIM's latest Screen Reader Survey, 1.5% of their respondents reported that they use Window-Eyes. I experimented with it because it was listed as an example of an assistive technology to experiment and test out.
\nContinued work from Screen Reader Keystroke Comparisons, Part 1. Tomorrow I hope to dive into one of the other screen readers that I'm less familiar with (either Windows Eyes or Orca).
\nSporadically, I've used some of my study time to test out using assistive technologies (AT) like screen readers, speech recognition, and high contrast mode. I'm circling back to AT because I've hit the section in the WAS Body of Knowledge that stresses testing with AT in order to better understand how people who use AT may experience your website. This will be a fun week for me because I enjoy trying out AT and broadening my perspective to how users encounter webpages.
\nToday I spent time with the Understandable Level AAA criteria. Some of the Readable Guideline's success criteria (SC) seem like a nice effort to make for everyone who comes to your site. However, I can see how that can take a lot more communication between content creator and developer to provide the necessary additional content or appropriate code to implement sufficient techniques correctly.
\nThere are 7 Level AAA criteria under Understandable, none of which are new to 2.1:
\nThere are 0 Level AAA criteria under Robust.
\nSC 3.1.3 Unusual words Fail: Specialized words are used in the content, but no definitions are provided. Providing definitions or a glossary would greatly benefit people with cognitive, language, and learning disabilities.
\nSC 3.1.4 Abbreviations Fail: Abbreviations are present, but no expanded form is available on the page, in assumption that the user already knows what it means. This can create confusion for people with cognitive issues or those using a screen magnifier (which challenges contextual cues).
\nSC 3.1.5 Reading level Fail: No summary or additional visuals are provided for reading level below 8th grade. This may inhibit people with reading disabilities or English as a second language from understanding your content.
\nSC 3.1.6 Pronunciation Fail: No audio or text pronunciation is provided for difficult words. This hinders people who use screen readers and people with reading disabilities from fully understanding the content provided.
\nSC 3.2.5 Change on request Fail: A new window opens when the user clicks on a link without the user expecting the change of focus to a new window. Related to SC 3.2.1 and SC 3.2.2. This greatly affects people who use screen readers.
\nSC 3.3.5 Help Fail: A form supplies no detailed instructions about data format or additional information necessary to submit the form. Leaving out required information and helpful tips can hinder people with visual, cognitive, or motor disabilities form submitting the form correctly.
\nSC 3.3.6 Error prevention (all) Fail: A form that is not a legal, financial, or data transaction fails to provide a reversible, review, or confirmation step when error is possible. Related to SC 3.3.4. This may affect people with reading or motor disabilities.
\n", "date_published": "2019-02-12T23:09:00Z" },{ "id": "https://100daysofa11y.com/2019/02/11/day-73-striving-for-wcag-level-aaa-part-2/", "url": "https://100daysofa11y.com/2019/02/11/day-73-striving-for-wcag-level-aaa-part-2/", "title": "Day 73: Striving for WCAG Level AAA, Part 2", "content_html": "Carrying on from Part 1, today I spent time with the Operable Level AAA criteria. There are a few, I feel, that should be on a lower conformance level, as well as best practice for web designers.
\nThere are 12 Level AAA criteria under Operable:
\nSC 2.1.3 Keyboard (no exception) Fail: Div element has been scripted to be clickable, but is not identified as a link to assistive technology. This makes custom page navigation more difficult for people who use screen readers or voice input.
\nSC 2.2.3 No timing Fail: Web app forces a time limit on the user. This can make use of the web app harder for people with cognitive or motor impairments.
\nSC 2.2.4 Interruptions Fail: User is not given an option to delay or request non-emergency updates. Interruptions can be disorienting for a person who uses a screen reader when their cursor focus is forced elsewhere.
\nSC 2.2.5 Re-authenticating Fail: Form data is not saved when the user is timed out of a session. This can be frustrating for people who have motor or cognitive impairments.
\nSC 2.2.6 Timeouts (new in 2.1) Fail: Users are not explicitly warned about data loss due to inactivity time limits.
\nSC 2.3.2 Three flashes Fail: A video on the page contains three or more flashes in a 1-second period. This can greatly affect people who are prone to seizures.
\nSC 2.3.3 Animation from interactions (new in 2.1) Fail: Decorative animation that occurs when a user interacts with an element does not have a "reduce motion" option for users to turn it off. Animation can cause nausea for people with vestibular disorders and distraction for people with attention disorders.
\nSide note: This concept introduced me to the Reduced Motion media query. Before today, I didn't know that existed!
\nSC 2.4.8 Location Fail: Users page location within that website is not evident. Breadcrumbs, sitemap, nor highlighted navigation bar has not been provided. This affects people with attention disabilities (as well as everyone else).
\nMy two-cents: This seems like it should be good practice and common courtesy to help everyone find their way around your site. I had no idea it was Level AAA and have considered using breadcrumbs as part of business as usual when I build more pages for large sites.
\nSC 2.4.9 Link purpose (link only) Fail: Generic and unclear text is provided within hyperlinks. This can be confusing for people who use screen readers and voice input, as well as those with cognitive disabilities.
\nSC 2.4.10 Section headings Fail: Text-heavy content and instructions are provided on a page without any additional headings to segment sections of text for clarity. This greatly affects people with visual and cognitive disabilities.
\nConfession: This is a bit of a pet peeve of mine, and I often feel this should be part of best practice for web designers. It especially irritates me when I see lists nested within lists, but not headings are provided to chunk and clarify content areas that are text-rich. Please make your page more navigable for everyone by including section headings.
\nSC 2.5.5 Target size (new in 2.1) Fail: Interactive buttons and customized links are less than 44x44 pixels. This can make it especially hard for people with motor disabilities to activate the button or link.
\nAdded note: this is already making its way into mobile web app best practice, which is where I was first introduced to this concept. I'm happy to see it considered as an accessibility issue, too.
\nSC 2.5.6 Concurrent input (new in 2.1) mechanisms Fail: Interactive components on a page restrict input from other input devices other than touch. Therefore, this restricts who uses that page because people of all abilities use their input device (or devices) of choice.
\n", "date_published": "2019-02-12T01:10:00Z" },{ "id": "https://100daysofa11y.com/2019/02/10/day-72-striving-for-wcag-level-aaa-part-1/", "url": "https://100daysofa11y.com/2019/02/10/day-72-striving-for-wcag-level-aaa-part-1/", "title": "Day 72: Striving for WCAG Level AAA, Part 1", "content_html": "Originally, I thought I was going to do Level AAA conformance in one sitting. Turns out there were 28 additional criteria! To better digest the techniques and failures associated with these criteria, I had to break that reading up into three study sessions, given I spend approximately 1.5 hours a day studying. Not to mention, I find myself falling down a documentation rabbit hole to learn more about points I'm extremely curious about.
\nThere are 9 Level AAA criteria under Perceivable:
\nSC 1.2.6 Sign language (prerecorded) Fail: Sign language is not provided along with a prerecorded video. This SC benefits deaf who rely on American Sign Language as their first language.
\nSC 1.2.7 Extended audio (prerecorded) Fail: Movie moves to quickly to accommodate synchronized audio description. Video needs to be extended for substantial audio description. This SC enables blind and visually impaired to better understand what the movie is conveying.
\nSC 1.2.8 Media alternative (prerecorded) Fail: Full text transcripts of equal experience for a prerecorded video are not provided This SC benefits people who have a combination of visual and auditory impairments.
\nConfession: I often confuse captions and transcripts. They are not the same and do not provide the same access to everyone. Ultimately, captions are the bare minimum. Transcripts are more inclusive.
\nSC 1.2.9 Audio-only (live) Fail: No text alternative, like live captioning, was offered during a live audio performance. This would benefit people with auditory
\nSC 1.3.6 Identify purpose Fail: Landmarks are not identified across the page. This inhibits the adaptability of the page to meet the needs of those with cognitive disabilities. Related to SC 4.2.1.
\nSC 1.4.6 Contrast (enhanced) Fail: Contrast of foreground text/images over background does not meet the 7:1 ratio. This enhanced criterion makes it easier for people with low vision or colorblindness to perceive content. Related to SC 1.4.3.
\nSC 1.4.7 Low or no background audio Fail: An audio track that is embedded on the page that contains a speech with background music doesn't offer the user the ability to turn off the background music. This criterion is meant to enhance the distinguishability of that speech for people who are hard of hearing.
\nSC 1.4.8 Visual presentation Fail: Paragraph text is justified. This presents reading challenges to those with reading, cognitive, or visual disabilities.
\nConfession: I strongly feel that SC 1.4.8 could easily be pushed into Level AA, so more people would strive for better visual presentation for all users, since it strikes me as just good practice and even common courtesy for everyone. I mean, who doesn't benefit from left-aligned text, greater line spacing, shorter paragraph width, a choice or foreground/background colors, and elimination of horizontal scrolling of text??
\nSC 1.4.9 Images of text (no exception) Fail: Images of text (not including the brand logo) are present throughout the site. People who zoom or magnify their screen would benefit greatly from the elimination of all images with text. Related to SC 1.4.5.
\nToday I learned that there are over 120 HTML elements from 4.01 on up to 5.2. Then there are all those attributes to go along with them. This huge inventory just confirms to me that more developers should spend more time with the "basics" of HTML. Some parts of Level AAA could be more achievable (i.e. SC 1.3.6) if people spent more time understanding the building blocks, along with CSS, rather than focusing on the "perfection" of JavaScript and other programming languages to get the front-end job done.
\n", "date_published": "2019-02-11T04:41:00Z" },{ "id": "https://100daysofa11y.com/2019/02/09/day-71-how-to-achieve-wcag-level-aa-part-2/", "url": "https://100daysofa11y.com/2019/02/09/day-71-how-to-achieve-wcag-level-aa-part-2/", "title": "Day 71: How to Fail WCAG Level AA, Part 2", "content_html": "Continuing on from Part 1 with how to pass or fail WCAG Level AA...
\nThere are only 3 additional operable success criteria:
\nThere are only 5 additional understandable success criteria:
\nThere is only 1 additional robust success criterion, which was added in 2.1:
\nSC 2.4.5 Multiple ways Fail: Not enough options to explore the website for people who have visual or cognitive disabilities. Provide alternative ways to navigate via search, sitemap, or table of contents.
\nSC 2.4.6 Headings and labels Fail: No section titles have been provided for a text/content-heavy page. This eases navigation for people with visual, motor, and cognitive impairments (and everyone else).
\nSC 2.4.7 Focus visible Fail: Focus outline was removed for input controls. This impacts keyboard-only users who need to see their navigation points throughout the page.
\nSC 3.1.2 Language of Parts Fail: Paragraph and span elements do not contain a lang attribute when a change of language is obviously present. This impacts understanding for anyone, but especially impacts screen reader users and browsers that need explicit identification of document and parts of text language. Related to SC 3.1.1.
\nSC 3.2.3 Consistent navigation Fail: Global navigation links are not consistent in presentation and order across the website. This can be confusing for anyone, but especially impacts people with cognitive impairments.
\nSC 3.2.4 Consistent identification Fail: Components with the same function are not consistently labelled across the website, which impairs recognition of similar tasks and functionality. Related to SC 1.1.1 and SC 4.1.2. This can affect people with visual or cognitive impairments.
\nSC 3.3.3 Error suggestion Fail: No description of required input error is provided client-side nor server-side. Related to SC 3.3.1 and SC 3.3.2. This can affect people with visual or cognitive impairments.
\nSC 3.3.4 Error prevention (legal, financial, data) Fail: During an online data transaction, the user is not given an opportunity to review, correct, or reverse the form data being submitted. Especially on multi-step forms that requires a few pages, this can affect people with cognitive disabilities.
\nSC 4.1.3 Status messages (new to 2.1) Fail: A role="status" was not assigned to a search update that returned x-amount of results. Role needs to be assigned to the status update of how many results found. This can greatly impact visually impaired who use screen readers.
\nLast night (in bed, of course), I was thinking about how the WCAG Quick Reference could use some filtering options, like tags, in order to quicken my information discovery. Well, someone was already thinking of this! They have many filters, including WCAG version, tags, conformance levels, techniques, and technologies, set up to help people find what they're looking for:
\n
I should have explored this option earlier in my week!
\n9 more success criteria across three principles is not too much more to ask of designers and developers. To reinforce that idea, I don't find these nine criteria especially hard to implement.
\n", "date_published": "2019-02-10T02:17:00Z" },{ "id": "https://100daysofa11y.com/2019/02/08/day-70-how-to-fail-wcag-level-aa-part-1/", "url": "https://100daysofa11y.com/2019/02/08/day-70-how-to-fail-wcag-level-aa-part-1/", "title": "Day 70: How to Fail WCAG Level AA, Part 1", "content_html": "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.
\nWithin the Perceivable principle, there are 11 additional success criteria to meet Level AA conformance within the latest WCAG recommendation (2.1).
\n5 SC within WCAG 2.0:
\n6 more SC added in WCAG 2.1:
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nI 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.
\n", "date_published": "2019-02-09T04:51:00Z" },{ "id": "https://100daysofa11y.com/2019/02/07/day-69-how-to-fail-the-bare-minimum-of-understandable-and-robust/", "url": "https://100daysofa11y.com/2019/02/07/day-69-how-to-fail-the-bare-minimum-of-understandable-and-robust/", "title": "Day 69: How to Fail the Bare Minimum of Understandable and Robust", "content_html": "Today I'm concluding Level A conformance evaluation, looking at the Understandable and Robust principles of WCAG.
\nThere 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:
\nThere 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:
\nWhen 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 3.3.1 Fail: No descriptive error text was provided for required fields to help user know why their form was unable to submit.
\nSC 3.3.2 Fail: No label was associated with an input control by using 'for' and 'id'.
\nSC 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.
\nSC 4.1.2 Fail: No role, name, or state were provided on a custom component control with a div or span.
\nThough 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...
\nTomorrow 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!
\n", "date_published": "2019-02-08T00:34:00Z" },{ "id": "https://100daysofa11y.com/2019/02/06/day-68-how-to-fail-the-bare-minimum-of-wcag-operable/", "url": "https://100daysofa11y.com/2019/02/06/day-68-how-to-fail-the-bare-minimum-of-wcag-operable/", "title": "Day 68: How to Fail the Bare Minimum of WCAG Operable", "content_html": "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.
\nThere 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:
\nWhen 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nThis 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.
\n", "date_published": "2019-02-07T05:26:00Z" },{ "id": "https://100daysofa11y.com/2019/02/05/day-67-how-to-fail-the-bare-minimum-of-wcag-perceivable/", "url": "https://100daysofa11y.com/2019/02/05/day-67-how-to-fail-the-bare-minimum-of-wcag-perceivable/", "title": "Day 67: How to Fail the Bare Minimum of WCAG Perceivable", "content_html": "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.
\nToday 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.
\nThere 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:
\nWhen these nine perceivable success criteria are met, it enables people with visual impairments and hearing impairments to enjoy your content and interactive components.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nSC 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.
\nI'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.
\n", "date_published": "2019-02-06T05:55:00Z" },{ "id": "https://100daysofa11y.com/2019/02/04/day-66-circling-back-to-wcag-and-other-standards/", "url": "https://100daysofa11y.com/2019/02/04/day-66-circling-back-to-wcag-and-other-standards/", "title": "Day 66: Circling Back to WCAG and Other Standards", "content_html": "Getting myself organized this week to continue studying is proving a bit challenging. The next section I've segued into within the WAS Body of Knowledge (BOK) is Section II list item B: Determine conformance to accessibility specifications based on accessibility issues found.
\nSuggested study topics within that section include:
\nIt took me a lot of re-reading this section several times to finally decide how to proceed, what I needed to focus on, and divide up each day of this week.
\nThe first thing that confused me when I first read this part of the BOK was the mention of pointing out accessibility failures, but don't point all of them out. What?! A failure is a failure, and something that's inaccessible is inaccessible, right? What finally dawned on me was that I was thinking just in terms of WCAG, especially since WCAG was used as examples throughout. This section is really saying,
\nAfter 66 days of focusing on web accessibility, I've found that I'm retaining things better than I hoped, understanding concepts more deeply, and can quickly research something now that I have so many resources and correct terminology at hand. The biggest transition that is happening in my brain is the change of focus from technicalities (code and standards) to a focus on the people using our sites and the challenges they face. The standards are still important to me, but they are more of a means to achieve my goal of enabling people with disabilities to surf the web just like everyone else. Technicalities worked as a good starting point. However, starting with understanding (empathizing with) people and the barriers they face would seem to be an even better place to start, so that the technicalities come easier.
\nThis image comes to mind when expressing Tim Berners-Lee's dream to build an open web that's for everyone:
\n![\"Lights](\"https://100daysofa11y.com/img/sir-tim-berners-lee-londo-007.jpg\")
All that being said, this week I'm going to enjoy putting the puzzle pieces together when it comes to mapping failures with standards, all the while, reinforcing the reasons behind those standards (the people!).
\n", "date_published": "2019-02-05T01:49:00Z" },{ "id": "https://100daysofa11y.com/2019/02/03/day-65-identifying-a11y-issues-for-switch-control-users/", "url": "https://100daysofa11y.com/2019/02/03/day-65-identifying-a11y-issues-for-switch-control-users/", "title": "Day 65: Identifying A11y Issues for Switch Control Users", "content_html": "About a week ago I learned more about users with motoric disabilities, which is usually who I think of when it comes to switch device use. Today I wanted to focus more on what challenges switch device users may encounter when using websites. My study time ended up turning into review of some things I'd already learned, as well as discovering some new articles and videos about switch access.
\nI was not able to do any testing myself, since I don't have any switch devices. On another day, when I'm feeling more adventurous, I'll dedicate a study session to testing with a Bluetooth keyboard or Android device buttons to simulate the experience.
\nApple's Switch Control feature is built over the VoiceOver platform, so that's how it knows to recognize things like buttons. Point mode allows access to otherwise inaccessible apps by scanning horizontally and vertically (x, y coordinates) to create clickable point. It also gives an alternative for quicker access to focuable elements on a web page, rather than waiting for a page to be parsed and scanned piece by piece.
\nAfter learning more about switches and switch control, I can better understand the many switch control settings on my iPhone.
\nI usually think of switches being used by people with motor disabilities, but there are other people who use it, too. Some people with intellectual or learning disabilities may use a switch because a mouse, keyboard, or game controller is just too complex to use.
\nSwitch access includes devices that can receive input from almost any body part. Actions may include, but are not limited to:
\nWindows 10 has eye control as a method of switch access. Apple doesn't have this feature... yet.
\nAndroid mobile devices have switch access much like Apple's feature.
\nRestating from my article mentioned at the beginning, designers and developers need to review WCAG's operable principle for switch control accessibility. It can't be emphasized enough that if your website is following those guidelines and success criteria, your website will be accessible to switch users and many other users.
\nWhat front-end developers can do for switch control users:
\nWhile working through my study session a few days ago about identifying a11y issues for people who use voice input to navigate the web, I ran across an interesting tweet thread started by Rob Dodson:
\nA11y experts, I have a voice access question: If you have a link with the text "learn more" but you put an aria-label on it so it says "learn more about shopping" are you still able to click the link by saying "click learn more"?
— Rob Dodson (@rob_dodson) February 1, 2019
\nSo funny that this stuck out on my feed last night as I was finishing up my blog post! Admittedly, it sparked my curiosity about how ARIA affects voice dictation users, and spurred me on further to start testing with the different platforms that are available to people who need full voice navigation.
\nDisclaimer: I am not a voice input software user. This is VERY new to me, so lean very lightly on my "experience" and what I'm learning.
\nLearning curve and first-use exposure aside, Apple's Dictation feature didn't seem to have enough reach or intuition to do the multitasking I wanted to do. Additionally, I found that I had to keep reactivating it ("Computer...") to give commands. There was no continuity. Apparently, I'm not the only one disappointed with the lack of robustness Dictation + Siri has to offer. Read another person's feelings in Nuance Has Abandoned Mac Speech Recognition. Will Apple Fill the Void?
\nHere is Apple's dictation commands dialog that I had off to the side of my screen as I worked with it enabled:
\n![\"Apple](\"https://100daysofa11y.com/img/screen-shot-2019-02-01-at-5.59.28-am.png\")
The number system to access links appears to be universal across dictation software. I found it in Dictation and Speech Recognition. And I know Dragon has it, too.
\nWindows Speech Recognition was just as awkward for me. However, I felt it was built more to include navigating my computer, and not solely dictation of documents. Microsoft has a handy Speech Recognition cheatsheet.
\nHere is the Windows Speech Recognition dock, that reminds me of what I've seen online with Dragon software:
\n![\"Speech](\"https://100daysofa11y.com/img/qm54xyxudt.png\")
I found myself struggling to not use my keyboard or mouse. If I had to rely on either of these OS built-in technologies, I think I'd definitely invest in something more robust. Eventually, I want to get a hold of Dragon NaturallySpeaking to give that a try for comparison.
\nFor people who can use the keyboard along with their speech input, there are keyboard shortcuts to turn listening on and off:
\nBy far, this was the hardest thing for me to test with. I think that's due to the AI relationship with me and my computer. It was nothing like quickly turning on another piece of software and diving right in. Instead, it required that it understand me clearly, which didn't happen often. Ultimately, it will take some time for me to get comfortable with testing my web pages with speech recognition software. Until then, I'll be heavily leaning on other testing methods as well as good code and design practices.
\nAs a final note, based on the above statement, I think purchasing more robust speech recognition software, like Dragon, would be a harder sell to my employer when it comes to accessibility testing. It's a hard enough sell for me to want to purchase a Home edition license for my own personal use and testing freelance projects.
\n", "date_published": "2019-02-03T01:28:00Z" },{ "id": "https://100daysofa11y.com/2019/02/01/day-63-practice-with-jaws/", "url": "https://100daysofa11y.com/2019/02/01/day-63-practice-with-jaws/", "title": "Day 63: Practice with JAWS", "content_html": "Back to playing with assistive technology. I wanted to mess around with speech input software, but I started the process and realized that will be a weekend project, due to the learning curve. So I settled on working in JAWS today to continue learning assistive technologies and what experience they provide.
\nNote: JAWS is really robust and considered top-notch in the screen reader industry. By no means, am I an expert at using JAWS. However, I need more practice with it, since I lean more heavily on NVDA for screen reader testing.
\nJAWS stands for "Job Access With Speech".
\nThe cursor on the screen blinks REALLY fast when JAWS has been activated.
\nSome of JAWS basic keyboard commands are very similar to NVDA's (or vice versa). That was extremely helpful when experimenting with it. That made me happy when thinking about one of my blind friends that recently made the switch from JAWS to NVDA. It likely made her transition a whole lot easier! (now I'll have to ask her about it)
\nI used Insert + F3 a lot to move more quickly through a page's regions and interactive areas. I liked how many options I had on their built-in navigation feature. However, I did accidentally discover a browser difference with Virtual HTML Feature when I switched over to my Firefox window to add notes to this post (colors are funny because my system was in High Contrast Mode at that time).
\nFirefox with Insert + F3:
\n![\"JAWS](\"https://100daysofa11y.com/img/jfw_2019-02-01_16-00-11.png\")
IE with Insert + F3:
\n![\"Virtual](\"https://100daysofa11y.com/img/jfw_2019-02-01_16-01-21.png\")
The built in PDF reader in IE didn't seem to register any regions with the Deque cheatsheet, like NVDA with Firefox did. So I couldn't quickly navigate between tables within the browser.
\nI really like how I could sort links by visited, unvisited, tab order or alphabetically! Plus, I could either go to link or activate the link as soon as I found it in this list.
\n![\"JAWS](\"https://100daysofa11y.com/img/jfw_2019-02-01_16-08-01.png\")
JAWS had a few more customization choices than NVDA:
\n![\"JAWS](\"https://100daysofa11y.com/img/jfw_2019-02-01_16-16-02.png\")
My bad: I inadvertently found a few photos on a site I manage that needs some alternative text because they are not decorative.
\n", "date_published": "2019-02-02T01:31:00Z" },{ "id": "https://100daysofa11y.com/2019/01/31/day-62-identifying-a11y-issues-for-voice-input-users/", "url": "https://100daysofa11y.com/2019/01/31/day-62-identifying-a11y-issues-for-voice-input-users/", "title": "Day 62: Identifying A11y Issues for Voice Input Users", "content_html": "Speech input software is an assistive technology and strategy that people use when they have difficulty using a keyboard or mouse. This may include people with motor, visual, or cognitive disabilities. In the 21st century, it's an excellent alternative for people in all walks of life.
\nWatched:
\nRead:
\nWindows 10 has built-in speech recognition?? It sounds like a combination of Cortana and Speech Recognition could be a cheap alternative to Dragon, but I'd need to experiment a bit with both to compare.
\nApple has a Dictation feature. So, somewhat like Windows, a combination of Siri and Dictation could be used. I've avoided setting up dictation just because of the privacy flag that pops up when it asks permission to connect to an Apple server and learn from your voice over the Internet. Maybe I'm just paranoid and they all actually work that way?
\nDragon offers some ARIA support, but it appears to be limited, and should be tested if relying on aria-label, specific roles, etc.
\nLove this catchphrase from the Web Accessibility Perspectives video:
\nWeb accessibility: essential for some, useful for all.\n
Challenges that people who use speech recognition software face on the web:
\nDesigners and developers should focus on WCAG's Operable principle. In particular, Navigable guideline's success criteria would apply here. If many of those success criteria are met with other users in mind, it will definitely be beneficial to speech recognition users, too.
\nIn the past, I haven't personally been interested in software, like Dragon, yet looking from an accessibility point of view, I'm ready to start testing with speech input technology to better understand how it works and affects people who rely on it when interacting with the web.
\n", "date_published": "2019-02-01T06:02:00Z" },{ "id": "https://100daysofa11y.com/2019/01/30/day-61-identifying-a11y-issues-for-users-who-magnify-their-screen/", "url": "https://100daysofa11y.com/2019/01/30/day-61-identifying-a11y-issues-for-users-who-magnify-their-screen/", "title": "Day 61: Identifying A11y Issues for Users Who Magnify Their Screen", "content_html": "Read:
\nWatched:
\nWindows has a built-in magnifier, as does Apple, but it often isn't always strong enough or robust to help everyone with low vision. Alternative magnification software includes:
\n\nFor mobile, I knew Apple phones and tablets had zoom built in, but Android devices have magnification built-in, too.
\nApple Watch has a zoom feature (YouTube)!
\nTrying to learn all things accessibility, I'm constantly having to rediscover keyboard shortcuts:
\nNever assume that two low vision people are alike. Everyone with low vision has their underlying reasons of why they struggle with that disability. The point is to add flexibility for their particular experience with low vision and the strategies they use to access content and services on the web.
\nChallenges people who enable magnification may encounter on the web:
\nWebAIM's advice:
\nThe general rule when designing for low vision is to make everything configurable. If the text is real text, users can enlarge it, change its color, and change the background color. If the layout is in percentages, the screen can be widened or narrowed to meet the user's needs. Configurability is the key.
WCAG supports people with low vision through it's perceivable principle. 15 reasons to consider designing to include low vision users who magnify their screen:
\nTouch screen accessibility is something I haven't spent much time thinking on. Maybe not ever, come to think of it. I know that touch screens usually require gestures for interaction (i.e. swiping or tapping), but I hadn't thought about how that might affect others. I even know about alternative ways to interact with touch screens, like with switch devices, but I'm not all that familiar with the challenges it can bring.
\nSo, today was a significant learning day to figure out how people could potentially be excluded from phone or tablet design or the apps that live on those devices.
\nRead:
\nWatched:
\n\nThe first thing that comes to mind when I hear touch screen accessibility are the disadvantages of touch screens for specific disabilities. However, touch screens are actually quite beneficial for other disabilities that make it hard to use a mouse or keyboard.
\nThings to consider for touch screen accessibility for web design:
\nIn short, don't take away the choice from users and don't make assumptions of how they use their device. Offer them lots of choices (alternatives for interaction) so they can continue to do what they do.
\nThis list reminds me that not all touch screen device owners use the touch screen. Other interaction methods include voice commands, Bluetooth keyboard, and switch devices. Not all who use the touch screen will touch the device the same way I can. Additionally, not all touch screens receive the same type of touch when it comes to how the screen responds to touch (i.e. hand versus gloved hand or stylus).
\n", "date_published": "2019-01-30T04:44:00Z" },{ "id": "https://100daysofa11y.com/2019/01/28/day-59-identifying-a11y-issues-for-high-contrast-mode-users/", "url": "https://100daysofa11y.com/2019/01/28/day-59-identifying-a11y-issues-for-high-contrast-mode-users/", "title": "Day 59: Identifying A11y Issues for High Contrast Mode Users", "content_html": "Ok, ok... so High Contrast Mode (HCM) isn't explicitly listed in the WAS Body of Knowledge under the current section I'm in, but it's an area of testing that is significant to me. I'm interested in seeing how my content looks when it undergoes transformation created by the system. And I wanted to take time to think about what other's using it may experience and strategies they may have to use when something can't be seen after that transformation.
\nAdditionally, it's such a cheap and easy way to test that I like to encourage other designers and developers to use it as well. It is not insignificant to the people who use your sites and might be using HCM or inverted colors.
\nOne last thing I'd like to mention before sharing what I did and learned... I actually like using HCM on Windows. It has improved greatly over the past few years (I didn't enjoy it when I first tried it). Oddly enough, a Dark Mode feature has been popping up more and more across applications and systems, so that has provided me with an alternative, too. I don't use HCM on a regular basis, but I've used it for relief before in a bright office with bright windows and three bright monitors glaring around me. I experience light sensitivity, so it provides me with a solution to continue working at my computer without contributing to headaches.
\nWorked in Windows High Contrast Mode for most of my work day.
\nWatched Windows 10 tips and tricks Using High Contrast mode to change Windows and screen colors
\nWatched Working with High Contrast Mode – Eric Bailey #ID24 2018
\nSomething I always have to look up when I want to test with HCM is the keyboard shortcut to activate it: Left Shift + Left Alt + Print Screen. The same key combination will exit HCM.
\nNot all of my Windows custom colors come back to life after using High Contrast Mode. Weird.
\nInvert colors, which is completely different experience to me, on macOS can be activated by Control + Option + Command + 8.
\nHCM offers some personal customization of colors. I played with it some and settled on the High Contrast #1 preset that offered black background and yellow text. Then I tweaked hyperlink colors to stand out more in my browser (Firefox).
\nHCM benefits people with visual and cognitive disabilities, as well as people with environmental impairments. Some examples:
\nNot surprisingly, WCAG comes into play here: SC 1.4.8 Visual Presentation. Yes, that's inside the Perceivable principle!
\nThe last point brought home the issue that we can never assume how someone else's system is set up. Default HCM offers white text on black background. But that doesn't work for everyone, dependent upon their visual needs and preferences. The best we can do is follow some core principles to enable people to perceive our content:
\ncurrentColor, and buttonTextFirefox partially support HCM code, and Chrome doesn't support it at all. Microsoft supports it though with:
\n@media (-ms-high-contrast: active) {}
For the most part, I was pleasantly surprised that I had no trouble seeing all components on my screen throughout the Windows system, as well as elements on familiar web pages that I frequent. There were a few exceptions, but at least I knew when things were present, even if I couldn't see him. Not great for someone new to those sites, though.
\nWorking in a CKEditor today, I discovered they had a neat trick for people using HCM. The editor icons were no longer icons; they were plain text. Kind of neat! Read further ahead to see more of my experience.
\nAs I mentioned under "What I learned today", my HCM encounter with plain text transformation from icons in a CKEditor was a surprise:
\n![\"CKEditor](\"https://100daysofa11y.com/img/firefox_2019-01-28_14-36-45.png\")
I had to turn off HCM just to remember what I was used to looking at:
\n![\"CKEditor](\"https://100daysofa11y.com/img/firefox_2019-01-28_15-23-48.png\")
Naturally that got my very curious. So, I visited the CKEditor website and dug into their documentation. Indeed, they have they're own support for HCM. Some one put some thought into it! The same transformation did not happen as I wrote this post in WordPress with their TinyMCE editor.
\n", "date_published": "2019-01-29T04:57:00Z" },{ "id": "https://100daysofa11y.com/2019/01/27/day-58-identifying-a11y-issues-for-keyboard-users/", "url": "https://100daysofa11y.com/2019/01/27/day-58-identifying-a11y-issues-for-keyboard-users/", "title": "Day 58: Identifying A11y Issues for Keyboard Users", "content_html": "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:
\nThe 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:
\nIf 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.
\nThat 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.
\nToday 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.
\nOne thing I did learn:
\nA 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)\n
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.
\n", "date_published": "2019-01-28T05:12:00Z" },{ "id": "https://100daysofa11y.com/2019/01/26/day-57-comparing-at-and-strategies-of-people-with-disabilities/", "url": "https://100daysofa11y.com/2019/01/26/day-57-comparing-at-and-strategies-of-people-with-disabilities/", "title": "Day 57: Comparing AT and Strategies of People with Disabilities", "content_html": "Before I move into the "Identifying accessibility issues/problems" section of the WAS Body of Knowledge, I needed to recap for myself what I learned this week about people with different types of disabilities, the barriers they run into, strategies and assistive tech they use to overcome barriers, and the WCAG principles that benefit each one. I ended up with an imperfect table visualization as I tried organizing my thoughts on what I'd learned this past week, as well as the entirety of the past 56 days.
\nIt's no easy task trying to visualize comparisons (in table format) of disability types and strategies used to interact with the web. For one, pigeon-holing any disability is tough, due to the nature of variety within any disability type. And organizing that information for me to better understand what strategies and assistive tech may be used in different instances really challenged me in considering what the best way was to approach this visualization. My personal cheat sheet as a 2D table doesn't do the information justice. There are experts out there who have likely wrestled with this themselves.
\nAssigning the WCAG principles to each instance helped me really think about why these principles were developed and how invaluable they are to many people in a very real and personal way.
\n", "date_published": "2019-01-27T05:19:00Z" },{ "id": "https://100daysofa11y.com/2019/01/25/day-56-practice-with-narrator/", "url": "https://100daysofa11y.com/2019/01/25/day-56-practice-with-narrator/", "title": "Day 56: Practice with Narrator", "content_html": "Back to exploring more assistive tech, specifically screen readers. Today I experimented for the first time with Narrator, the built-in screen reader for Windows. I was a bit apprehensive at first since it has not been on my priority list to learn, knowing that only a mere 0.3% of desktop screen reader users actually use Narrator, according to WebAIM's latest Screen Reader Use Survey. However, it's free and built-in for Windows users (and it's mentioned in the WAS Body of Knowledge study material), so I'm giving it a chance.
\nThere is still so much to learn! Jumping between screen reader programs leaves my head spinning with all the shortcut keys I'd need to know. I'll come back to this screen reader at some point because one hour of use is not enough to get fully comfortable with it. I also need to expand upon my cheatsheet to include more commands/tasks. Currently, it's just a quick guide to the most frequent tasks I've needed.
\nLittle #a11y side project: Get a random web accessibility related resource, article, tool, wiki page or else everytime you visit 👉 https://t.co/7Gcvcgj6px
— Marcus Herrmann (@_marcusherrmann) January 24, 2019
\nAuditory disabilities range from different levels of hearing difficulties to deafness, and may even include deaf-blindness. Being inclusive of this group seems fairly straightforward and easy (albeit captioning may require some budgeting).
\nUsers that are deaf from birth may have sign language as their first language. Text information on websites can be their second or third language. Icons, illustrations, and images can help enhance clarity of information provided on a website.
\nIn order to include people with auditory disabilities, web designers and developers need to review the WCAG perceivable principle. Effective strategies of accommodation for the hearing impaired include:
\nOffering sign language video as an alternative can be a nice-to-have (WCAG SC 1.2.6, Level AAA), but it isn't always the right solution for every person with a hearing impairment. Though deaf culture is a thing, designers should never assume that every deaf person knows sign language. Additionally, it can be hard to clearly see sign language provided via web video.
\nIt is controversial to use the word disabled in conjunction with a deaf person. Many within that community don't consider themselves disabled due to the fact that they are thinking and capable people.
\n", "date_published": "2019-01-25T04:48:00Z" },{ "id": "https://100daysofa11y.com/2019/01/23/day-54-users-with-motoric-disabilities/", "url": "https://100daysofa11y.com/2019/01/23/day-54-users-with-motoric-disabilities/", "title": "Day 54: Users with Motoric Disabilities", "content_html": "More on people with various disabilities. Today's exploration led me to learn more about people with different motor disabilities. This group may include people with cerebral palsy, multiple sclerosis, quadriplegia, and arthritis.
\nWhen considering people with motor disabilities, web designers and developers should hold fast to WCAG's operable principle. Specific important concepts includes creating a usable interface that:
\nThere are one-handed keyboards for people with the use of only one hand. Other assistive technologies that can be used by those with more severe paralysis include head wands, mouth sticks, voice recognition software, switch access, and eye-tracking.
\n", "date_published": "2019-01-24T05:20:00Z" },{ "id": "https://100daysofa11y.com/2019/01/22/day-53-users-with-cognitive-disabilities/", "url": "https://100daysofa11y.com/2019/01/22/day-53-users-with-cognitive-disabilities/", "title": "Day 53: Users with Cognitive Disabilities", "content_html": "Users with cognitive disabilities can include a wide scope of people, including autism, Down syndrome, Alzheimer's, and ADHD. Persons in this category may have trouble concentrating, experience a neurophysiological disability, or struggles with a level of intellectual disability. People with cognitive disabilities may use some of the same strategies that people with reading difficulties use in order to navigate the web. Additionally, some people in this group may use assistive technology that assists with writing on the web.
\nThings to consider as a web developer/designer when trying to include this category of disability:
\nThis population is larger than those with all other physical and sensory disabilities combined, and yet it's harder to use a universal solution for everyone within this group (due to the scope of abilities categorized within this group).
\nMemory and organization are two big challenges that this group has to overcome on a daily basis.
\n", "date_published": "2019-01-23T04:49:00Z" },{ "id": "https://100daysofa11y.com/2019/01/21/day-52-users-with-reading-difficulties/", "url": "https://100daysofa11y.com/2019/01/21/day-52-users-with-reading-difficulties/", "title": "Day 52: Users with Reading Difficulties", "content_html": "Screen readers. They're just for the blind and visually impaired, right? Wrong! There's a whole other class of screen readers and screen reader users that often get little recognition. I'm talking about people who have difficulty reading. This group contains a wide spectrum that may include, but is not limited to, people with ADHD, dyslexia, Irlen syndrome, or memory loss. And I'm accusing myself of not acknowledging this group when it comes to envisioning people who use screen readers (text to speech technology).
\nWatched:
\n\nRead:
\nThere is a stark difference between screen reader use by people with reading difficulties as compared to the blind. For one, the first group doesn't need all things read. They mostly need assistance with having some text read aloud, rather than having everything read aloud along with additional navigational aids. A couple of screen readers that benefit this group:
\nAnother strategy that people with reading difficulties use to access content on the web is to change styles on a web page or document. This includes customizing font size, color, and family. Using true text, rather than text inside of images, makes the reading experience for this group of people more enjoyable and inclusive.
\nExamples of barriers that may stand between people with reading difficulties and the web content they pursue:
\nContinuing on through the WAS Body of Knowledge, I'm currently working through concepts that involve building websites that accommodate strategies used by people with disabilities. Today I focused on those with low vision. I'm personally familiar with the group the most, and yet the strategies that people with low vision use to access web content can vary greatly. So, I consider there is still room for me to learn here.
\nWatched:
\n\nRead:
\n\nThere are several low vision users that use screen readers, but often times they make the most out of the vision they do have by:
\nZoomText Magnifier/Reader is a Freedom Scientific product (the same company that produces JAWS). It appears to be a very robust program, offering enhancements to increase visibility of content, cursor, and focus. Additionally, it has a screen reader function, and has a toolbar that lets the user search and find by text, headings, lists, tables, etc (unified finder). ZoomText and JAWS can work together.
\nVoiceOver can describe images to you, such as telling you if a photo features a tree, a dog, or four smiling faces. It can also read aloud text in an image — whether it’s a snapshot of a receipt or a magazine article — even if it hasn’t been annotated.
WOW. I tried this on my iPhone and verified that it could describe a picture of my son outside in the snow. My mind was BLOWN. This technology makes me very happy for one of my blind friends!
iOS magnification can jump from 100% to 1500%. Android phones have magnification, too.
\nHigh contrast text, color inversion, and color correction are available on Android 5.0+, however, they are still considered experimental features. That's interesting, considering these are solid accessibility options on iPhones.
\n", "date_published": "2019-01-21T05:06:00Z" },{ "id": "https://100daysofa11y.com/2019/01/19/day-50-refreshable-braille-displays/", "url": "https://100daysofa11y.com/2019/01/19/day-50-refreshable-braille-displays/", "title": "Day 50: Refreshable Braille Displays", "content_html": "Today marks my halfway point in learning. 50 days down (total of 72 hours study time), 50 more to go! So far, I've managed to cover swaths of WCAG, ARIA, and ATAG documentation. Additionally, I've learned about JavaScript techniques to better support screen readers when it comes to custom widgets. During this time, I've also managed to experiment with some of the popular screen readers (VoiceOver, NVDA, and TalkBack).
\nOn that note, I'm curious about braille output. I'm very familiar and comfortable with speech output from screen readers, but am less so with refreshable braille displays. Unfortunately, I don't currently have access to a refreshable braille display (not that I could read it, even if I did), but that won't stop me from learning about them online.
\nWatched on YouTube:
\nUse your refreshable braille display with Narrator on Windows 10
\nWhat is REFRESHABLE BRAILLE DISPLAY? What does REFRESHABLE BRAILLE DISPLAY mean?
\nRead:
\n\nBack tracking to Day 41, I returned to the CodePen project I'd started in order to complete making it accessible. Due to unforeseen popularity of this pen (before I'd even completed it), I felt I needed to get all the pieces right.
\nMy pen now meets the requirements that need to happen for a dialog/modal to be accessible. I even ran a quick test with VoiceOver on Safari, as well as keyboard navigability.
\n\n See the Pen \n Accessible Modal by Amy (@digilou)\n on CodePen.\n
\n\n\nThe two things I hadn't completed earlier involved:
\nIt was the Tab trap that was getting me. I knew the Tab key was associated with key code 9, but it took me a bit to realize I needed to attach an event listener of keydown to the close button. That solved it!
As for returning focus, it was as simple as adding the focus method onto open button within my closeModal function. It worked!
Still looking over the WAS Body of Knowledge section about creating accessible single-page applications (SPAs), I took my research a step further beyond the items they listed (aria-live and focus management), and started exploring on my own about what else I needed to pay attention to when it came to making SPAs accessible.
\nRead:
\nSingle page applications, Angular.js and accessibility (Simply Accessible)
\nAccessible Page Titles in a Single Page Application (hiddedevries)
\ntabindex="-1" lets scripts bring focus to an element, but not let a user tab to it.Yesterday during my Part 1 learning, I watched videos that gave me a great idea of how live regions worked. Today I looked over documentation to see what W3C had to say about it.
\nRead the WAI-ARIA documented parts on:
\n\naria-live is just a strong suggestion to user agents and AT, but may be overridden by user agents, AT, or the user.aria-relevant indicates what notifications the user agent will trigger when the accessibility tree within a live region is modified.aria-relevant values include:\naria-busy is a state, not a property.aria-busy exists to indicate an element is being modified and that AT may want to wait until the modifications are complete before showing them to the user.Today I started digging into ARIA live regions to better understand how they can be useful in making SPAs (single-page applications) more accessible to screen reader users. This is a topic that will take some research because I'm not familiar with using most of those attributes. YouTube was a great place for me to start because I knew I'd find a few examples of how they work along with helpful screen reader demos.
\nWatched:
\nUdacity lesson Introducing ARIA Live (YouTube)
\nTried the ARIA Live Region Test (by Terrill Thompson) with VoiceOver on Safari.
\naria-live attribute is useful to update a screen reader user about changing content. It only reads the changed content.aria-atomic attribute can be set as true on the same element as the aria-live element in order to read the entire contents within that element, in order to give context.aria-live possible values:\naria-busy and aria-relevant.So much to learn, so little time! I'll be spending more time on the topic and intricacies of live regions tomorrow, as well. As always, I am ever so grateful for those who have taken time to experiment and share their screen reader test findings with the rest of us.
\n", "date_published": "2019-01-16T05:21:00Z" },{ "id": "https://100daysofa11y.com/2019/01/14/day-45-more-aria-roles-requirements/", "url": "https://100daysofa11y.com/2019/01/14/day-45-more-aria-roles-requirements/", "title": "Day 45: More ARIA Roles Requirements", "content_html": "Today was a short day. I wanted to finish adding ARIA role requirements to my spreadsheet, then take a peek at the next section to plan for my current study week.
\nI was surprised that the timer role didn't have any requirements but the accessible name. Maybe I thought there would be a required marker, of sorts, to read out as the time ticked down? It's a subclass of the status role, and has 22 inherited states and properties. I haven't created one myself, so there's more to explore!
\nThis is a continuation from Day 44 where I consulted the WAI-ARIA docs about requirements that come along with each role.
\n", "date_published": "2019-01-15T04:45:00Z" },{ "id": "https://100daysofa11y.com/2019/01/13/day-44-aria-roles-have-requirements/", "url": "https://100daysofa11y.com/2019/01/13/day-44-aria-roles-have-requirements/", "title": "Day 44: ARIA Roles Have Requirements", "content_html": "Finishing off my study week about interactive controls/widgets from the WAS Body of Knowledge, I came back to ARIA documentation to look through ARIA roles, their parent and child relationships, and required attributes. This was actually a very engrossing study time as I dove into how some roles are related and how they can help make an interactive component more accessible!
\nRequirements for roles used in interactive controls, found in the WAI-ARIA docs, include:
\nrole="combobox" has to have textbox and listbox, tree, grid, or dialog as children)role="cell" has to have row as a parent role)role="checkbox" has to have the aria-checked attribute)One thing I've discovered on my learning journey is that I'm having a much easier time reading "hard" documentation the further along I get. It was overwhelming at first, yet as I better understand what I'm looking for, the easier it is for me to browse and find the answer to what I'm looking for. For instance, knowing that some roles have different requirement, I did a Ctrl + F to quickly find the word "required" throughout the documentation, so I could quickly find which roles had required parents, children, and/or attributes.
\nOne requirement that was completely new (and of interest) to me: the heading role requires an aria-level attribute. Makes sense, I just wouldn't have guessed to use it.
\n", "date_published": "2019-01-14T01:33:00Z" },{ "id": "https://100daysofa11y.com/2019/01/12/day-43-quick-look-over-accordion-keyboard-interactions/", "url": "https://100daysofa11y.com/2019/01/12/day-43-quick-look-over-accordion-keyboard-interactions/", "title": "Day 43: Quick Look over Accordion Keyboard Interactions", "content_html": "Another sick day, so I spent 30 minutes looking over information about a custom accordions.
\nExpected keyboard interactions with accordion headers include:
\nIt was interesting to me to see WAI's code example made use of dl, dt, dd, and button within the accordion. Progressive enhancement!
Under the weather again, cold symptoms that just won't let go. Regardless, I put in half an hour today, since some studying is better than no studying. Which is why this challenges exists in the first place: to keep making progress, albeit slowly.
\nAfter spending a couple days learning what a custom modal needs to be accessible, and then making an attempt myself to code it, I felt more confident moving ahead to review more patterns and their expected keyboard interactions.
\nToday I looked over a custom menu with submenu items that open when interacted with. A few things I learned:
\n.focus() or aria-activedescendent.Started coding a custom modal to experience for myself what effort has to go into it, and solidify what keyboard interactions and ARIA. It's far from fully accessible (or even pretty), but I've started work on CodePen, for those curious about how I'm working:
\n\n See the Pen \n Accessible Modal by Amy (@digilou)\n on CodePen.\n
\n\nIf the embed doesn't work, you can view my Accessible Modals on CodePen
\nNote: By the time some of you read this post, my project may be complete, yet others will see that focus has not been properly delegated to the inside of the modal and tabbing has not be restricted to stay within the modal.
\nWhat have I learned from this just in the hour I spent today?
\nposition="fixed" worked better on one platform than position="absolute", when making the modal cover the entire screen.Today I found myself doing a lot of testing with the NVDA screen reader on PDFs at work. So, I made a diversion from my plan to code a custom modal tonight, instead to document what I was learning throughout the day.
\nI should note that this was not my first encounter with NVDA. It has been my go-to screen reader for testing webpages during the past year. On that note, this post does not go in-depth about all the things NVDA, but rather points out things I hadn't spent time learning during these quick experiments I've done in the past.
\n| Task | \nShortcut | \n
|---|---|
| Start reading continuously (from this point on) | \nInsert + ▼ | \n
| Stop reading | \nCtrl | \n
| List all headings, links, and landmarks | \nInsert + F7 | \n
| Next line | \n▼ (down arrow) | \n
| Next character -or- Next input option (radio buttons, selection list) | \n► (right arrow) | \n
| Quit NVDA | \nInsert + Q | \n
On top of all these new shortcuts and tidbits, I was reminded that I am not a screen reader user. When I was trying to solve a "problem" within a remediated PDF document, I finally concluded that it wasn't the document's problem, but rather the way I was using NVDA as a novice screen reader user. Listening to the PDF with JAWS, which gave me the results I expected, I decided to abandon the issue I thought the document had. In doing so, I'm relying on the fact that I am not that user, and the appropriate tags given to the document would allow real screen reader users to make their own decisions while still being able to access all the content within this document.
\n", "date_published": "2019-01-10T04:40:00Z" },{ "id": "https://100daysofa11y.com/2019/01/08/day-39-concepts-concerning-custom-modals/", "url": "https://100daysofa11y.com/2019/01/08/day-39-concepts-concerning-custom-modals/", "title": "Day 39: Concepts Concerning Custom Modals", "content_html": "Today I started combing through code and underlying principles to create accessible dialogs (modals). The development of this pattern has eluded me in the past, so I wanted to tackle it first. I didn't get as far as I'd liked (no coding on my part), but did squeeze in the time to at least review what others have done and why they did it.
\nrole="dialog" instead.aria-label, aria-labelledby, or aria-describedby) and dialog role should be announced.visibility: hidden.With all the effort that goes into a custom dialog, and the many shortcomings with only partially-reliable workarounds, it makes me wonder if dialogs are really the answer to some "problems". I look at the usability aspect for all users, and wonder if dialogs really meet a user's need, or rather, a designer's and business need.
\nStruggling a bit as to what exactly I need to be studying when it comes to accessible techniques (beyond browser and assistive technology compatibility), I'm moving onto the next WAS Body of Knowledge topic "create interactive controls/widgets based on accessibility best practices." I feel mostly familiar with the topic I researched yesterday, and I feel like getting back into code and doing some testing myself will help solidify more knowledge. In reality, the interactive controls/widgets concept will circle back around to the "accessible JavaScript, AJAX, and interactive content" and ARIA sections, but will offer me more context and application to this head knowledge.
\nAnd, to be honest, after all this reading and Googling, I'm ready to jump back into coding with CodePen, as well as my local environment.
\nrole="application" on one of my own CodePen projects.What I learned through researching accessible interactive content, I need to:
\nBasic keyboard interactions with a webpage:
\nRemember... W3C has a thorough document on ARIA authoring practices, including an extensive section on Design Patterns and Widgets.
\nrole="application" (MDN) should be used sparingly. It overrides many AT keystrokes, such as ones that allow screen reader users to navigate by headings, landmarks, and tables.In Deborah Edwards-Oñoro's The State of the Web: Making the Web More Accessible, she offers her takeaways from a 30-minute video that Google produced about the importance of web accessibility. It's a quick read when you're crunched for time, and a good reminder of just how important accessible websites are. My favorite was takeaway #1: The more accessible your website is, the more usable it is to everyone.
This week I'm moving into the WAS Body of Knowledge section "choose accessibility techniques that are well-supported". Most of these topics I've had some experience with and even preached about myself. For instance, adhering to coding standards and building with progressive enhancement in mind are two concepts I firmly believe can eliminate a lot of problems. I also understand that testing across platforms, browsers, and assistive technologies is important in order to discover what unanticipated barriers might occur, despite coding to standard.
\nThat being said, today I focused on learning about what combinations of browsers and assistive technologies have been tested to work the best together. I know a bit about screen reader and browser combinations, but I'm certain there is more to learn than the base knowledge I have.
\nHere's what I learned:
\nOne of my favorite resources is canisue.com when checking for support across browsers. Choice of elements can really matter in cases where IE doesn't support all HTML5 elements, including dialog. This resource alone has taught me so much about browser support for standards as I've worked through projects. In this vein, HTML5 Accessibility is another useful site.
\nOne thing to remember is that following standards (like WCAG) are your best bet. Aiming for specific AT or browser support is not a good approach since updates can be made and support between the two can change.
\nNote: when reading through the Level Access wiki about AT support by browsers, these were for most popular browsers. Other browsers like Opera were not mentioned.
\n", "date_published": "2019-01-07T05:01:00Z" },{ "id": "https://100daysofa11y.com/2019/01/05/day-36-questions-to-ask-throughout-the-product-life-cycle/", "url": "https://100daysofa11y.com/2019/01/05/day-36-questions-to-ask-throughout-the-product-life-cycle/", "title": "Day 36: Questions to Ask throughout the Product Life Cycle", "content_html": "Today wrapped up my research for the week about integrating accessibility into a product's life cycle. I ended with reviewing what a product's life cycle looks like, and how everyone can play a role during each phase to ensure accessibility is considered throughout development, rather than an afterthought.
\nStages of a product's lifecycle with accessibility questions to ask at each stage:
\nToday's mission was to reflect on user (usability) testing, and search for accessibility verification testing (AVT). AVT was new to me, and I had a harder time finding that exact word combination when searching the web. So, I ended up reading about accessibility user testing and manual testing a developer can perform on her own to emulate user testing.
\nDesigning for Guidance (Microsoft) [PDF] offers tips about the varied learning styles that people have. With the approach of inclusive design in mind, this tiny booklet will make you think more critically when you develop a product or learning course for your large audience.
\n", "date_published": "2019-01-05T04:25:00Z" },{ "id": "https://100daysofa11y.com/2019/01/03/day-34-talkback-on-android/", "url": "https://100daysofa11y.com/2019/01/03/day-34-talkback-on-android/", "title": "Day 34: TalkBack on Android", "content_html": "A diversion from my quality assurance research this week out of necessity of testing with an Android screen reader at work. Time spent today: 2 hours.
\nComparing accessibility and user experience, both have benefits for all, yet differ mostly by audience:
\nAccessibility includes a more technical aspect (considerate of assistive technologies, for instance); UX is more principled in its approach.
\nUsable accessibility = a11y + UX.
\nAccessibility is just one aspect of the "universal web".
\nLooking at accessibility a little closer, what makes a person disabled? We may think of someone with a disability as having a certified report by a doctor or proving an obvious physical or mental difference from our own. Yet disabilities are actually better defined as a conflict of a person's ability with their environment. It puts us all on a spectrum, doesn't it?
\nFor people without disabilities, technology makes things convenient. For people with disabilities, it makes things possible.- Judith Heumann, U.S. Department of Education’s Assistant Secretary of the Office of Special Education and Rehabilitative Services\n
There are several benefits to starting out a design process with accessibility in mind, rather than catching it after production and resorting to remediation. Some of these benefits include:
\nMoving onto the next WAS Body of Knowledge study topic: integrating accessibility into the quality assurance process. Approximate study time: 1 hour.
\nConsidering accessibility shouldn't just happen at the mockup or code level. It can happen throughout the product's entire life:
\nAdditionally, I read about the agile and waterfall processes and when to apply accessibility when working through the cycle:
\nLove this statement by Karl Groves which nails it when it comes to encouraging the development of an accessible product rather than blockading it:
\nBecome a member of the team, not a gatekeeper, and you will be seen as a resource instead of a hurdle.
After learning a bit this past week about principles and concepts to create JavaScript that is accessible, I used today as a chance to remind myself of who we are doing this for, why it's helpful to them, and how we can strive to meet them where they are.
\nSpending an hour of my time today, I used IAAP's Prepare for WAS online resources list to get me started.
\nWCAG 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.
\nAs an aside, one fun thing about this journey has been revisiting familiar websites and running across familiar names in the web accessibility circle.
\nToday I sought to learn about JavaScript events. Specifically, in the context of accessibility, I wanted to dig deeper into two ideas that can make or break the interaction of assistive technologies with websites and web apps:
\nSearched for articles and videos pertaining to proper use of event handlers to optimize accessibility.
\nAs developers, we shouldn't offer interaction with just one type of device or peripheral. Coding device-independent event handlers will open up the experience to a wider audience of users. We know to make our sites keyboard accessible, but we shouldn't build just for keyboard users either. Examples of device-independent event handlers:
\nonFocusonBluronSelectonChangeonClick (when used with links or form elements)The examples aforementioned are not unbreakable. Altering default behaviors can present problems.
\nWhile searching for articles, I was amazed to go back 10 years (or more!) on the topic of accessible JavaScript. My time in this field is still so fresh and new that I forget how long these conversations have been going on. A huge thank you to all who have initiated these conversations and built an education for the rest of us!
\nProperly managing focus, especially within web applications, is a key component to making JavaScripted web pages accessible. Determining logical order of code and components can be another challenge when it comes to web accessibility. Sites need to be coded thoughtfully so that the proper reading order of each section of the page is synchronous visually and audibly.
\nI learned a few things today that will not only make me a better accessibility specialist, but also a better developer.
\nStudy hiatus on Christmas Day. I was just having too much fun being with my family. Back at it today, despite the sudden onset of a head cold. Time spent studying: 1 hour.
\nThe following ideas were not new to me, yet I appreciated the reminders, especially in context of web accessibility (not just usability):
\nContinuing on my course of study by following the WAS Body of Knowledge (BOK), I've moved onto Accessible JavaScript, AJAX, and interactive content for the coming week. The BOK offers a basic list of things to consider when writing dynamic content and code:
\nHowever, this list isn't exhaustive, and the BOK doesn't go into greater detail about what I need to study for or be more knowledgeable about. It does encourage me that I don't have to be a JavaScript expert to understand the concepts, principles, and strategies for creating accessible code and content.
\nAll that being said, I'd like to get a handle on the basic concepts provided, learn from good examples of accessible JavaScript, and discover other strategies that could be important for the WAS exam and my future as a digital accessibility consultant.
\nI gave myself a bit of slack today since it's Christmas Eve, and my family time is more important than my study habits during holidays. However, I did dedicate 45 minutes to remain consistent and get a jump on the next section of the BOK.
\nonClick event if used on an non-link or non-control element (i.e. a div element). In those cases, Enter or Spacebar will have to be detected for interaction.Today I came back to practice using VoiceOver (VO) a bit more, since I was struggling with it yesterday. More practice definitely gave me more confidence. It would take a week of consistent use for me to use VO more naturally with my laptop. That's an aspiration for the near future.
\nNeeding to take a break from reading through so much documentation, I decided to spend some time with some assistive technology. Specifically, I practiced navigating with VoiceOver (VO) on my MacBook Pro. Turns out that it was more a challenge than I anticipated!
\nDespite what my study calendar says, today was my last day spent fully focusing on the Authoring Tools Accessibility Guidelines (ATAG). I'll be spending the weekend experimenting with a couple assistive technologies (AT), learning and practicing some accessible code, and reviewing some of my notes for standards I've learned. ATAG has been fairly easy to understand, and will likely be even easier to implement once I have a chance to put it to practice this winter.
\nThere is no way I'll remember all that I read today or even be able to sum up the wealth of information offered, but I rely on the fact that there is additional technical information to aid in meeting the success criteria of ATAG via Implementing ATAG 2.0. This parallel documentation (notes) adds intent, examples, and related resources to help a developer make better accessibility choices.
\nI've been really impressed with many of the articles on 24 Accessibility that have been published this month. If you haven't had a chance to read any of those articles, do it! So much good information covering a variety of topics within web accessibility. You're missing out if you haven't tapped into the expertise that's been made available all throughout the month of December.
\n", "date_published": "2018-12-22T01:29:00Z" },{ "id": "https://100daysofa11y.com/2018/12/20/day-21-atag-resources-wai-vetting-process/", "url": "https://100daysofa11y.com/2018/12/20/day-21-atag-resources-wai-vetting-process/", "title": "Day 21: ATAG Resources & WAI Vetting Process", "content_html": "I tend to do things backward, and my learning process seems to be no exception. Today I read through some of W3C's Web Accessibility Initiative (WAI) informative resources and realized they've broken down ATAG documentation in a simplified way. And here I was going directly to the recommended specification and trying to break it down for myself. Well, I can't say I didn't challenge myself that way!
\nW3C's Web Accessibility Initiative (WAI) website has been recently overhauled this year and I've found a lot of great informational points on this site that have been easy to navigate. Some of their ATAG resources include:
\nAdditionally, W3C has their recommended specification and implementation notes:
\nToday I moved onto the second major portion of the Authoring Tools Accessibility Guidelines (ATAG) spec to learn about how the content and code being produced by authoring tools should be accessible and how authors should be able to easily make that happen. It comes to no surprise that there are more references to WCAG principles and its conformance levels.
\nThe Authoring Tool Accessibility Guidelines (ATAG) 2.0 have been fairly easy for me to read, so far. Having spent a significant amount of time studying WCAG, I'm noticing the similarities in principle, guidelines, and success criteria. All the more, it seems reasonable to expect web developers to assimilate ATAG into their mindset and workflow.
\nAccessibility Pro Certified: To Be or Not To Be (24 Accessibility) is a timely article by Glenda Sims that answers the questions of "what is an accessibility professional?" and "how do I become one?" Perfect timing for me, as I've been wrestling with these questions myself, which pushed me to create this site and challenge. I could've used this insight a year ago when I did my first 100 Days of A11y challenge, which involved a more loose direction than I have now.
\n", "date_published": "2018-12-19T05:09:00Z" },{ "id": "https://100daysofa11y.com/2018/12/17/day-18-introduction-to-atag/", "url": "https://100daysofa11y.com/2018/12/17/day-18-introduction-to-atag/", "title": "Day 18: Introduction to ATAG", "content_html": "ATAG stands for Authoring Tool Accessibility Guidelines. Thanks to my pursuit to study for the WAS certification exam, this was my first introduction to ATAG. Sadly, I wish I'd been exposed to this earlier. This is an important specification recommended by W3C to offer guidelines in making web authoring tools (like WordPress) accessible to content creators (e.g. bloggers) who may have a disability Secondly, ATAG offers guidelines for developers, so that the code produced by their authoring tool of choice (e.g. WordPress) will output accessible code in order to make an accessible website (WCAG comes into play again).
\nFor me, reading this spec for the first time, this is timely. I'm starting to see so many State of Alaska departments leaning on content management systems (CMS) to generate and update their web presence. My concern has grown about how accessible these sites are (is semantic code outputted?), but I've had nothing solid to back up my concern. Fortunately, others are way ahead of me and have given their time to form a specification to support this very concern.
\nThis spec holds even more relevance for me as I continue to produce content for this site.
\nThere are two major parts of the ATAG spec:
\nATAG shares similar guideline traits as WCAG. Each major part has principles, guidelines, success criteria, and three conformance levels (A, AA, AAA). This structure should help me absorb its documentation much easier than ARIA!
\nThe definition of "authoring tools" in the ATAG glossary lists of several avenues that I didn't even consider at first sight. Those tools include:
\nToday I quickly went through the ARIA Authoring Practices 1.1, a W3C Working Group Note included in the ARIA suite of documentation. Though I found the WAI-ARIA 1.1 spec a bit hard to retain, this additional "note" helped me see some real-life application of the ARIA spec. It's definitely something I'd recommend web developers bookmark when needing to refer to common pattern examples, use of landmark regions, and a how-to for developing a keyboard interface. It's an informative resource best tapped into for specific information, rather than a document read from top to bottom.
\nThere are a couple principles behind why using ARIA can be a challenge, and why sometimes it is better to not use ARIA rather than write bad ARIA:
\nThis guide does not provide help on mobile and touch support. Apparently, ARIA is not consistently supported in mobile browsers. On that note, if you notice my resource mentioned at the end of this post, ARIA isn't consistently supported across screen readers (it's only 70% reliable!), and varies even more depending on the browser the screen reader is paired with.
\nConcerning role="presentation", this role is ignored, if one of the following is true:
Today I went over more ARIA States and Properties. Honestly, I'm still feeling a bit overwhelmed trying to learn all these, but I'm not going to get too stuck on memorization at this point. I'll find ways in my future studies to come back to these when I'm actually applying them, where necessary when HTML gaps are present.
\nI still have so much to learn...
\nThough there is still much for me to learn about ARIA roles, I've moved onto States and Properties of ARIA. ARIA is definitely challenging my ability to stay above water when it comes to information overload. Only 1 hour spent wading through information today.
\naria- prefixed attributes describing the object.Two weeks of consistent web accessibility studying down! And a total of 24 hours (non-consecutively) spent.
\nToday I continued on reading through The Roles Model, this time diving deeper into the definitions of each role. 82 roles is a lot. At times I shifted over to informational documentation to get a well-rounded grasp of the use of ARIA, rather than spending a full hour reading straight through the role definitions.
\nAs an added note, learning (memorizing) these roles could take days, if not weeks. In order to stay on my study schedule, I think reinforcing this type of knowledge is best suited in practice. When I begin studying and creating custom interactive controls and widgets (per the WAS Body of Knowledge), I'll circle back around to ARIA roles.
\nrole="directory" is for static table of contents. I could definitely be using this alongside my aria-label="Table of Contents". Up to now, I've just been using the HTML navigation landmark.role="alert" shouldn't be coupled with focus (like a close alert option), but role="alertdialog" does. Key difference. That, and alert is a live region role, while alertdialog is window role. Understanding the role types first is key to helping understand the what and when to use of these roles.You may say I'm a dreamer, but I'm not the only one...🎵 (John Lennon)
After all these years the Internet has been alive, why don't we have an HTML search landmark??
\nThe WAI-ARIA specification is a doozy! Today I waded into The Roles Model, after feeling a bit lost in some of the earlier parts of the spec. I was feeling pretty run down by the end of my day, so I only spent half an hour on this spec, mostly trying to get my bearings.
\nI didn't realize just how many roles there were in ARIA! Spoiler: there are 82, if you count the abstract roles. Each role falls into a category:
\nAbstract roles were new to me. Rightly so, since they are not supposed to be used in my code.
\nDocument structure role="none"?? That one I'll have to research further. It sounds vaguely familiar from the Internet somewhere.
Out of all of these role types, I am the most familiar with landmark roles, even though I rarely use them, since I lean more on HTML5 landmarks.
\n", "date_published": "2018-12-13T05:17:00Z" },{ "id": "https://100daysofa11y.com/2018/12/11/day-12-wcag-reinforcements-and-aria-conformance/", "url": "https://100daysofa11y.com/2018/12/11/day-12-wcag-reinforcements-and-aria-conformance/", "title": "Day 12: WCAG Reinforcements and ARIA Conformance", "content_html": "Time spent pursuing web accessibility knowledge: 2 hours.
\nI 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.
\nPart 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?
\nI've finished studying WCAG! Now onto ARIA, the next item in the checklist from the WAS Body of Knowledge. WCAG's Robust principle segues into this. As SC 4.1.2 states:
\nFor all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.\n
The WAI-ARIA specification says that it exists to provide:
\nan ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications.\n
And so the twain shall meet when development of custom components occurs.
\nI got a slower start on these docs, as I just wasn't as familiar with them. WCAG had a straightforward POUR outline. ARIA docs didn't have as easy an access point for me, so I had to spend some time trying to create an approachable framework for myself to navigate the less familiar territory. I did manage to:
\nSo many things!
\nWAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement.-and-
It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of object.\n
It's tempting to use ARIA, since it's a bit more mysterious and, therefore, appealing to master, but it can't be stated enough: don't use ARIA if you don't have to. I've heard this before, seen it stated in different documentation, and completely agree. Use semantic HTML first.
\n", "date_published": "2018-12-11T05:31:00Z" },{ "id": "https://100daysofa11y.com/2018/12/09/an-overview-of-wcags-fourth-principle-robust/", "url": "https://100daysofa11y.com/2018/12/09/an-overview-of-wcags-fourth-principle-robust/", "title": "Day 10: An Overview of WCAG's Fourth Principle: Robust", "content_html": "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.
\nOn 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.
\nThe 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.
\nThis 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.
\nTo 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:
\nDigging 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:
\nI 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.
\nRegardless 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.
\nThis 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.
\nAs 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.
\n", "date_published": "2018-12-09T17:42:00Z" },{ "id": "https://100daysofa11y.com/2018/12/08/an-overview-of-wcags-third-principle-understandable/", "url": "https://100daysofa11y.com/2018/12/08/an-overview-of-wcags-third-principle-understandable/", "title": "Day 9: An Overview of WCAG's Third Principle: Understandable", "content_html": "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.
\nOn 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.
\nThe 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.
\nThis 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.
\nTo 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:
\nDigging 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:
\nI 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.
\nRegardless 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.
\nThis 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.
\nAs 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!
\nAs 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.
\n\n See the Pen \n A11y: Use ruby for pronunciation by Amy (@digilou)\n on CodePen.\n
\n\nIf the embed doesn't work, you can go directly to this CodePen
\n", "date_published": "2018-12-08T16:58:00Z" },{ "id": "https://100daysofa11y.com/2018/12/07/day-8-wcag-understandable/", "url": "https://100daysofa11y.com/2018/12/07/day-8-wcag-understandable/", "title": "Day 8: WCAG Understandable", "content_html": "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.
\nAt 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.
\nWhile I'm learning about how how some users perceive and operate pages, I think it's a good time to start diving into some of the assistive technology (AT) that people use. A week ago I had a more cut and dry approach to the WAS Body of Knowledge, as seen on my Google calendar, but now I'm discovering a more natural overlap of ideas as my own curiosity grows and I attempt to apply these ideas in a useful and concrete way.
\nTo start, I spent time with Apple's VoiceOver (VO) on my iPhone. Why this particular AT first? Honestly, I needed it during work today to test and share with others. Secondly, it's one I have the least familiarity with. It's hard to go against how I normally use my iPhone! Yet, enough motivation and time has slowly brought me around and made me also think more on how this AT can lend itself to benefiting everyone in the screen-less world we are presumed to be heading into.
\nVO has a screen curtain mode that turns the screen off, while the functionality continues. This offers added privacy or could save battery power. Careful! I scared myself, not being able to toggle my screen back on. Fortunately, I'd practiced navigating beforehand and listened my way through Settings to turn VO off, which resolved the issue. Phew!
\nPracticed at least 5 ways to interact with my iPhone using VO:
\n| Gesture | \nDesired Behavior | \n
|---|---|
| Swipe down with 2 fingers | \nStart reading continuously (from this point on) | \n
| Tap with 2 fingers | \nStop reading | \n
| Rotate both thumbs in sync (like a dial) | \nScroll through rotor for list settings and navigation options. | \n
| Tap with 1 finger | \nSelect item | \n
| Double-tap with 1 finger | \nChoose item or activate button | \n
I can comfortably listen to VO at a speed of 60%.
\n5 guidelines. 29 success criteria (including 14 Level A conformance. 3 Level AA conformance. 12 Level AAA conformance). And many ever-changing techniques that are sufficient, advisory, or a failure. Just as I pointed out in my Perceivable principle review, this is just one way the World Wide Web Consortium's (W3C) "Operable" principle within the current Web Content Accessibility Guidelines (WCAG) 2.1 recommendation can be broken down. And yet, the documentation that follows is even more massive! Though, looking at it by the numbers can leave one feeling intimidated, exhausted, and uninspired to learn the golden standard of web accessibility, there are better ways to break down the docs into chunks.
\nOn that note, I'll introduce you to WCAG's second principle: Operable. As stated earlier, it has many components, so to speak, but it all boils down to giving everyone the opportunity to successfully navigate each part of your website via the technology of their choosing. For instance, I navigate the web mostly with my mouse, sometimes in unison with my keyboard, when skipping from page to page, link to link. Additionally, my fingers do the walking (nod to the old school yellow pages) when I'm on my smartphone and zipping through sites. However, there are many people who solely use their keyboard to navigate the web. Additionally, all of us rely on clear wayfinding to get from one place to another online.
\nThe second Web Content Accessibility Guideline's says: "User interface components and navigation must be operable." This is a generally defined idea, leading up to more objective goals (success criteria) and techniques.
\nThis 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. "Operable" 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 navigate your website without hurdles.
\nTo dig a little deeper, how can we ensure that everyone can access the variety of 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 Operable guidelines say that your entire webpage should:
\nDigging even deeper into those 4 guidelines, we find each guideline offers its own goals (success criteria) to target common accessibility problems. Rather than writing out all 29 criteria, which could be several blog posts in and of themselves, I'll expand upon the guidelines to include some goals that the criteria are aiming for:
\nI encourage you to check out all the success criteria, now that you are more confident in understanding the guidelines within the second principle. If that page still looks too intimidating, try reading How to Meet WCAG, which is more approachable and provides clearer techniques that help you visualize how to meaningfully apply what you've learned.
\nRegardless of how you take your next steps, I hope you are 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.
\nThis is Day 6 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.
\nI'd also like to note another resource that I've recently tapped into. I've started reading Form Design Patterns by Adam Silver (Smashing Magazine) in the hopes of learning how to make accessible and usable forms on pages that I design and develop. As an added note, I'm reading it on my Kindle Paperwhite because it is more accessible to me in that format, which allows me to enlarge the print, control lighting (no glaring white background or overwhelming backlighting), and read without distractions. Flexible formats are a wonderful thing for everyone!
\n", "date_published": "2018-12-06T02:26:00Z" },{ "id": "https://100daysofa11y.com/2018/12/04/an-overview-of-wcags-first-principle-perceivable/", "url": "https://100daysofa11y.com/2018/12/04/an-overview-of-wcags-first-principle-perceivable/", "title": "Day 5: An Overview of WCAG's First Principle: Perceivable", "content_html": "4 guidelines. 29 success criteria (including 9 Level A conformance. 11 Level AA conformance. 9 Level AAA conformance). And so many more sufficient, advisory, and failure techniques that are ever changing. This is just one way the World Wide Web Consortium's (W3C) "Perceivable" principle within the current Web Content Accessibility Guidelines (WCAG) recommendation can be broken down. But, wait, there's so much more documentation to follow! However, looking at it that way can suddenly leave one feeling intimidated, exhausted, and uninspired to learn even just this small segment of the golden standard of web accessibility.
\nSadly, I get the impression that many web developers, such as myself, feel this way when referring to this documentation. We go in, quickly find what we need, and get out as quick as possible before the abyss of text and jargon overwhelm us. Or, we find a non-normative siteto help us understand the documentation and never once visit the normative documentation (there's nothing wrong with that, by the way).
\nI'm not here to judge you, but rather I am on a long road to better understand the whys and hows of web accessibility, so that I can become a better developer, designer, and person. On that journey, I can only hope to impart some of what I've gained and inspire you to take your own journey, no matter the length.
\nOn that note, let me introduce you to the principle labelled as Perceivable. As stated earlier, it appears to have a ton of components, so to speak, but it all boils down to giving everyone the opportunity to access your application and content by the sense that is dominant for them. For instance, ironically, I rely heavily on my vision to pull in information around me (though I'm visually impaired), but supplement with hearing and touch to fill in the gaps. Lucky me, in such a visually dominant world we live in. Virtually, I have to enlarge print, zoom into pages, and minimize business on the page (yay, for Reader View!). However, I recognize that not everyone is like me. There are people who rely heavily on hearing or touch to interact with their environment. Additionally, there are others who can see much better than I can. And, yet, we all live in the same world, trying to access the same Internet.
\nThe first Web Content Accessibility Guideline's says: "Information and user interface components must be presentable to users in ways they can perceive." Take note, this is just the general idea with goals that is more objectively defined in the success criteria and techniques.
\nTo me, this principle offers us some low hanging fruit to successfully make our websites more inclusive, inviting more people in, who arrive with a different means to interact than our own. Whether someone sees (visual, screen), hears (audio, screen reader), or feels (Braille output) in order to read a blog, buy a plane ticket, or learn a new skill, it shouldn't matter. They should still be able to partake in all those things.
\nTo dig a little deeper, how can we ensure that everyone can access the variety of services and information on the web? Trail down through the levels within the principle, from subjective to objective, via their guidelines and success criteria. The Perceivable guidelines say that content and components should:
\nDigging down further into these 4 guidelines, we find each guideline offering it's own criteria to target potential accessibility issues. Rather than writing out all 29 criteria, which could be several blog posts in themselves, I'll expand upon the guidelines to include what some of the key criteria are aiming for or why:
\nI encourage you to check out all the success criteria, now that you are more confident in understanding the guidelines within the first principle. If that page still looks too intimidating, try reading How to Meet WCAG, which is more approachable and provides clearer techniques that help you visualize how to meaningfully apply what you've learned.
\nRegardless of how you take your next steps, I hope you are less afraid to dive into WCAG documentation and its supplemental materials and guides to help you understand web accessibility. Despite all the technical specs, take a moment to sit back and empathize with people who have different levels of abilities than your own. Ask yourself, "How could my website prevent a person with a visual, hearing, physical, or cognitive impairment from entering in and walking away with what they came for?" In the end, it's the empathizing and relating to your wider audience that will make your accessibility efforts a success, rather than all the vast technical memorization and compliance, in which you devoted your time.
\nThis is Day 5 of my 100 Days of Accessibility journey to learn all things web accessibility. The best way I keep information in my brain is to share with others, so I spent my "study" time today writing this post, so that I could better assimilate the information in a more permanent way, while offering you a step forward into understanding web accessibility a little better.
\nIf you're trying to learn more about web accessibility, you don't have to do anything as extravagant or dramatic as I'm doing. Today I just discovered Learning A11y, which provides a list of resources to help you get started learning. We're all headed for the same destination here, but our learning styles and journey may vary.
\n", "date_published": "2018-12-05T05:14:00Z" },{ "id": "https://100daysofa11y.com/2018/12/03/day-4-wcag-operable/", "url": "https://100daysofa11y.com/2018/12/03/day-4-wcag-operable/", "title": "Day 4: WCAG Operable", "content_html": "Moving onto the second WCAG principle: Operable! 1.5 hours dedicated to studying today.
\nThough I'm only two principles into WCAG, I'm actually surprised how much I already know and have applied in my web design/development work over the last 5 years. It goes to show that the best way to learn this stuff is working with others who know it, apply it, and care about it. It also hasn't hurt to lurk in conversations about web accessibility on Twitter, Slack, and listserv emails. Those two factors have helped me advance forward, alongside the fact that I have close friends and family with various disabilities, who have helped me relate to the challenges many people face when navigating online.
\n", "date_published": "2018-12-04T05:16:00Z" },{ "id": "https://100daysofa11y.com/2018/12/02/day-3-wcag-perceivable-part-2/", "url": "https://100daysofa11y.com/2018/12/02/day-3-wcag-perceivable-part-2/", "title": "Day 3: WCAG Perceivable, Part 2", "content_html": "Time spent studying today: 1 hour. Again, another weekend day that I successfully allotted time for study. I've been through three rounds of 100 Days of Code, a 9-month course on Udacity, and one round of 100 Days of A11y. I'm no stranger to dedicating time, figuring out a process, and sacrificing blocks of time I could've spent with family. However, I've seen what I can accomplish and how I can progress, so that gives me some confidence in continuing to put time aside to prepare in-depth for this challenging exam.
\n9 out of the 29 success criteria in the first WCAG principle are Level A. It's like reading, "these are just the basics, folks, which gets you almost a third of the way there". Yet if they're so basic, why aren't all web designers and developers trained to meet the bare minimum to create websites that are better for everyone? Is it really so much to ask for alternative text for images, captions for video, or volume controls for audio?
\nOther new-to-me tidbits:
\nDay 2... a weekend day, which can make it harder to make time to set aside for studying. I did it, though, spending roughly an hour and a half working through documentation, mulling over only part of the first WCAG principle, and working toward visualizing the different guidelines, success criterion, and techniques. I didn't get as far as I would've liked either, yet this is the deepest work I've ever done at combing through the WCAG docs.
\nIn the process of trying to memorize guidelines and success criterion, I reinforced the image of the layers that exist within WCAG:
\nAdditionally, looking closer at each criterion helped me to identify the additions made to WCAG 2.0's first principle:
\nWhen reading through the description about text alternatives, I ran across a concept new to me: "simpler language" is considered a text alternative under Guideline 1.1. Also, there are some identified exceptions to the text alternative guideline. Those exceptions apply to:
\nAnd here I go! To start off my journey to earn my Web Accessibility Specialist certification, I had to get myself in gear, get organized, and just start.
\n![\"Pyramid](\"https://100daysofa11y.com/img/wcag-pyramid.png\")
The more that you read, the more things you will know. The more that you learn, the more places you'll go.”\n
— Dr. Seuss, I Can Read With My Eyes Shut!
\nThanks for coming! I'm here to learn web accessibility at a greater depth, so that I can become a Web Accessibility Specialist. In 100 days I plan to be (mostly) prepared for IAAP's Web Accessibility Specialist certification exam. Along the way, I'd like to share with you what I learn each day.
\nJoin me on my journey to learn about all things web accessibility from W3C documentation to user stories.
\n", "date_published": "2018-11-30T15:31:00Z" } ] }