The Appian platform allows designers to build applications that are accessible to all users, including those with disabilities who employ assistive technologies such as screen readers. In order to meet this goal, Appian validates its product features against the requirements of leading accessibility standards:
US Federal Government's Section 508 of the Rehabilitation Act of 1973 (January 2017 Refresh)
World Wide Web Consortium (W3C)'s Web Content Accessibility Guidelines (WCAG) 2.1 Level AA
Since each screen reader is optimized to work best with a particular browser, Appian recommends the following common combinations of browser and screen reader:
Accessibility feature in Appian's SAIL technology allow users with low vision, limited dexterity, and other concerns to consume the same information and perform the same activities as any other user of an application. Many of these capabilities are automatically enabled when using interfaces, while others are activated by making use of specific interface component configuration parameters. Accessibility-related configuration recommendations are described in detail on each interface component documentation page.
A small number of interface components, due to their specialized functionality, may not be accessible to all users.
The Reconcile Doc Extraction Smart Service generates a task for a user to validate the extracted data. This task requires users to visually inspect an image of a document to validate correct extraction of its contents. Therefore, this feature may not be usable for blind users or those with low vision. To learn more about this task, see Appian Document Extraction.
Browser components like the document browser, hierarchy tree, and org chart show a visual representation of object relationships, so they are not usable for blind users and may be difficult to use for users who have low vision.
For an accessible alternative, provide the data using grids or another screen reader friendly layout.
Rich text with positive styling does not meet WCAG color contrast requirements and may not be usable by users with low vision.
For an accessible alternative to positive styling, choose a custom green color such as
#1B890A that meets WCAG 2.1 AA contrast requirements for text.
Styled rich text items are not interpreted as HTML headings by screen readers. Rich text headers should be used to represent content sections in an accessible way.
The drawing pad on the Signature component is not keyboard accessible. A mouse or touchpad must be used to draw the signature.
The warn color option in gauge and progress bar does not meet WCAG color contrast requirements and may not be usable by users with low vision.
A faded version of the site object accent color is used as a hover style on certain components, such as dropdown menus and grids with row highlight. For better accessibility, test your accent color while hovering on dropdown menus and grids with row highlight to ensure they have adequate color contrast. The contrast ratio between the cell color and the text should be 4.5:1.
The row highlight selection style in the read-only grid and editable grid components uses color to indicate which row is selected. This information is not conveyed by screen readers, so it may not be usable by non-sighted users or those with low vision.
For an accessible alternative, use the checkbox selection style instead.
Building Accessible Applications