All components in Modus are built with accessibility in mind. Studies estimate that about one fifth (20%) of the population has some kind of disability. Even though that number might be significantly lower for our users, keeping accessibility in mind is not only a good practice, but it also may have serious legal implications especially as it relates to government contracts.
Major categories of disabilities include visual, hearing, motor, and cognitive, with each category requiring a certain type of adaptation in the design of web and desktop products. For help with implementation, we include a checklist that you can add to the acceptance criteria.
All states (default, hover, focus) of active UI (e.g. not disabled buttons) and meaningful graphics (icons, charts, buttons) must meet 3:1 contrast ratio
(Exception) pure decoration
Changing the setting of any UI component does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time.
Navigations that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user
Components that have the same functionality within a set of web pages are identified consistently (e.g. all links look the same, all error messages are red)
When additional content is presented on hover or keyboard focus:
The newly revealed content can be dismissed (generally via the Esc key) without moving the pointer or keyboard focus, unless the content presents an input error or does not obscure or interfere with other page content.
The pointer can be moved to the new content without the content disappearing.
The new content must remain visible until the pointer or keyboard focus is moved away from the triggering control, the new content is dismissed, or the new content is no longer relevant.
Correct use of semantic HTML
Tables are used only for tabular data & data cells are associated with their headers
All code is standards-compliant
ARIA is used appropriately to enhance accessibility when HTML is not sufficient
Use the language attribute on the HTML element (<html lang="en">)
The language of page content that is in a different language is identified using the lang attribute
DOM (document object model) order must match visual order (i.e. code source)
Focusable components receive focus in visual order
Keyboard focus indicator is visible.
Provide alt tag for all images
A descriptive alt tag for informative images
A null alt tag (alt="") for decorative images
Alternative forms of CAPTCHA using output modes for different types of sensory perception are provided
Each web page must have a unique title that describes the page’s topic or purpose
A mechanism is available to bypass blocks of content that are repeated on multiple pages, such as
Adding links at the top of the page to each area of the content, and/or
Using ARIA landmarks to identify regions of a page, and/or
Providing heading elements (h1, h2, etc) at the beginning of each section of content
More than one way is available to locate a web page within a set of web pages, such as: sitemap, search.
(Exception) when the web page is the result of, or a step in, a process
If multipoint or path-based gestures (such as pinching, swiping, or dragging across the screen) are not essential to the functionality, then the functionality can also be performed with a single point activation (such as activating a button).
To help avoid inadvertent activation of controls, avoid non-essential down-event (e.g., onmousedown) activation when clicking, tapping, or long pressing the screen. Use onclick, onmouseup, or similar instead. If onmouseup (or similar) is used, you must provide a mechanism to abort or undo the action performed.
Functionality that is triggered by moving the device (such as shaking or panning a mobile device) or by user movement (such as waving to a camera) can be disabled and equivalent functionality is provided via standard controls like buttons.
Content that is updated dynamically (status messages) must be notified to users of assistive technologies (like screen readers) without getting visual focus. (Can use ARIA role=status)
All functionality is operable through the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g. free-hand drawing)
Keyboard focus is never locked or trapped at one particular page element
Page-specific shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts
Web pages do not contain anything that flashes more than three times in any one second
When a page element receives focus, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user
For each time limit that is set by the content, the user is given options to turn off, adjust, or extend that time limit
For any moving, blinking or scrolling information (e.g. background videos, carousels, animations) that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it. (Having motion stop only so long as a user has focus on it – where it restarts as soon as the user moves the focus away – would not be considered a “mechanism for the user to pause”)
For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, hide it, or control the frequency of the update.
