Day 38: Accessible Custom Widgets Overview

Published on 07 Jan 2019

• journal
• was
• aria
• techniques
• widgets

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.

• Read Marco Zehe's If you use the WAI-ARIA role "application", please do so wisely.
• Read Keyboard Interaction Accessibility Guidelines (Salesforce).
• Browsed Harvard's Online Accessibility Support Keyboard Accessibility page.
• Removed role="application" on one of my own CodePen projects.

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.

• Tab should focus on the widget; ▲/▼(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" (MDN) 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.

In Deborah Edwards-Oñoro'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.