Day 31: A11y throughout a Product’s Lifecycle, Waterfall vs. Agile

Moving onto the next WAS Body of Knowledge study topic: integrating accessibility into the quality assurance process. Approximate study time: 1 hour.

Things I accomplished

What I learned today

Considering accessibility shouldn’t just happen at the mockup or code level. It can happen throughout the product’s entire life:

  • concept,
  • requirements,
  • design,
  • prototyping,
  • development,
  • quality assurance,
  • user testing, and
  • regression testing.

Additionally, I read about the agile and waterfall processes and when to apply accessibility when working through the cycle:

  • waterfall approach: present throughout each step and is well documented
  • agile approach: discussed at scrum meeting, established as a requirement, built into design and architecture, use standardized testing with TDD and automation

Love this statement by Karl Groves which nails it when it comes to encouraging the development of an accessible product rather than blockading it:

“Become a member of the team, not a gatekeeper, and you will be seen as a resource instead of a hurdle.”

Day 30: Reminders of the Who, Why, and How of A11y

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.

Spending an hour of my time today, I used IAAP’s Prepare for WAS online resources list to get me started.

Things I accomplished

What I learned today

  • Access to information and communications technologies, including the Web, is defined as a basic human right in the United Nations Convention on the Rights of Persons with Disabilities (UN CRPD).
  • Accessibility really involves the cooperative of several moving parts for it to work:
    • content
    • user agents (browsers, media players, etc)
    • assistive technology
    • user knowledge and experience
    • developers, designers, content creators
    • authoring tools, and
    • evaluation tools.
  • I’m very familiar with assistive technologies when it comes to users being able to access websites. However, learning about adaptive strategies was new to me, though it rang true. Adaptive strategies include increasing mouse size, turning on captions, and reducing mouse speed. These techniques are usually how a user adapt with more mainstream technology.

Day 29: Making Dynamic Content Perceivable

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

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

Thing I accomplished

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

What I learned today

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


Day 28: Accessible JavaScript Events

Today 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:

  1. there should be no more than one event assigned to an element (some exceptions may apply)
  2. create device-independent event handlers

Thing I accomplished

Searched for articles and videos pertaining to proper use of event handlers to optimize accessibility.

What I learned today

As 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:

  • onFocus
  • onBlur
  • onSelect
  • onChange
  • onClick (when used with links or form elements)

The examples aforementioned are not unbreakable. Altering default behaviors can present problems.

While 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!


Day 27: Managing Focus and Logical Order

Properly 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.

I learned a few things today that will not only make me a better accessibility specialist, but also a better developer.

Things I accomplished

What I learned today

  • There’s a ‘template’ HTML element for rendering content when called upon. Cool! Not supported by IE 11, of course.
  • JavaScript has a focus method to assist with focus on elements that do not naturally receive focus.
  • In the case of an SPA, don’t forget to change the page title alongside managing the focus of the pages element.
  • The position of the some “subscribe to newsletter” components can be problematic if not positioned appropriately in the DOM. I had to quickly evaluate this site, and was relieved that it didn’t have that problem.
  • Labeling (naming) techniques are not all treated equally. Importance is computed. In other words, if several techniques are combined, one could overwrite another. Examples of labels (names) that may overwrite one another, dependent upon importance:
    • aria-labelledby
    • aria-label
    • label
    • title
  • Reminder: not every person who uses a screen reader is a keyboard user; likewise, not every keyboard user is a person who uses a screen reader.


Day 26: Use JavaScript Appropriately (and For Good)

Study 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.

Things I accomplished

What I learned today

  • Using languages appropriately is not only good practice, but also good accessibility. CSS was meant for visual design, and using it to make content dynamic can break accessibility. The same goes for JavaScript when used beyond what it was intended for. JavaScript is great for updating content, but server-side scripting should be used to help increase accessibility, security, and progressive enhancement, especially when it comes to implementing forms.
  • Discovered Nomensa has a YouTube channel with some very helpful videos about web accessibility. It’s only within the past month that I’ve learned about Nomensa.
  • Automatically submitting a form ‘onchange’ is stripping control from the user. Giving a user control of form submission is helpful to users with assistive technology, and anyone who may get confused about the sudden information update on the page.

The following ideas were not new to me, yet I appreciated the reminders, especially in context of web accessibility (not just usability):

  • JavaScript should be an enhancement, therefore, enhancing the experience and not being obtrusive to every user.
  • This quote really speaks to me, not just about JavaScript, but about accessibility in general. That’s why WCAG principles, guidelines, and success criteria were set in place. So that all designers, developer, etc. can understand the why and how of accessibility. “You can paint a picture with a paint-by-numbers kit, but you will have trouble explaining how the harmonies of the picture were achieved and if there is a special meaning in the use of a certain color.” – Christian Heilmann
  • I should pin this up in my cubicle: “The browser, its settings, and its functionality belong to the visitor, and are not yours to dictate or remove.” – Christian Heilmann
  • Essential markup should not rely on JavaScript. This feels like a hard lesson in 2018 with all our fancy web apps. Going back to my first bullet point, I can be reminded that using each language for what it was intended to do can help overcome this challenge. Ask yourself, “Does this script help visitors to reach a goal faster or overcome a problem, or is it just there because it is flashy or trendy?”
  • Take caution when you’ve about to break convention. You may be breaking a solid user experience, too.

Day 25: Introduction to Accessible JavaScript

Continuing 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:

  • Manage focus
  • Use semantic HTML
  • Keep content and its changes perceivable
  • Create device-independent event handlers
  • Consider DOM order when adding new content dynamically, and
  • Simplify events.

However, 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.

All 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.

Things I accomplished

I 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.

What I learned today

  • JavaScript is not inherently good or evil. Dependent upon the programmer, the use of JavaScript can create barriers or improve accessibility.
  • WCAG 2.0 requires that JavaScript, when enabled, must be accessible.
  • The Enter key doesn’t always trigger an onClick event if used on an non-link or non-control element (i.e. a div element). In those cases, the Enter or Spacebar will have to be detected for interaction.


Day 24: Better VoiceOver Practice

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.

Things I accomplished

  • Walked through all 22 steps of the built-in VoiceOver Quick Start tutorial.
  • Read Chapter 1, 2, and 6 of Apple’s VoiceOver Getting Started Guide.
  • Added keyboard shortcuts to my study spreadsheet.

What I learned today

  • VO has a Trackpad Commander option. This meant that I could use some of the same gestures on my MacBook Pro (MPB) trackpad that I use on my iPhone! This was an important discovery for me, offering me cross-device ease of use.
  • Control + Option + Spacebar selects my choice for interactive components like checkboxes, radio buttons, buttons, etc.
  • I finally got the hang of stepping in and out of different components and windows by using Control + Option + Shift + up/down arrows. For some reason, my brain struggled with this yesterday.
  • Control + Option + D gets me quickly into the dock of my MBP.
  • Control + Option + M goes directly to my MBP menu.
  • Control + Option + K opens keyboard help. When open this will explain what keys do when a key is pressed while holding down the Control + Option keys.
  • Control + Option + H + H opens up a Command help dialog, which lists all the different keyboard shortcuts for specific commands and tasks.
  • Web Spots is a generated list of areas of the current webpage based on VoiceOver’s interpretation of the page’s visual design.
  • Control + Option + ; (semi-colon key) locks the VO modifier keys so you don’t have to keep holding them for shortcut commands. This was a big deal to learn! It seemed ridiculous to keep holding down 2-4 keys at a time while pressing another key.
  • Control + Option + Shift + I creates a verbal overview of the page, including how many headers, links, landmarks, etc.

Day 23: VoiceOver for macOS

Needing 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!

Things I accomplished

What I learned today

  • I surprised myself be feeling more out of water on my MBP then I did with my iPhone when using VoiceOver. I’ve become fairly familiar with NVDA on Windows, so I really felt like I was having to relearn navigating with a screen reader.
  • Control + Option + U opens the rotor.
  • Sometimes using VO felt complex when having to hold down 4 keys to “quickly” navigate a webpage.

VoiceOver on macOS resources

Day 22: Implementing ATAG

Despite 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.

Thing I accomplished

What I learned today

There 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.

Resource unrelated to ATAG

I’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.

Day 21: ATAG Resources & WAI Vetting Process

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!

Things I accomplished

What I learned today

  • I’m learning something! My Part A and Part B posts, along with my study spreadsheet, all mirror what’s been written on the WAI website.
  • Learned the 5 milestones of WAI’s accessibility standard development process:
    1. working draft
    2. wide review working draft
    3. candidate recommendation
    4. proposed recommendation
    5. W3C recommendation (web standard)

ATAG Resources

W3C’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:

Additionally, W3C has their recommended specification and implementation notes:


Day 20: ATAG, Part B

Today 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.

Things I accomplished

What I learned today

  • Part B has 4 principles, 11 guidelines, and 32 success criteria.
  • The second major part of ATAG is intended to encourage support of the production of accessible content by the author in that:
    1. all automatically generated web content should be accessible (conforming to WCAG 2.0),
    2. authoring tools need to help authors in produce accessible content (conforming to WCAG 2.0),
    3. accessibility checks and repair options should be available to the author which identify accessibility problems that don’t conform to WCAG 2.0, and
    4. accessibility features should be prominent and documented for ease of use by the author.

Day 19: ATAG, Part A

The 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.

Things I accomplished

What I learned today

  • Part A has 4 principles, 13 guidelines, and 31 success criteria to follow.
  • If I’m using WCAG as a guide in all things web development, then following Part A of ATAG shouldn’t prove much harder. (“POU” out of “POUR” is literally present) More proof that digital accessibility is a mindset and not a checklist.
  • SC A.2.2.1 (Status Indicators) really opened my eyes to just how many visual indicators I have when creating a blog post! For instance, a red dotted underline to indicate a typo, a “Saved” text status in gray, or a number in a bubble next to my blog’s name to indicate that a draft is awaiting publication. So many things that could be missed if not made perceivable to assistive technology, like a screen reader.

Random share

Accessibility 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.

Day 18: Introduction to ATAG

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).

For 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.

This spec holds even more relevance for me as I continue to produce content for this site via WordPress.

Things I accomplished

What I learned today

There are two major parts of the ATAG spec:

  1. accessibility of authoring tool user interfaces to authors with disabilities, and
  2. support by authoring tools for the creation, by any author (not just those with disabilities), of web content that is more accessible to end users with disabilities.

ATAG 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!

The definition of “authoring tools” in the ATAG glossary lists of several avenues that I didn’t even consider at first sight. Those tools include:

  • WSYWIG HTML editors (Dreamweaver, TinyMCE)
  • software for editing source code (VS Code)
  • software that converts to HTML (“Save As HTML” in Office docs)
  • IDEs (Visual Studio)
  • software that generates web content on the basis of templates, scripts, command-line input or “wizard”-type processes
  • software that quickly updates portions of websites (Wikipedia)
  • content management systems (Drupal, WordPress)
  • email clients that use rich HTML (MS Outlook)
  • multimedia authoring tools (iMovie)
  • software for creating mobile apps

Extra reads


Day 17: ARIA Authoring Practices

Today 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.

Things I accomplished

What I learned today

There 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:

  1. A role is a promise, so you better couple expected keyboard functionality with that role
  2. ARIA can both cloak and enhance, so use this power cautiously

This 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.

Concerning role=”presentation”, this role is ignored, if one of the following is true:

  • the element it is applied to is focusable (links or inputs)
  • the element it is applied to contains any of the 21 global states and properties.

Must-read resource