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 45: More ARIA Roles Requirements

Today was a short day. I wanted to finish adding ARIA role requirements to my spreadsheet, then take a peek at the next section to plan for my current study week.

Things I accomplished

What I learned today

I was surprised that the timer role didn’t have any requirements but the accessible name. Maybe I thought there would be a required marker, of sorts, to read out as the time ticked down? It’s a subclass of the status role, and has 22 inherited states and properties. I haven’t created one myself, so there’s more to explore!

In case you missed it

This is a continuation from Day 44 where I consulted the WAI-ARIA docs about requirements that come along with each role.

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

Day 37: How Well Do Browsers Play with Assistive Technologies?

This week I’m moving into the WAS Body of Knowledge section “choose accessibility techniques that are well-supported”. Most of these topics I’ve had some experience with and even preached about myself. For instance, adhering to coding standards and building with progressive enhancement in mind are two concepts I firmly believe can eliminate a lot of problems. I also understand that testing across platforms, browsers, and assistive technologies is important in order to discover what unanticipated barriers might occur, despite coding to standard.

That being said, today I focused on learning about what combinations of browsers and assistive technologies have been tested to work the best together. I know a bit about screen reader and browser combinations, but I’m certain there is more to learn than the base knowledge I have.

Things I accomplished

What I learned today

Here’s what I learned:

  • VoiceOver (VO) on macOS works mostly well with Firefox, but VO used with Chrome has limited support. Naturally, VO works best with Safari.
  • On that note, only Talkback works the best with Chrome. Other screen readers experience limited support or some support with exceptions. Oddly enough, even ChromeVox has some exceptions.
  • Edge does not support Dragon or ZoomText, and yet Internet Explorer (IE) does. As a matter of fact, IE is recommended for use with these two technologies.
  • Edge has the most support (with exceptions) for Narrator.
  • JAWS has been recommended for a while to be used with IE, but Firefox is a second close as of recently.
  • NVDA still plays best with Firefox.
  • Firefox and IE differ in visual focus, so both should be tested for this.
  • Likewise, video and audio elements differ across browsers, so those should be tested across browsers, too.
  • IE and Firefox are the only browsers that support Flash and Java accessibility.
  • ChromeVox uses to DOM to access content for the listener, rather than other screen readers that access an accessibility API or combination of API and DOM.
  • Level Access has a wiki on iOS Accessibility Issues.
  • SAToGo is another screen reader that works on Windows.

One of my favorite resources is canisue.com when checking for support across browsers. Choice of elements can really matter in cases where IE doesn’t support all HTML5 elements, including dialog. This resource alone has taught me so much about browser support for standards as I’ve worked through projects. In this vein, HTML5 Accessibility is another useful site.

One thing to remember is that following standards (like WCAG) are your best bet. Aiming for specific AT or browser support is not a good approach since updates can be made and support between the two can change.

Note: when reading through the Level Access wiki about AT support by browsers, these were for most popular browsers. Other browsers like Opera were not mentioned.