Accessibility

VOSS Automate supports Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. A full Voluntary Product Accessibility Template (VPAT) report is available from your VOSS account team.

The table provides examples of features in Automate that are assessed for accessibility to support users with disabilities, including those who require assistive technologies, such as users who are unable to use a mouse, or those who are visually impaired:

Setting	Description
Title display in the browser	When choosing a menu option in the Admin Portal, the title displays in the browser to give screen reader users an overview of the page and to help them to move between open pages in their browser.
Buttons and images have alternative text	Buttons and images have accessible names and can be read by screen readers. For example, paginator buttons that allow a user to navigate to the first, next, previous, and last page on a form. The alternative text displays when the mouse pointer hovers over an image. Visually impaired users who are using screen readers can hear the alternative text read out. Users who have turned off images to speed up downloads or to save bandwidth can view the alternative text.
Heading elements appear in a sequentially-descending order	Headings are properly ordered and do not skip levels. This conveys the semantic structure of the page, making it easier to navigate and understand when using assistive technologies. For example, the Login page contains a level-one heading, and landmarks for the logo, input fields, and labels.
Elements meet minimum color contrast ratio thresholds and can be changed	Low-contrast text is difficult or impossible for many users to read. While some people need high contrast, for others, bright colors (high luminance) are not readable. A Chrome plugin can be installed (on the Chrome browser), which allows the user to change the default colors on a page.
Zoom capability	VOSS Automate supports zooming without losing any information or functionality.
Keyboard access and alternative visual focus	Many people cannot use a mouse and rely on the keyboard to interact with the Web. People who are blind and some sighted people with mobility impairments rely on the keyboard or on assistive technologies and strategies that rely on keyboard commands, such as voice input. In a browser that supports keyboard navigation with the Tab key (for example, Firefox, IE, Chrome, and Safari): Click in the address bar, then put your mouse aside and do not use it. Press the ‘Tab’ key to move through the elements on the page. To move within elements such as select boxes or menu bars, press the arrow keys. To select a specific item within an element such as a drop-down list, press the Enter key or Spacebar.
ARIA roles have allowable attributes	Children of ARIA roles, such as form arrays, panel title bars, and tabs, are announced Landmarks and IDs are unique Table headers have text labels that are visible to screen readers Interactive controls are not nested Toggle fields have accessible names, for example, Element: List checkbox

Setting	Description
Dynamic forms	All buttons, including those used for pagination on dynamic forms, have discernible text labels that can be read by a screen reader Links with the same name have a similar purpose to facilitate keyboard navigation and the use of screen readers
Breadcrumb navigation elements	Breadcrumbs have machine-readable labels to allow those using assistive technologies to understand the site structure, to facilitate navigation, and to provide context for their current location.
Pop-up dialogs	Form elements have accessible labels that properly identify the element, for example, a screen reader is able to announce a Close button as well as the header and content text on Confirmation dialogs and other messages, and on Search and Hierarchy pop-ups. Relationships between parent/child elements can be determined, for example, in the hierarchy tree.