Accessibility Checklist

Items in this checklist should be checked when applicable. For example, if an interface contains a form or an input control, then steps related to form fields should be checked. However, all items under the “General Guidelines” section should be followed as these steps relate to all interfaces.

The purpose of this checklist is to add to the formal peer review process done as part of the completion of an agile user story.

General Guidelines

• Is the accessibilityText attribute used consistently across UX components? The accessibilityText attribute doesn’t have to be present on every interface component. In some instances, the use of this attribute would be redundant, frustrating the user. It is, however, important that the attribute is used consistently throughout an application so that users know what to anticipate while using the application. The majority of Appian Interface Components, minus some of the layouts and layout element components, can make use of the accessibilityText attribute.

• Are heading levels appropriately set in section layouts? Using headings and making them visually apparent is especially helpful for users with cognitive disabilities. If the underlying SAIL in an interface is correct, screen reader users can also benefit from headings. Assistive technology like screen readers will list all of the headings, making it possible for users to skip to a desired heading to begin reading at that point.

• 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.

• Is content that is dynamically added to a page after a user action positioned in a logical order after the user's current perspective/location on the page? If the new content shows below the control (link or button) that is used to load dynamic content, users will be aware of the new content.

• Are contrast levels appropriate? Text and images of text should have a contrast ratio of at least 4.5:1, except for the following:

• Large-scale text and images of large-scale text should have a contrast ratio of at least 3:1.
• Incidental text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
• 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.

NOTE: Rich text with positive color 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. WebAIM Color Contrast Checker

Form Guidelines

• Does the layout component used within the form support a logical tabbing order when moving between form inputs? Side By Side Layout tabs left to right, whereas Columns Layout tabs top to bottom. For example, think of a form that contains inputs for ‘first name’, ‘last name’ and ‘email address.’ The logical tabbing order would go ‘first name’, ‘last name’ and then lastly ‘email address.’ Make sure the order of your fields and the layout component being used supports this.

• Do form fields have labels?

• Persistently visible labels must be provided for content that requires input. The interface will fail WCAG success criterion 3.3.2 if:

• Labels are not visible
• Field labels are hidden and placeholder text is used to provide a label for the input

• Do forms have instructions? Including instructions will provide a better user experience for all users. If it is possible to include instructions, it is highly recommended to do so.

• Do form fields that fail validation have error messages that identify the error and how to correct it? Validation messages should contain instructions on how to resolve the error. This is beneficial for all users.

• Do grouped form fields (e.g. radio buttons, checkboxes) have a group label defined? Within Appian the label attribute acts as the group label per the documentation for the Radio Button and Checkbox Components, basically what this means is don’t rely on the choice label(s) as the only label(s) so that we have an interface component that looks similar to these examples. 

• For form fields that gather specific information from users (name, email, phone number, street address, postal code, credit card number), is the correct input purpose value set/used? (this should be very low on the list because of limited use cases)

Grids Guidelines

• Do grids have column and row headers correctly defined where needed (possible)? For details on how to set headers correctly see the documentation for the Read-Only Grid and Editable Grid Components. 

Charts and Graph Guidelines

• Do non-stylistic icons and images used to convey information have a text equivalent? Relying on an image alone to provide information or context is a barrier to entry for a lot of people. A text equivalent can be added in Appian by using the accessibilityText attribute.

NOTE: images that are redundant to content already output, and images that are decorative (e.g. images used in links/buttons that already have link/button text that describes the purpose of the link/button) should be ignored by assistive technology. Text equivalents should only be provided when the image conveys information that is not already conveyed by another means.

• Is tabular data included with charts and graphs? Providing a text equivalent to images, charts, and other graphical content is a cornerstone of making a web application accessible. For charts, it’s especially important to provide the data in a grid format as some users will not be able to interact easily with, or understand complex data visualizations.

• Do your users know about the Accessibility Options built into the Appian platform which can make it easier to view and understand the data in charts? For users with low vision, there is an Accessibility option in User Settings where they can enable fill patterns on column, bar, and pie charts. For an accessible alternative, provide the data in a grid instead. See this recipe for an example.

• Does your application contain charts and graphs with drill downs? Some (not all) charts support navigation (drill downs) via mouse clicks and this capability is not available to users who rely exclusively on keyboard inputs.Work with your client to explain these limitations up front and work on an alternative approach if they determine one is needed.