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 44: ARIA Roles Have Requirements

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!

Things I accomplished

What I learned today

Requirements for roles used in interactive controls, found in the WAI-ARIA docs, include:

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.

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

Day 43: Quick Look over Accordion Keyboard Interactions

Another sick day, so I spent 30 minutes looking over information about a custom accordions.

Thing I accomplished

What I learned today

Expected keyboard interactions with accordion headers include:

  • Enter or Space: With focus on the header, collapses or expands panel
  • Tab: Moves focus to the next focusable element; includes the entire page
  • Down Arrow or Up Arrow (Optional): Moves focus to next or previous accordion header
  • Home (Optional): Moves focus to the first accordion header
  • End (Optional): Moves focus to the last accordion header

It was interesting to me to see WAI’s code example made use of dl, dt, dd, and button within the accordion. Progressive enhancement!

Day 42: Researching Custom Menus

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.

Things I accomplished

What I learned today

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

Today I looked over a custom menu with submenu items that open when interacted with. A few things I learned:

  • W3C has 3 examples of menus that can be considered accessible.
    • The navigation menu item with subitems can be coded as an anchor link with a list of links underneath,
    • Action menus can be coded as buttons, and actions within the menu can be focused with .focus() or aria-activedescendent.
  • Expected keyboard interactions for menus with focus on the button include:
    • Enter orĀ Spacebar: opens the menu and places focus on the first menu item.
    • (Optional) Down or Up Arrows: opens the menu and moves focus to the first or last menu item.
  • Keyboard behaviors needed after the menu is open are described in separate widget documentation: 3.14 Menu or Menu bar.

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 38: Accessible Custom Widgets Overview

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

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

Things I accomplished

In review

What I learned through researching accessible interactive content, I need to:

  • manage focus
  • use semantic HTML
  • keep content perceivable at all times
  • create device-independent events
  • consider DOM order when adding content dynamically
  • simplify events

Basic keyboard interactions with a webpage:

  • Tab navigates to next focusable element
  • Shift+Tab navigates to previous focusable element
  • Arrows navigate between related radio buttons, menu items, or widget items
  • Enter activates a link or button, or submits a form
  • Space activates a button or toggle
  • Esc closes menus, modals, and other popover variations

Remember… W3C has a thorough document on ARIA authoring practices, including an extensive section on Design Patterns and Widgets.

What I learned today

  • The Tab key should focus on the widget; the arrow keys should navigate within the widget.
  • When a custom role is assigned to an element, the custom role completely overrides the native role.
  • When creating ARIA widgets, pay attention to the semantic structure of the roles. Some roles have required parent or child roles, or required attributes.
  • Role=”application” should be used sparingly. It overrides many AT keystrokes, such as ones that allow screen reader users to navigate by headings, landmarks, and tables.
  • A screen reader has two modes it uses to access a website:
    • focus mode
    • browse mode
  • Some of the MDN docs about ARIA share vital information about keyboard interaction, available states and properties, and effects on assistive technologies.

Related resource of the day

In Deborah Edwards-Onoro’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.”