By: Kim Wee, Webmaster, Minnesota IT Services partnering with MN Department of Education and David Miller, Quality Assurance Lead, Minnesota IT Services partnering with MN Department of Corrections.

Editor’s note: This is the latest article in our series “WCAG 2.1 – Improving Digital Accessibility.” Missed the first installments? Use the #Accessibility tag on our blog page then search the page for WCAG 2.1. Subscribe to be sure you get each installment in this series! (The link is at the bottom of this page.)

This is a “quick dive” into two WCAG 2.1 success criteria – 2.1.4 Character Key Shortcuts and 2.5.3 Label in Name. The article is aimed at experienced developers who already have some familiarity with digital accessibility.

2.1.4 Character Key Shortcuts 

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

• Turn off - A mechanism is available to turn the shortcut off.
• Remap - A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt).
• Active only on focus - The keyboard shortcut for a user interface component is only active when that component has focus.

Examples and key messages

• Don't do single key shortcuts. It could interfere with assistive technology (AT) shortcuts. For example, a JAWS user using the "B" key to jump from button to button on the page.
• Ensure character-only shortcut keys can be turned off or modified.
• Be sure to test for single-key shortcut functionality when considering off-the-shelf software. If single-key shortcuts exist, the software must also provide a way to turn them off or remap them.
• Discoverability of keyboard shortcuts that are available for use.

How to

Provide a mechanism to allow users to remap or turn off character key shortcuts. 

Testing tools

• Keyboard-only testing of all characters.

Testing

• For each character key shortcut:
  • Determine if the user has the ability either to turn off the shortcut or to remap it to a combination that includes one or more modifier keys.
• An initial challenge for testers is to identify if author-created shortcuts exist, and then determine if existing shortcuts are triggered by character keys without modifiers. 
  • Where testers have access to the development team, the existence and nature of shortcut keys can often be determined by asking involved designers and developers. 
  • Where reliable information from the authors is not available, the presence of shortcuts can possibly be identified by checking code (for example, in JavaScript, the presence of keydown, keyup and keypress listeners).
  • Another means of identifying shortcuts is to review documentation. 
  • Where none of these strategies provide information on the presence of keyboard shortcuts, manual tests will need to be completed to search for the existence of character key shortcuts.

Training

• Search for training by qualified resources on:
  • Device-Independent User Input Methods.
  • WCAG Conformance Testing, Detailed Methodology.
• W3C Schools.

References

• Understanding character key shortcuts.

Barriers

• None.

2.5.3 Label in Name

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

A best practice is to have the text of the label at the start of the name.

Examples and key messages 

• The visual label for controls is a trigger for speech activation.
• Where practical, make the control’s text label and name match.
• The criteria have  potential for big impact on development across the work we do, including how we apply “accessible name” to elements such as buttons, links, etc. (for example, "edit" or "view" links/buttons in a table).
• Assistive technology uses the name to identify the control to the user. This means it can be programmatically determined and why it is often referred to as the accessible name. The accessible name is not related to the name attribute on input elements.
• Visually present the "label." 
• Where two strings cannot be grammatically or seamlessly combined using aria-labelledby, you can use aria-label to make a new name which includes the visible label. For example: ...end of news story. <a href="poor.html" aria-label="Read more about Insufficient link names">Read more</a>.
• Use aria-labelledby to concatenate generic link text with other information.
• The aria-label property affects assistive technology users in one of two ways, depending on the role of the element. When applied to an element with one of the roles that supports naming from child content, aria-label hides descendant content from assistive technology users and replaces it with the value of aria-label. However, when applied to nearly any other type of element, assistive technologies will render both the value of aria-label and the content of the element.
• Three principles of accessible name: 

1. All interactive elements must have an accessible name. 
2. An element can only have one accessible name. 
3. To be sure of the name, you must test with a screen reader or inspect the HTML.

How to

• Including the text of the visible label as part of the accessible name.
• Matching the accessible name to the visible label. 

Testing tools

• Dev Tools (browser).
• ANDI.
• Axe Dev Tools Extension.
• Browser accessibility tab to see the accessibility tree.

Testing

• For all controls with a visible label, check that:
  • The accessible name of the control contains the same letters in the same order as the visible label.
• For input controls:
  • Examine each input that has adjacent text which serves as its label.
  • For each input, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input, according to the accessible name computation.
  • For buttons, links, menus, and other non-input controls, examine each control that contains text which serves as its label.
  • For each non-input control, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input.

Training:

• Search for training by qualified resources on:
  • Device-Independent User Input Methods.
  • WCAG Conformance Testing, Detailed Methodology.
• W3C Schools.

References

• Accessible Name and Description Computation 1.1. 
• HTML Accessibility API Mappings 1.0.
• Using aria-labelledby or aria-label.

Barriers

• Title tag - for label (screen readers do not read this and it does not get picked up in the accessibility API of the browser).