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