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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s