Accessibility microinteractions: better user experience, happier developers
7 likes2,341 views
The document outlines a workflow aimed at enhancing accessibility in front-end development through clear guidelines and patterns for microinteractions, such as buttons, modals, and menus. It details keyboard interactions, ARIA roles, and properties to ensure components are accessible and usable. The collaborative process involves accessibility specialists and developers to create a consistent, enjoyable user experience while addressing challenges in speed and prior accessibility knowledge.
Accessibility microinteractions: better user experience, happier developers
- 1. Better user experience, happier developers Accessibility microinteractions AIDAN TIERNEY @AIDANA11Y ɱ
- 2. A workflow for accessibility specialist & development team ɱ
- 3. A front-end development style guide for accessibility
- 5. Patterns that repeat throughout the application
- 9. • Description of pattern • Screenshot • Keyboard interactions • ARIA roles, states, and properties • Code snippets • Examples • Resources - blog posts, tutorials Style Guide
- 12. Remember, today is about a workflow - don't sweat the technical details in the examples ȶ
- 13. Description A button is a widget that enables users to trigger an action or event, such as submitting a form, opening a dialog, canceling an action, or performing a delete operation. Button vs. link: a link navigates away from current context; a button triggers new content in same context. But there will be exceptions. Note: menu button and toggle button are unique patterns
- 14. Screenshot Ƕ Add to cart Subscribe
- 15. Keyboard Interactions When the button has focus: • Space activates the button. • Enter: Activates the button. Following button activation: • If activating the button opens a dialog, the focus moves inside the dialog. (see dialog pattern) • If activating the button closes a dialog, focus typically returns to the button that opened the dialog unless the function performed in the dialog context logically leads to a different element. • If activating the button does not dismiss the current context, then focus typically remains on the button after activation, e.g., an Apply or Recalculate button. • If the button action indicates a context change, such as move to next step in a wizard or add another search criteria, then it is often appropriate to move focus to the starting point for that action. You don’t need to read this now!
- 16. WAI-ARIA Roles, States, and Properties The button has role of button. The button has an accessible label. By default, the accessible name is computed from any text content inside the button element. However, it can also be provided with aria-labelledby or aria-label. If a description of the button's function is present, the button element has aria-describedby set to the ID of the element containing the description. When the action associated with a button is unavailable, the button has aria-disabled set to true. Also see: See menu button and toggle button You don’t need to read this now!
- 17. Code Snippets <div role="button" id="print"> Print Page </div> <a tabindex="0" role="button" id="alert1"> Show alert </a>
- 19. Resources Links vs. Buttons in Modern Web Applications - Marcy Sutton marcysutton.com/links-vs-buttons-in-modern- web-applications/ Links are not buttons. Neither are DIVs and SPANs - Karl Groves karlgroves.com/2013/05/14/links-are-not-buttons- neither-are-divs-and-spans/
- 21. Team identifies what it will work on - sprint planning
- 22. Accessibility specialist drafts guidance (spec) for new components or patterns
- 23. Review spec early in sprint Ȭ Development feedback Agree on behaviour
- 25. Development team starts to build components to this spec
- 27. Developers demo using keyboard and screen reader
- 28. Rework spec & modify code, if needed
- 30. Clarifications for Development or Users Update screen reader and other content to better explain patterns (e.g. hints, instructions, user guides)
- 32. QA tests against the detailed behaviour for each microinteraction
- 34. Description A modal is a window overlayed on either the primary window or another modal window designed to prompt the user to enter information or make a response. Sometimes called a dialog, these windows take and hold focus until closed or actioned. The window under a modal dialog is typically inert; users cannot interact with content outside the dialog window.
- 35. Screenshot
- 36. Keyboard Interactions Tab: Moves focus to the next focusable element inside the dialog. If focus is on the last element, moves focus to the first focusable element inside the dialog. Shift + Tab: Moves focus to the previous focusable element inside the dialog. If focus is on the first element, moves focus to the last focusable element inside the dialog. Escape: Closes the dialog. Note: • When a dialog opens, focus is typically set on the first focusable element. • When a dialog closes, focus returns to the element that had focus before the dialog was invoked. This is often the control that opened the dialog. You don’t need to read this now!
- 37. WAI-ARIA Roles, States, and Properties The element that serves as the dialog container has a role of dialog. The dialog has either: • The aria-labelledby property set to refer to the visible dialog title. • A label specified with aria-label. The aria-describedby property can be set on the element with the dialog role to indicate which element or elements in the dialog contain content that describes the primary purpose or message of the dialog. Specifying descriptive elements enables screen readers to announce the description along with the dialog title and initially focused element when the dialog opens. You don’t need to read this now!
- 38. Code Snippets <div role="dialog" aria-labelledby="dlgtitle"> <h1 id="dlgtitle"> Sign up to Newsletter</h1> <div> <label for="email">Email: </label> <input type="text" id="email" name="email"> <input type="button" value="Sign up"> </div> </div>
- 39. Examples Using ARIA role=dialog to implement a modal dialog box - W3C WAI w3.org/WAI/GL/wiki/ Using_ARIA_role%3Ddialog_to_implement_a_ modal_dialog_box
- 40. Resources Custom-Built Dialogs - Gez Lemon juicystudio.com/article/custom-built_dialogs.php Using the dialog role - MDN developer.mozilla.org/en-US/docs/Web/ Accessibility/ARIA/ARIA_Techniques/ Using_the_dialog_role
- 41. Let's try this out
- 42. Menu navigation - menubar w3.org/TR/wai-aria-practices-1.1/#menu
- 43. Description A menu that is visually persistent is a menubar. A menubar is typically horizontal and is often used to create a menu bar similar to those found near the top of the window in many desktop applications, offering the user quick access to a consistent set of commands.
- 44. Screenshot
- 45. Keyboard Interactions Enter: When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item. Otherwise, activates the item and closes the menu. Space: When focus is on a menuitemcheckbox, changes the state without closing the menu. When focus is on a menuitemradio that is not checked, without closing the menu, checks the focused menuitemradio and unchecks any other checked menuitemradio element in the same group. (Optional): When focus is on a menuitem that has a submenu, opens the submenu and places focus on its first item. (Optional): When focus is on a menuitem that does not have a submenu, activates the menuitem and closes the menu. Down Arrow: When focus is on a menuitem in a menubar, opens its submenu and places focus on the first item in the submenu. When focus is in a menu, moves focus to the next item, optionally wrapping from the last to the first. Up Arrow: When focus is in a menu, moves focus to the previous item, optionally wrapping from the first to the last. When focus is in a menubar, does nothing. Right Arrow: When focus is in a menubar, moves focus to the next item, optionally wrapping from the last to the first. When focus is in a menu and on a menuitem that has a submenu, opens the submenu and places focus on its first item. When focus is in a menu and on an item that does not have a submenu, performs the following 3 actions: Closes the submenu and any parent menus. Moves focus to the next menuitem in the menubar. Either: (Recommended) opens the submenu of that menuitem without moving focus into the submenu, or opens the submenu of that menuitem and places focus on the first item in the submenu. Note that if the menubar were not present, e.g., the menus were opened from a menubutton, Right Arrow would not do anything when focus is on an item that does not have a submenu. You don’t need to read this now!
- 46. Keyboard Interactions Left Arrow: When focus is in a menubar, moves focus to the previous item, optionally wrapping from the last to the first. When focus is in a submenu of an item in a menu, closes the submenu and returns focus to the parent menuitem. When focus is in a submenu of an item in a menubar, performs the following 3 actions: Closes the submenu. Moves focus to the previous menuitem in the menubar. Either: (Recommended) opens the submenu of that menuitem without moving focus into the submenu, or opens the submenu of that menuitem and places focus on the first item in the submenu. Home: If arrow key wrapping is not supported, moves focus to the first item in the current menu or menubar. End: If arrow key wrapping is not supported, moves focus to the last item in the current menu or menubar. Any key that corresponds to a printable character (Optional): Move focus to the next menu item in the current menu whose label begins with that printable character. Escape: Close the menu that contains focus and return focus to the element or context, e.g., menu button or parent menuitem, from which the menu was opened. Tab: Moves focus to the next element in the tab sequence, and if the item that had focus is not in a menubar, closes its menu and all open parent menu containers. Shift + Tab: Moves focus to the previous element in the tab sequence, and if the item that had focus is not in a menubar, closes its menu and all open parent menu containers. You don’t need to read this now!
- 47. WAI-ARIA Roles, States, and Properties A menu is a container of items that represent choices. The element serving as the menu has a role of either menu or menubar. The items contained in a menu are child elements of the containing menu or menubar and have any of the following roles: menuitem menuitemcheckbox menuitemradio One of the following approaches is used to enable scripts to move focus among items in a menu as described in 4.6 Keyboard Navigation Inside Components: The menu container has tabindex set to -1 or 0 and aria-activedescendant set to the ID of the focused item. Each item in the menu has tabindex set to -1, except in a menubar, where the first item has tabindex set to 0. If activating a menuitem opens a submenu, the menuitem has aria-haspopup set to true. When a menuitemcheckbox or menuitemradio is checked, aria-checked is set to true. When a menu item is disabled, aria-disabled is set to true. Items in a menu may be divided into groups by placing an element with a role of separator between groups. For example, this technique should be used when a menu contains a set of menuitemradio items. All separators should have aria-orientation consistent with the separator's orientation. NOTE If aria-owns is set on the menu container to include elements that are not DOM children of the container, those elements will appear in the reading order in the sequence they are referenced and after any items that are DOM children. Scripts that manage focus need to ensure the visual focus order matches this assistive technology reading order. You don’t need to read this now!
- 49. Microinteration workflow Collaboration: Accessibility Specialist & Development team Accessibility Pattern/Style Guide: Detailed, testable and achievable requirements Best suited to large iterative projects. Developers demo they've met requirements: Solve for problems together (it's not a test)
- 50. Benefits Consistent user experience Shift left - should reduce defects in builds Subsequent projects can use or modify the specs Teams like to know 'how its supposed to work'
- 51. Challenges Speed: Early sprints have a lot of new patterns. Keeping ahead of the developers. Best when UX and Design patterns clear. Teams with no accessibility experience. Workflow is for efficiency, not for teaching Accessibility 101. Screen reader logistics and skills.
- 52. “What questions or comments do you have?” ɳ
- 53. Better user experience, happier developers Accessibility microinteractions AIDAN TIERNEY @AIDANA11Y ɱ