Day 49: Modal Completion

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

Thing I accomplished

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

What I learned today

The two things I hadn’t completed earlier involved:

  • not allowing the user to Tab outside of the modal, and
  • return focus back to the button that triggered the modal, once the modal is closed.

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


Day 46: ARIA Live Regions, Part 1

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.

Things I accomplished


Tried the ARIA Live Region Test (by Terrill Thompson) with VoiceOver on Safari.

What I learned today

  • The aria-live attribute is useful to update a screen reader user about changing content. It only reads the changed content.
  • The 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:
    • off (default)
    • polite (waits for user to finish what they’re doing)
    • assertive (interrupts user)
  • Other ARIA live regions include aria-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.

Day 41: Coding a Custom Modal

Thing I accomplished

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:

Note: 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.

What I learned today

What have I learned from this just in the hour I spent today?

  • Well, for one, I sure think a well-supported dialog HTML element sure would make my life a lot easier!
  • Making a checklist of what I needed to accomplish, based on expected keyboard interactions, really brought to light what needs to happen in the code.
  • Keeping a mindset of mobile-first and progressive enhancement can really benefit in these situation of creating custom widgets.
  • I was reminded that testing across browsers and platforms is important in this situation. I worked on my code from two different operating systems, same browser, and got different look and results my design and functionality.
  • Esc == keycode 27
  • Tab == keycode 9
  • position="fixed" worked better on one platform than position="absolute", when making the modal cover the entire screen.
  • If not for the people who coded and tested before me, I’m not sure if I’d be able to work through too many custom widgets for a website without them being inaccessible. Lots of love to the accessibility experts/coders out there!

Resources I leaned heavily on today

Day 39: Concepts Concerning Custom Modals

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.

Things I accomplished

What I learned today

  • I knew there was a dialog HTML element, but didn’t realize just how unequally supported it is across browsers. I see now why so many devs just use a div with ARIA role=”dialog” instead.
  • Once a dialog is opened, focus should immediately move inside the dialog, and an accessible name (aria-label, aria-labelledby, or aria-describedby) and dialog role should be announced.
  • When a dialog is open, the Tab key should not allow the user to get outside of the dialog box.
  • A user should be able to close the dialog with Esc, tapping outside the box, pressing a Close button, or even F6 (reaching the address bar).
  • When a dialog is closed, focus should return back to the element that initiated it.
  • Dialogs should be hidden with visibility:hidden.
  • Expected keyboard interactions within the dialog should be:
    • Tab: Moves focus forward inside the dialog
    • Shift + Tab: Moves focus backward inside the dialog
    • Escape: Closes the dialog

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.

Other articles I read today

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.