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.