Created by Grof, Richard, last modified on 2020-06-09

Quadient understands how important it is that its software and web experiences is accessible for everyone. Web accessibility is not a not feature but rather a design principle integrated with UX. It helps people access online services regardless of their situation, whether it is a disability, older technology or alternative devices (for example mobile phones).  As a result, good accessibility improves mediate content to a wider audience and search engine rankings.

 

    WCAG 2.0 Principles Related to Keyboard Accessibility

    Quadient is committed to complying with accessibility best practices based on WCAG AA,Section 508, and European standards. Quadient UI patterns are following WCAG 2.0 fundamental principles:

    • perceivable
    • operable
    • understandable to all users including support for assistive technology
    • robust

    Principle 1: Perceivable

    Information and user interface components must be presentable to users in ways they can perceive.

    • Visually impaired users must be able to receive information via sound or touch

    • Hearing-impaired users must be able to receive information via sight

    • Low vision users must be able to receive information with alternative formatting or zoomed to larger sizes

    • Color deficient users must be able to receive information without use of color

    Guideline Number

    Guideline

    How to Implement

    Guideline 1.3: 
    Adaptable

    "Create content that can be presented in different ways (for example simpler layout) without losing information or structure."







     1.3: Standards Compliant Markup
    Structural, semantic HTML is the key starting point toward good accessibility practices.
    The semantic markup and use of ARIA roles in our components are based on W3C standards and industry best practices.

    Principle 2: Operable

    User interface components and navigation must be operable

    • Functions triggered via mouse or gesture are also available via a keyboard

    • All users are given sufficient time to read and use content.

    • Content does not induce seizures.

    • Users are given mechanisms to skip repetitive content.

    • Landmarks are provided to assist in screenreader navigation (e.g. meaningful page title, semantic headings, ARIA landmarks) meaningful headings and meaningful and unique link text.

    • Multiple paths are provided to navigate Web site structure.


    Guideline Number

    Guideline

    How to Implement

    Guideline 2.1:
     Accessible  Keyboard

    "Make all functionality available from a keyboard."

    Tab keys can be used to be navigate between form fields and buttons.

    Guideline 2.1.2 No Keyboard Trap. 

    A “keyboard trap” occurs when a person who uses a keyboard cannot move focus away from an interactive element or control using the keyboard alone.

    The most common “Keyboard traps” found on the web today are a result of particular implementations of JavaScript functionality.  Specifically, if blur or any keypress events are used to enhance or override an element's behaviour Beware  event.preventDefault();
    https://www.w3.org/TR/WCAG20-TECHS/G21https://www.w3.org/TR/WCAG20-TECHS/G21

    Guideline 2.4: 
    Navigable

    "Provide ways to help users navigate, find content, and determine where they are.

    • HTML Frames are given meaningful titles

    • Users are given mechanisms to skip repetitive content.

    • Landmarks are provided to assist in screen reader navigation,
      e.g. meaningful page title, meaningful headings and meaningful and unique hyperlink text.

    • Multiple paths are provided to navigate through Web site content.

    • Keyboard users are able to see a cursor or other indicator of position on the screen.

    Principle 3: Understandable

    Information and the operation of user interface must be understandable.

    • Site is free of unannounced pop up windows.

    • Separate Submit or Go buttons/links are provided to initiate page changes (versus autosubmit upon selection).

    • Navigation and labels are consistent across a Web site or application.

    • Mechanisms are available to detect errors and provide clear instructions to users on fixing errors.

    • Language of text or subsection of text is identified.

    Principle 4: Robust

    Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

    Testing Common Keyboard Interactions

    Certain users navigate the internet using the keyboard rather than the mouse. Expert “power” users prefer keyboard commands for efficiency, while users with certain disabilities have no choice but to use the keyboard. Testing predictable order of interface by keyboard interactions is an essential part of accessibility evaluation. The Tab key can be used to navigate through links and form controls, Enter (and sometimes Spacebar) selects an element, and the arrow keys are sometimes used for other navigation. 


    Interaction

    Keystrokes

    Notes

    Navigate to most elements

    • Tab

    • Shift + Tab - navigate backward

    • Keyboard focus indicators must be present.

    • Navigation order should be logical and intuitive.

    Link

    Enter

    Button

    Enter or Spacebar

    Ensure elements with ARIA role="button" can be activated with both key commands.

    Checkbox

    Spacebar - check/uncheck a checkbox

    Checkboxes should be used when one or more option can be selected.

    Radio buttons

    • ↑/↓ or ←/→ - select an option.

    • Tab - move to the next element.

    Radio buttons should be used when only one option from a group can be selected.

    Select (dropdown) menu

    • ↑/↓ - navigate between menu options

    • Spacebar - expand

    You can also filter by typing letters, but this behavior varies by browser. Some will filter as you type, like autocomplete. Others will only sort by first letter. E.g., in a list of US States, hitting A then R may take you to Arizona, or it may take you to Alabama and then Rhode Island.

    Autocomplete

    • Type to begin filtering

    • ↑/↓ - navigate to an option

    • Enter - select an option

    Dialog

    Esc - close

    • Modal dialogs should maintain keyboard focus (see Modal dialogs).

    • Non-modal dialogs should close automatically when they lose focus.

    • When a dialog closes, focus should usually return to the element that opened the dialog.

    Slider

    • ↑/↓ or ←/→ - increase or decrease slider value

    • Home/End - beginning or end

    • For double-sliders (to set a range), Tab/Shift + Tab should toggle between each end.

    • In some sliders PageUp/PageDown can move by a larger increment (e.g., by 10).

    Menu bar

    • ↑/↓ - Previous/next menu option

    • Enter - expand the menu (optional) and select an option.

    • ←/→ - expand/collapse submenu

    • Not all menus should have these controls. Simpler menus should usually rely on Tab/Enter.

    Tab panel

    • Tab - once to navigate into the group of tabs and once to navigate out of the group of tabs

    • ↑/↓ or ←/→ - previous/next tab.

    • This is for 'application' tabs that change without loading a new page. If a menu looks like a group of tabs, but is actually a group of links to different pages, Tab and Enter are more appropriate.

    • The tab content should update automatically when pressing the arrow keys. You should not hit Enter to activate the tab.

    'Tree' menu

    • ↑/↓ - Navigate Previous/next menu option

    • ←/→ - expand/collapse submenu, move up/down one level.

    Scroll

    • ↑/↓ - scroll vertically

    • ←/→ - scroll horizontally

    • Spacebar/Shift + Spacebar - scroll by page

    Minimize horizontal scrolling.

    Common Accessibility Problems

    Keyboard Accessibility

    Sometimes it is not possible to avoid losing keyboard accessibility because semantics are not very good.
    Use  tabindex="0" to  to add " fake "  focus.  Element  with tabindex="0"  become focusable.  It places the element in the logical navigation flow as if it were a link on the page.

    Focus

    Elements in focus; links and form elements should have clear visual feedback and should therefore be defined  :hover,  :focus and avoid outline:0. 

    Hiding Content

    There are many instances where a visual design will require that not all content is shown at once. Do not use visibility:hidden or display:none, because they do hide content from screen-readers, rather use width:0px, height:0px or other 0 pixel sizing techniques.

    Forms

    • Forms elements should be  semantically grouped into logical blocks by <fieldset><legend>.

    • Forms elements should be linked or to be wrapped with label.

    • Labels should be never empty or placeholder should be used instead of label. If the design requires an empty label hide it with accessible hiding method.

    Resources

    Accessible Components - Find Inspiration in Well-designed Examples:

    Techniques for WCAG 2.0

    https://www.w3.org/TR/WCAG20-TECHS/
    WAI-ARIA Authoring Practices 1.1
    https://www.w3.org/TR/wai-aria-practices/
    Tools
    https://wave.webaim.org/toolbar/
    https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh
    https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb
    Checklists
    https://blog.marvelapp.com/accessibility-checklist-designers-developers/
    https://www.ibm.com/able/guidelines/ci162/accessibility_checklist.html

    Quick Checklist for Developers 

    • Is HTML semantic and well-structured, using lists, tables for data tables, buttons? Are groups using headings?

    • Are all interactive items accessible using keyboard in the expected order and without being trapped with consistently visible focus indicator? Double check by using keyboard test.

    • Are all form controls, links, page titles, frames, and headings meaningfully and uniquely labeled (e.g. not “click here”, but “the article on WCAG”; or not “Name” but “Your full name”)?

    • Are there any meaningful images? Is there a text equivalent? Images that are decorative (like an icon in front of a label in a button) can leave the alt value blank. 

    • Are there any diagrams or graphs? Are the key points explained in the text?

    • If custom controls/components have been implemented, have these been tested to assure that assistive technology recognizes name, role, state, and value (where applicable)?

    • Are there any audio-visuals? Can the key information be accessed in other ways?

    • Is color used to convey meaning? Check that there is another way to access the meaning.

    • Is there enough contrast between the text and the background? Our standard is contrast ratio of 4.5:1. Can text links be clearly understood without color?

    • Does the content render in a meaningful way and logical way when these are not active?

    • Are there any data tables used? Are there clear row and column headings?