Day 87: Guidelines, Laws, and Myths

My intention today was to complete the first Deque course within the WAS certification prep program. I did do that, but not without being led to more resources that I need to read through. I’ve done a little research into US laws, but I need to read them again, plus read other laws mentioned in what I reviewed today. Looks like tomorrow’s study session is laid out for me.

Thing I accomplished

Completed guidelines, laws, and myths sections of Deque’s Accessibility Fundamentals.

What I reviewed today

Guidelines

Principles, guidelines, and authoring practices help create an accessible interaction between user and website or application. These guidelines and practices ensure that a variety of disabilities are taken into consideration.

I covered these more in detail on my own, which I’ve journalled on this site, but Deque does a decent job of getting the learner started with the basic principles and guidelines, and points them to official specifications. I’ll admit, I need to go back and spend some serious review time to go over all these.

Laws

Web accessibility laws usually fit into one of the following categories:

  • civil rights: discrimination against disabilities (Americans with Disabilities Act)
  • procurement: purchasing accessible IT products (Section 508 of the Rehabilitation Act)
  • industry-specific: regulations for private industries (21st Century Communications and Video Accessibility Act, Air Carrier Access Act)

United States

Canada

Europe

Other Regions

The Web Accessibility Initiative (WAI) has a comprehensive list of international accessibility policies. Additionally, PowerMapper has a list of government accessibility standards.

Myths and Misconceptions about Accessibility

  1. It benefits only a small minority. Truth: It actually benefits everyone.
  2. It’s a short-term project. Truth: It’s on-going.
  3. It should be the last step. Truth: It needs to start at the beginning of the project and last throughout the project’s life cycle.
  4. It’s hard & expensive. Truth: Remediation is harder and more expensive than considering it throughout the life cycle.
  5. It’s ugly. Truth: Most accessibility features are not visible to everyone.

Best takeaway

“Inaccessible web sites are not just inconvenient for people with disabilities, they are blocking.”

Day 47: ARIA Live Regions, Part 2

Yesterday during my Part 1 learning, I watched videos that gave me a great idea of how live regions worked. Today I looked over documentation to see what W3C had to say about it.

Things I accomplished

Read the WAI-ARIA documented parts on:

What I learned today

  • The politeness value of aria-live is just a strong suggestion to user agents and AT, but may be overridden by user agents, AT, or the user.
  • Some ARIA roles (i.e. log, status) already have default aria-live politeness levels (implicit value for role) when aria-live is not set.
  • aria-relevant indicates what notifications the user agent will trigger when the accessibility tree within a live region is modified.
  • aria-relevant values include:
    • additions
    • additions text
    • all
    • removals
    • text
  • aria-busy is a state, not a property.
  • aria-busy exists to indicate an element is being modified and that AT may want to wait until the modifications are complete before showing them to the user.

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

Watched:

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 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 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 17: ARIA Authoring Practices

Today I quickly went through the ARIA Authoring Practices 1.1, a W3C Working Group Note included in the ARIA suite of documentation. Though I found the WAI-ARIA 1.1 spec a bit hard to retain, this additional “note” helped me see some real-life application of the ARIA spec. It’s definitely something I’d recommend web developers bookmark when needing to refer to common pattern examples, use of landmark regions, and a how-to for developing a keyboard interface. It’s an informative resource best tapped into for specific information, rather than a document read from top to bottom.

Things I accomplished

What I learned today

There are a couple principles behind why using ARIA can be a challenge, and why sometimes it is better to not use ARIA rather than write bad ARIA:

  1. A role is a promise, so you better couple expected keyboard functionality with that role
  2. ARIA can both cloak and enhance, so use this power cautiously

This guide does not provide help on mobile and touch support. Apparently, ARIA is not consistently supported in mobile browsers. On that note, if you notice my resource mentioned at the end of this post, ARIA isn’t consistently supported across screen readers (it’s only 70% reliable!), and varies even more depending on the browser the screen reader is paired with.

Concerning role=”presentation”, this role is ignored, if one of the following is true:

  • the element it is applied to is focusable (links or inputs)
  • the element it is applied to contains any of the 21 global states and properties.

Must-read resource