Accessibility Checklist
Guidance for how to make your interfaces accessible
| Category | Success Criteria | How To Test |
|---|---|---|
| Form Inputs | Every enabled and disabled input MUST have a label set via the input label parameter. The label must accurately convey the purpose of the input. |
SAIL Testing: Inspect the label parameter for a value, it must not be null. Screen Reader Testing: Navigate to the input using the TAB or SHIFT + TAB keys. The screen reader must announce the field label. Tool Testing: • axe DevTools: Run a page scan. Works for all inputs except text and paragraph fields. Scan must be run in a browser, must not be run in Appian Designer. Possible errors: ARIA input fields must have an accessible name; Form elements must have labels • ARC Toolkit: Run the Interactive Controls or Custom Widgets test. Scan must be run in a browser, must not be run in Appian Designer. Possible errors: Invalid aria-labelledby; Input has no accessible name; Empty label text Manual DOM Inspection: What to check varies on the type of input. Check the value being used or referenced by the following: The string used for the aria-label attribute set on the input; A string contained in the node referenced by the ID used for the aria-labelledby attribute; OR the value contained in the <label> element that has a FOR attribute value set equal to the ID of the input. |
| Form Inputs | Placeholder text alone MUST NOT be used to convey important information for form inputs. | Visual inspection. |
| Form Inputs | Every input MUST have a persistently visible label (using placeholder text or currently selected values does not meet this requirement). Passes by default when the input uses a label parameter value and a labelPosition parameter value of any value other than COLLAPSED. |
Visual inspection. |
| Form Inputs | The label parameter value for each input MUST contain at least the same string used for the visible label. Passes by default when the input uses a label parameter value and a labelPosition parameter value of any value other than COLLAPSED. |
SAIL Testing: Inspect the label parameter value used for the input. If the label parameter uses a labelPosition of COLLAPSED, compare the value of the label parameter to the rich text used for the visual label.Screen Reader Testing: Navigate to the input using the TAB or SHIFT + TAB keys. The screen reader must announce a label for the input that includes at least the same string as the visible label. |
| Form Inputs | Duplicated controls having the same name in the same interface have additional context provided by accessibility text, icon altText, or other means. The context should indicate what content the input is associated with or performs an action on. Does not apply to controls output in grids. | Visual Inspection: Identify controls in the interface that use the same input label text, link text, button text, or single icon. SAIL Testing: Inspect the label and accessibilityText parameter values used for the inputs. If icons are used in the controls, inspect the altText and caption parameter values set on the icons. Screen Reader Testing: Navigate to the inputs/controls using the TAB or SHIFT + TAB keys, note if the screen reader announces the same name for each duplicated input/control. Put the screen reader into Browse mode and read any hidden content immediately prior to or after the input/control and note if the hidden content provides context for the input/control. |
| Form Inputs | Each individual checkbox and radio button MUST have a label set via the choiceLabels parameter. |
SAIL Testing: Inspect the choiceLabels parameter on a!checkboxfield or a!radioButtonField and ensure the labels do not use a null value.Screen Reader Testing: • Checkboxes: Navigate to the individual checkbox using the TAB or SHIFT + TAB keys • Radio Buttons: Use the Up or Down arrow key to navigate to additional radio buttons once the selected radio button receives keyboard focus via the TAB or SHIFT + TAB keys • The screen reader should announce the same name for each control that is output adjacent to the control Manual DOM Inspection: Locate the checkbox or radio button in the DOM. Inspect the <label> element used for the input. The <label> FOR attribute must match the ID of the checkbox or radio button and the value in the <label> element must not be null and must not equal "". |
| Form Inputs | Checkbox and radio button components MUST have a label parameter set when more than one checkbox or radio button is present in the group. |
SAIL Testing: Inspect the label parameter on a!checkboxField or a!radioButton field and ensure it has a value.Screen Reader Testing: • Checkboxes: Navigate to the first checkbox in the group using the TAB key or to the last checkbox in the group using the SHIFT + TAB keys • Radio buttons: Navigate to the currently selected radio button using the TAB or SHIFT + TAB keys. If no radio buttons are selected, use the same approach indicated above for checkboxes • The screen reader should announce the label value and identify the checkbox or radio button as being a "grouping" or "group" Manual DOM Inspection: • Checkboxes: Locate the element that has role="group" set on it • Radio buttons: Locate the element that has role="radiogroup" set on it • Locate the DOM node referenced by the ID used for the aria-labelledby attribute set on the element having role="group" or role="radiogroup". This DOM node must contain the label text. |
| Form Inputs | Text fields that accept PERSONAL information from the user MUST have the appropriate inputPurpose parameter set on the input. Note that the "Name" input purpose should only be used for a single input that accepts the user's entire name. | SAIL Testing: Inspect that the text field (a!textField) has an appropriate inputPurpose parameter value.Keyboard Testing: Navigate to the input using the TAB or SHIFT + TAB keys. A list with previously-supplied input values (that YOU have entered previously) should become visible when the input receives keyboard focus. Manual DOM Inspection: Ensure the input ( <input type="text">) has an appropriate autocomplete attribute value. |
| Validations | Inputs that are required MUST have the required parameter set to TRUE. | SAIL Testing: Ensure the input required attribute is set to TRUE. Screen Reader Testing: Navigate to the input using the TAB or SHIFT + TAB keys. The screen reader should announce "required" in addition to the input name, role, etc. Manual DOM Inspection: Ensure the input has aria-required="true" set on it. |
| Validations | OOTB validation MUST be used for all form input error messaging/validation. | SAIL Testing: Ensure the appropriate validations, validationGroup, and validationMessage parameters are set. Screen Reader Testing: Navigate to the input that has an error using the TAB or SHIFT + TAB keys. The screen reader should announce the visible error message text and the input as having an "invalid entry" when the input receives keyboard focus. Manual DOM Inspection: When an error is present, ensure the aria-describedby attribute set on the input references the ID of the DOM node that contains the visible error message. |
| Validations | The input name MUST be included in the error message text. The typical format is "[input name] requires a value.". | Visual inspection. |
| Instructions | The input instructions parameter MUST be used for visible form input instructions, expected formats, valid input ranges, etc. | SAIL Testing: Inspect the input instructions parameter and ensure it is set to the same value used for the instructions that appear on the screen. Screen Reader Testing: Navigate to the input using the TAB or SHIFT + TAB keys. The screen reader should announce the visible onscreen instructions when the input receives keyboard focus. Manual DOM Inspection: Ensure the aria-describedby attribute set on the input references the ID of the DOM node that contains the instructions. |
| Forms | Forms having required inputs that use an asterisk MUST have a visible legend at the beginning of the form prior to the first input. The typical format is "Required fields are marked with an asterisk (*)". | Visual inspection. |
| Forms | Keyboard focus MUST NOT be moved to a form input when the form initializes if there is important information positioned before the input. Set focusOnFirstInput=FALSE on the form. |
Visual Inspection: Identify important information at the beginning of or prior to the form and observe if focus is being moved to an input positioned after that information. Screen Reader Testing: When the form is initialized, the screen reader announces only the page title or dialog name, it does not announce the name of an input when there is important information presented prior to the input that receives keyboard focus. |
| Forms | Information that a user must re-enter to complete a wizard/milestone MUST be auto-populated or available for the user to select. | Visual inspection. Note any information that a user has entered in an earlier step in the process that must be re-entered in a later step. |
| Grids | Every grid MUST have a label set via the label parameter on the grid. The label can use a labelPosition of COLLAPSED if the grid is preceded by a visible heading that describes the content in or purpose of the grid. |
SAIL Testing: Inspect the label parameter on a!gridField and ensure it uses a value that summarizes or describes the content in the grid. Screen Reader Testing: Put the screen reader into Browse mode and navigate to the grid by pressing the T key (Windows screen readers) or VO + Command + T (VoiceOver). The screen reader should announce a value that summarizes or describes the content in the grid when the grid is navigated to. Manual DOM Inspection: Locate the <table> element. Ensure the DOM node referenced by the aria-labelledby attribute set on the <table> element contains the grid label text. |
| Grids | Each grid column that contains data or a single form input MUST have column header text. Columns that contain multiple controls such as an action menu, links that move rows up/down, download link, etc. do not need a column header as long as non-sighted users can understand the cell information based on the controls in the cell. | SAIL Testing: Inspect the label parameter on a!gridColumn for each column in the grid and ensure it is not null. Visual Inspection: Inspect the first cell at the top of each column for text. Screen Reader Testing: Using the screen reader table navigation keys, read each cell in a grid row using left or right cell navigation (CTRL + ALT + Left/Right arrow keys). Manual DOM Inspection: Examine each <th> tag within the <thead> tag and ensure they contain a value. |
| Grids | The grid row header MUST be defined using the rowHeader parameter when the content in the cell is unique and summarizes all content in the row. NOTE: Be careful with setting row headers on editable grids. All information associated with an input that is contained within the cell that is defined as the row header is announced by screen readers as part of the row header value, such as character counters, hidden instructions for operating dropdowns, etc. Setting the row header in this case must take into account how much information will be announced by the screen reader as grid cells are navigated. |
SAIL: Inspect the rowHeader parameter for a!gridField and ensure it is set to a numeric value (the position of the cell within the row). Screen Reader: Using the screen reader table navigation keys, navigate to any column to the right of the column that should have the row header set. Navigate cells in those columns up and down (CTRL + ALT + Up/Down arrow keys). The screen reader should announce the row header cell value prior to announcing the value in the cell currently navigated to. Manual DOM Inspection: Ensure the cell that should be defined as the row header is defined as a <tr> having scope="row" set on it. |
| Grids | Empty grid columns MUST NOT be used for spacing. | SAIL: Inspect each a!gridColumn or a!gridLayoutHeaderCell for a label value and valid value parameter setting. Screen Reader: Put the screen reader into Browse mode and navigate to the grid by pressing the T key (Windows screen readers) or VO + Command + T (VoiceOver). The screen reader should announce the same number of columns as are visible. Table navigation keys can also be used to navigate a grid row from left to right or right to left (CTRL + ALT + Left/Right arrow keys). The name of each column should be announced by the screen reader prior to any value in the cell that has been navigated to. Manual DOM Inspection: Ensure each <tr> used for column headers contains a text value. |
| Grids | Grid instructions MUST be associated with the grid using the grid instructions parameter. Do not use the word "grid" in instructions, use "table". | SAIL Testing: Inspect the grid for the instructions parameter. It should contain the same instruction text as the text output visually. Screen Reader Testing: Put the screen reader into Browse mode and navigate to the grid by pressing the T key (Windows screen readers) or VO + Command + T (VoiceOver). The screen reader should announce the instructions when the grid is navigated to. Manual DOM Inspection: Locate the <table> element. Ensure the DOM node ID referenced by the aria-describedby attribute set on the <table> element contains the instruction text. |
| Grids | Accessibility text MUST be set on the grid when controls above the grid become enabled based on grid row selections. Do not use the word "grid" in the accessibility text, use "table". | SAIL: Inspect the grid for the accessibilityText parameter. The parameter should contain text that indicates controls positioned above the table become enabled when rows are selected. The text should not indicate that the controls prior to the table become disabled when all rows are deselected. Screen Reader: Put the screen reader into Browse mode and navigate to the grid by pressing the T key (Windows screen readers) or VO + Command + T (VoiceOver). The screen reader should announce the accessibility text instructions when the grid is navigated to. Manual DOM Inspection: Locate the <table> element. Ensure the DOM node referenced by the aria-describedby attribute set on the <table> element contains the accessibility text. |
| Grids | Links used to move grid rows up and down MUST have a target size of at least 24 x 24 pixels OR when a 24 x 24 pixel circle is centered on each link, the circles do not intersect. Can be met by using 3 spaces between each link or buttons of any allowable size. | Testing Overview: There are two phases to testing. First, the target size of the links needs to be verified as being at least 24 x 24 pixels. If that test fails, then the spacing between the undersized targets needs to be verified. If both tests fail, then an accessibility failure is present. Phase 1 - Verify Target Size: • Open the browser DOM Inspect feature and select the active grid row ordering controls that are defined as links and are output adjacent to each other • Hover over the link anchor in the DOM explorer, producing the popup in the browser for the link, note the link size indicated in the popup (you must examine the link anchor size, not the icon) • If this test yields a link size smaller than 24 x 24 pixels, then proceed to Phase 2. Otherwise, there is no failure present Phase 2 - Verify Spacing: • Because of restrictions by Appian, this target size bookmarklet (https://cdpn.io/pen/debug/YzdwWZw) needs to be used to create a visual representation of the targets that overlap on a page • Install this bookmarklet and run it over the page. The bookmarklet will output 24 x 24 pixel circles on many elements on the page • Pay specific attention to the circles that are output over the grid row ordering links, and note if they overlap. An overlap indicates a failure of the requirement • Once the bookmarklet is run, refresh the browser to clear the onscreen results • NOTE: If the links are being tested within a dialog, the bookmarklet output will be present in the parent page that spawned the dialog, positioned exactly where the links were present in the dialog |
| Grids | Grid row drag and drop MUST also use a single-click alternative such as links that allow the row to be moved up or down by activating the link (applies to editable grids only). | Visual inspection. |
| Headings | Text headings MUST be defined as semantic headings using the Heading component. | SAIL Testing: Verify the text is defined using a!HeadingField. Screen Reader Testing: Put the screen reader into Browse mode and navigate to the text by pressing the H key (Windows screen readers) or VO + Command + H (VoiceOver). The screen reader should identify the text as a heading in addition to announcing the heading text when the heading is navigated to. Manual DOM Inspection: Examine the text to determine if it is contained within an HTML heading tag (H1-H6). |
| Headings | Headings use appropriate heading levels set via the headingTag parameter that reflect the structure or importance of the content. |
SAIL: Verify the text is defined using a!HeadingField and uses an appropriate headingTag parameter value. Screen Reader: Put the screen reader into Browse mode and navigate to the text by pressing the H key (Windows screen readers) or VO + Command + H (VoiceOver). The screen reader should identify the text as a heading and indicate the appropriate heading level, in addition to announcing the heading text when the heading is navigated to. Manual DOM Inspection: Examine the text to determine if it uses the correct HTML heading tag (H1-H6). |
| Lists | Text and other elements that are output as list items using visual styling (bullets, checkmark icons, or other notation) MUST be defined as semantic lists using Use a!richTextBulletedList or a!richTextNumberedList (excludes navigation links). |
SAIL Testing: Ensure a!richTextDisplayField is used, and ensure the list is defined using a!richTextBulletedList or a!richTextNumberedList (a!styledTextEditorField does not expose parameters for values provided).Screen Reader Testing: Put the screen reader into Browse mode and navigate to the text by pressing the L key (Windows screen readers) or VO + Command + X (VoiceOver). The screen reader should identify the area as a list and may or may not identify how many items are in the list. List items may be read one at a time with Browse mode. Some screen readers will identify the position within the list (e.g. "item 3 of 7"). All screen readers will announce that the list is being exited when navigating out of the list. Manual DOM Inspection: Examine the text and ensure it is contained with <ul>/<li> or <ol>/<li> markup. |
| Modal Dialog | Keyboard focus MUST NOT be moved to a form input when a modal dialog opens if there is important information positioned before the form input. Set focusOnFirstInput=FALSE on the form. |
Visual inspection. Identify important information at the beginning of or prior to the form and observe if focus is being moved to an input positioned after that information. Screen Reader: When the dialog is initialized, the screen reader announces only the dialog name and identifies the dialog ("dialog"), it does not announce the name of an input when there is important information presented prior to the input that receives keyboard focus. Note that the dialog name is typically set to the name of the control that opened the dialog. |
| Pane Layout | Each pane layout MUST have a label set via accessibility text. Do not use the following terms in the accessibility text: pane, main, navigation, section, form, search, header, footer, article or region. | SAIL: Ensure the accessibilityText parameter is set on a!pane. Screen Reader: Put the screen reader into Browse mode and navigate to the text by pressing the R key (JAWS), D key (NVDA) or VO + Shift + Dwn Arrow/Up Arrow (or the Rotor can be used) (VoiceOver). The screen reader should identify the pane as a "region" or landmark and announce the name/title of the pane. ARC Toolkit: Run the Interactive Controls test. Panes without a label will have an error of "Invalid aria-labelledby". Run the test in a browser, do not run it in Appian Designer. Note that if a label was provided for the pane and then removed via designer, this test will not produce an error in this case. Manual DOM Inspection: Search the DOM for "region". On the resulting element having role="region", ensure the aria-labelledby attribute references the DOM node that contains the pane accessibility text value. |
| Section Layout | Each expandable section layout MUST have a label provided by the label parameter and use an appropriate labelHeadingTag parameter value to indicate the heading level. |
SAIL: Inspect the label parameter is set on a!sectionLayout. Inspect the labelHeadingTag parameter is set on a!sectionLayout. A value must be present for both parameters. Screen Reader: Put the screen reader into Browse mode and navigate to the section by pressing the H key (Windows screen readers) or VO + Command + H (VoiceOver). The screen reader should identify the section label text as a heading and announce the text. For expandable/collapsible sections, the text can be navigated to using the TAB or SHIFT + TAB keys. In this case the screen reader should identify a button, heading, and announce the section name/label. Manual DOM Inspection: Inspect the section label text and verify it is contained within heading markup (H1-H6). |
| Box Layout | Each expandable box layout MUST have a label provided by the label parameter and use an appropriate labelHeadingTag parameter value to indicate the heading level. |
SAIL: Inspect the label parameter is set on a!boxLayout. Inspect the labelHeadingTag parameter is set on a!boxLayout. Both parameters should have a value. Screen Reader: Put the screen reader into Browse mode and navigate to the box by pressing the H key (Windows screen readers) or VO + Command + H (VoiceOver). The screen reader should identify the box label text as a heading and announce the text. For expandable/collapseable boxes, the text can be navigated to using the TAB or SHIFT + TAB keys. In this case the screen reader should identify a button, heading, and announce the box name/label. Manual DOM Inspection: Inspect the section label text and verify it is contained within a <div> that has both role="heading" and the aria-level attribute set to the appropriate heading level. |
| Cards | Cards having a link set on the card MUST NOT contain other controls or inputs within the card. | SAIL: Ensure that if a link parameter value is provided for a!cardLayout that no other components within the card use a link, button, or any other input type. Screen Reader/Keyboard: Navigate to the card using the TAB key. Once the card has keyboard focus, press the TAB key again. Keyboard focus must not move to any other element inside of the card except to open a tooltip or caption. Manual DOM Inspection: Search for an element that has role="link" and tabindex="1" set on it. This element will use CSS classes beginning with the text "CardLayout". Examine the nodes within this element for active controls such as links, buttons, or other form inputs. |
| Cards | A label parameter value MUST NOT be used for a link that is set on a card. | SAIL: Ensure that if a link parameter value is provided for a!cardLayout that the label parameter value is null for the link. Screen Reader: Navigate to the card using the TAB key. The screen reader should announce "link" only once in addition to any other content within the card when the card receives keyboard focus. Manual DOM Inspection: Search for an element that has role="link" and tabindex="1" set on it. This element will use CSS classes beginning with the text "CardLayout". Ensure the first child node of this element is not an <a> tag. |
| Cards | When color or a decorative bar is used to indicate the card is the current selection, accessibility text of "Selected" MUST be set on the card. Cards that are not selected MUST NOT be indicated as such. | SAIL: Ensure the accessibilityText parameter on a!cardLayout is set to "Selected". Screen Reader: If the card has a link definition, navigate to the card link using the TAB or SHIFT + TAB keys. The screen reader should announce "Selected" in addition to all content within the card. If the card does not have a link definition, read the entire card using browse mode with the screen reader. The screen reader should announce "Selected" in addition to all content within the card. Manual DOM Inspection: Search for an element that has role="link" and tabindex="1" set on it. This element will use CSS classes beginning with the text "CardLayout". Ensure the LAST child node of this element contains the text "Selected". |
| Links | Links embedded in text MUST use a method other than only color to differentiate the link from the surrounding text, such as a persistent underline (linkStyle: INLINE), font style change, icon positioned after the link, OR have at least a 3:1 color contrast between the link text and the surrounding text. The link can also be repositioned on a new line where there is no text present on either side of the link. |
Visual inspection. SAIL: The linkStyle parameter on a!richTextItem is set to INLINE or other formatting is used to differentiate the link from the surrounding text. |
| Links | When color or styling is used to indicate a RICH TEXT link is currently selected, accessibility text of "Selected" MUST NOT be set on the link UNLESS the rich text does not contain an icon. If an icon is used, set the altText parameter value of "Selected" on the icon. Links that are not selected MUST NOT be indicated as such. Setting the accessibility text parameter on the rich text link should be used only as a last resort. |
SAIL: Inspect the component. If no icon is used in the link, check for the accessibilityText parameter value of "Selected" set on a!richTextDisplayField. If the link uses an icon, ensure the accessibilityText parameter is not set on a!richTextDisplayField and instead, the altText OR caption parameter value of "Selected" is set on the icon. Screen Reader: For active elements, navigate to the element using the TAB or SHIFT + TAB keys. For inactive elements, put the screen reader into Browse mode and read the content. Regardless of how the element is accessed, the screen reader should announce the element as being "Selected" in addition to any content used in the element. |
| Breadcrumbs | Breadcrumbs MUST use accessibility text to identify the breadcrumb and the current (last) page in the breadcrumb. | SAIL: Esnure that the accessibilityText parameter value is set on a!richTextDisplayField that indicates the element is a breadcrumb and includes identification of the current (last) page in the breadcrumb, e.g., "Breadcrumbs, corporate is the current page". Screen Reader: Put the screen reader into Browse mode and read the breadcrumb. The screen reader should identify the element as a breadcrumb and indicate the current page prior to announcing all elements within the breadcrumb. Depending on the configuration, it is also OK if the screen reader identifies the current page directly before announcing the current page value. Manual DOM Inspection: Search for the paragraph ( <p> tag) that contains the entire breadcrumb content. Traverse the DOM upward two <div> nodes and expand the second <div>. Verify that the text in the <span> contained in the second <div> contains text that indicates the element is a breadcrumb and indicates the current (last) page in the breadcrumb. |
| Progress Bar | Each progress bar MUST have a label defined by setting the label parameter on a!progressBarField. |
SAIL: Ensure a label parameter value is provided for a!progressBarField. Screen Reader: Read the progress bar using Browse mode. A name/label for the progress bar should be announced by the screen reader prior to announcing the value in the progress bar. axe DevTools: Run a page scan in a browser, do not run the scan in Appian Designer. If a label is not provided for the progress bar, the identified error is "ARIA progressbar nodes must have an accessible name". ARC Toolkit: Run the Interactive Controls test in a browser, do not run the test in Appian Designer. If a label is not provided for the progress bar, the identified error is "Invalid aria-labelledby". Manual DOM Inspection: Search for "progressbar". Ensure the DOM node referenced by the aria-labelledby attribute set on the element having role="progressbar" contains text. |
| File Upload | The file upload MUST have a label set via the label parameter on a!fileUploadField. |
SAIL: Ensure a label parameter value is provided for a!fileUploadField. Screen Reader: Navigate to the Upload button using the TAB or SHIFT + TAB keys. The screen reader should announce a name/label for the button in addition to "upload" and "drop files here". ARC Toolkit: Run the Interactive Controls test in a browser, do not run the test in Appian Designer. If a label is not provided for the file upload button, the identified error is "Invalid aria-describedby". Manual DOM Inspection: Search for the Upload button. Ensure the DOM node referenced by the aria-describedby attribute set on the button contains text. |
| File Upload | Visible instructions for file upload MUST be set via the instructions parameter on a!fileUploadField. |
SAIL: Ensure an instructions parameter value is provided for a!fileUploadField and it is set to the instruction text that is output on the screen. Screen Reader: Navigate to the Upload button using the TAB or SHIFT + TAB keys. The screen reader should announce the instructions in addition to a name/label for the button and "upload" and "drop files here". Manual DOM Inspection: Search for the Upload button. Ensure the DOM node referenced by the aria-describedby attribute set on the button contains the instruction text. This should be referenced by the second, space-delimited ID used by the aria-describedby attribute where the ID ends with the text "-instructions". |
| Signature | An alternative keyboard method of acquiring a signature or indicating acceptance MUST be provided for the Signature component. | Visual inspection. Use an alternative method such as an accessible checkbox, dropdown, third-party element such as DocuSign, etc. Values should not be defaulted. |
| Simulated Grid | Data that is visually output as a grid but does not use a grid MUST have accessibility text set on each grid cell that contains the column "header" text and row header text (if appropriate). | SAIL: Confirm there is an accessibilityText parameter value output as the first element in each "cell" that indicates what the visual "column header" is and the text of the cell used for the row header (if applicable). Screen Reader: Put the screen reader into Browse mode and read the content in a forward reading order. The screen reader should announce the visual "column header" text and the text of the cell used for the row header (if applicable) prior to announcing the value in the "cell". Manual DOM Inspection: Not recommended for larger grids. |
| Custom Pagination Links | Links that are inactive/non-applicable MUST NOT use accessibility text that indicates the element(s) is a disabled link and accessibility text that was used when the element was applicable and defined as a link (e.g. "First Page", "Previous Page", etc.) must be removed. | SAIL: Inspect the accessibilityText parameter of the link and the altText or caption parameter values on the icon if present. Each parameter should have a null value or not be included in the SAIL. Screen Reader: Put the screen reader in Browse mode and read the non-applicable pagination elements. The screen reader should ignore the elements and announce nothing. Manual DOM Inspection: Locate the non-applicable elements, they are defined as SVG. The SVG should have focusable="false", aria-hidden="true" and tabindex="-1" set on it/them. |
| Custom Pagination Links | The active/available pagination links output immediately adjacent to each other MUST have a target size of at least 24 x 24 pixels OR when a 24 x 24 pixel circle is centered on each link, the circles do not intersect. | Testing Overview: There are two phases to testing. First, the target size of the links needs to be verified as being at least 24 x 24 pixels. If that test fails, then the spacing between the undersized targets needs to be verified. If both tests fail, then an accessibility failure is present. Phase 1 - Verify Target Size: • Open the browser DOM Inspect feature and select the active pagination links that are output adjacent to each other • Hover over the link anchor in the DOM explorer, producing the popup in the browser for the link, note the link size indicated in the popup (you must examine the link anchor size, not the icon) • If this test yields a link size smaller than 24 x 24 pixels, then proceed to Phase 2. Otherwise, there is no failure present Phase 2 - Verify Spacing: • Because of restrictions by Appian, this target size bookmarklet (https://cdpn.io/pen/debug/YzdwWZw) needs to be used to create a visual representation of the targets that overlap on a page • Install this bookmarklet and run it over the page. The bookmarklet will output 24 x 24 pixel circles on many elements on the page • Pay specific attention to the circles that are output over the active, adjacent pagination links, and note if they overlap. An overlap indicates a failure of the requirement • Once the bookmarklet is run, refresh the browser to clear the onscreen results • NOTE: If the links are being tested within a dialog, the bookmarklet output will be present in the parent page that spawned the dialog, positioned exactly where the links were present in the dialog |
| Workflow Visualization Plugin | An alternative view of content in the Workflow Visualization plugin MUST be provided when the plugin is used. | Visual inspection. Alternative views can include a grid, rich text, cards, or other means that convey the same information as the visualization. This can be a toggled view, appear on the same page, or linked to on a separate page. The alternate view must include any node information present in the visualization including the node name, immediate dependencies, and the next node in the process from the current node. |
| Date & Time Component | The Date & Time component MUST NOT be used. | SAIL: Determine if a!dateTimeField is present in the interface. Visual inspection. |
| Card Choice Field | The card choice field component MUST have a label parameter set when more than one card is present in the group. |
SAIL: Verify a label parameter value has been provided for a!cardChoiceField when more than one card is present in the group. Screen Reader: Navigate to the first card in the group using the TAB key or to the last card in the group using the SHIFT + TAB keys. The screen reader should announce the label parameter value prior to announcing "grouping" and any other information in or associated with the card. Manual DOM Inspection: Search for "group". The result should be a <div> having role="group" set on it. Ensure the DOM node referenced by the aria-labelledby attribute set on the element having role="group" contains text. |
| Color Contrast - Text | Regular-sized text MUST have at least a 4.5:1 color contrast between the text and background it is used on. | Manual Testing: Use the Colour Contrast Analyser (https://www.tpgi.com/color-contrast-checker/) Tool Testing: Use axe DevTools - Run a page scan in a browser, do not scan the page in Appian designer. |
| Color Contrast - Text | Large text (at least 18 point or 14 point bold) MUST have at least a 3:1 color contrast between the text and background it is used on. | Manual Testing: Use the Colour Contrast Analyser (https://www.tpgi.com/color-contrast-checker/) Tool Testing: Use axe DevTools - Run a page scan in a browser, do not scan the page in Appian designer. |
| Color Contrast - Image/Icon | Images/icons that convey information and are not redundant to other text MUST have a color contrast ratio of at least 3:1 between the part of the image that conveys information and any adjacent color(s). | Manual: Use the Colour Contrast Analyser (https://www.tpgi.com/color-contrast-checker/) |
| Color Contrast - Selected State | Color that indicates an element as being currently selected MUST have at least a 3:1 color contrast between the color used to indicate the selected state and the default color used for the same area of an adjacent, unselected element. | Manual: Use the Colour Contrast Analyser (https://www.tpgi.com/color-contrast-checker/) |
| Color Use - General | Color MUST NOT be used as the only means of identifying visual elements, e.g. statements such as "Click the red button", "content is below the blue heading", etc. | Visual inspection. |
| Magnification - 200% | All text content MUST be readable, functional, and does not overlap when the browser is magnified to 200% with the interface tested in a browser (not Appian Designer), use CTRL+"+" five times. If text is truncated, a method is provided for accessing the text. | Browser Testing: • Test in a web browser, do not test in Appian Designer • Use the built-in browser zoom • Magnify the content to 200% by pressing CTRL + "+" five times (a browser popup will inform you when you reach 200%) • Reset to default magnification by pressing CTRL+0 |
| Magnification - 400% | Loss of content or functionality MUST NOT occur AND content MUST NOT require both vertical and horizontal scrolling when the browser width is set to 1280 pixels and the browser window is magnified to 400% with the interface tested in a browser (not Appian Designer), use CTRL+"+" eight times. Grids and complex images are exempt from this requirement. | Test in a web browser, do not test in Appian Designer. Set the browser width to 1280 pixels. Use the built-in browser zoom. Magnify the content to 400% by pressing CTRL + "+" eight times (a browser popup will inform you when you reach 400%). Reset to default magnification by pressing CTRL+0. |
| Dynamically-Added Content | Inputs and controls that are dynamically added to the page MUST occur in the tab order after the control that added the content unless visible instructions warn the user of the positioning prior to the content being added. | Keyboard Testing: After activating the control that adds the new content, use the TAB key to navigate forward to the newly-added content. Screen Reader Testing: If content is not added in the forward tab order, navigate to the control that adds the content using the TAB or SHIFT + TAB keys. The screen reader must indicate where the content will be added when the control receives keyboard focus, not when surrounding content is read in screen reader Browse mode. The screen reader must convey a semantic location, such as "after the XX heading". It must not indicate references such as "left" or "right". A screen reader announcement is considered as a last resort - it is preferred that the content be added downstream from the user (in the forward tab order). |
| Link Focus | When a rich text link receives keyboard focus, there MUST be a visual indication of focus, such as a change in the color of the underline used for the link. | Keyboard: Navigate to the link using the TAB or SHIFT+TAB keys. Visually inspect if there is a visual change to the link when it receives keyboard focus. |
| Charts | The chart MUST have a label provided by setting the label parameter on the chart (can use a labelPosition of COLLAPSED if a heading that describes the chart is output above the chart). |
SAIL Testing: Verify the chart component has a label parameter value set.Screen Reader Testing: Navigate to the chart using the TAB or SHIFT + TAB keys. The screen reader should announce a name/label for the chart (may announce this several times). Manual DOM Inspection: Search for "highcharts-container". Ensure the aria-label attribute set on this <div> has a string value that describes/summarizes the chart. |
| Icon | [STANDALONE USED IN A LINK] A text alternative MUST be provided for the icon when it is the only element used in a link, set via the altText or caption parameter on the icon.|SAIL: Verify thealtTextorcaption` parameter value used for the icon. Screen Reader: Navigate to the link using the TAB or SHIFT + TAB keys. The screen reader should announce a text alternative for the icon. axe DevTools: Run a page scan, run the scan in a browser and not in Appian Designer. If an error is present, it will be indicated as "Links must have discernable text". ARC Toolkit: Run the Interactive Controls test, run the test in a browser and not in Appian Designer. If an error is present, it will be indicated as "No link text". Manual DOM Inspection: Locate the icon. Verify the string value used for the aria-label attribute set on the SVG. In some cases, the text alternative may also be inside of a node contained within the link. |
|
| Icon | [USED WITH TEXT IN A LINK] A text alternative MUST be provided for the icon ONLY if the link text does not already convey the same information as the icon. If a text alternative is needed for the icon, it MUST be set via the altText or caption parameter on the icon (do not use accessibility text or a tooltip set on the link). |
SAIL: Verify the altText or caption parameter value used for the icon. Screen Reader: Navigate to the link using the TAB or SHIFT + TAB keys. The screen reader should announce a text alternative for the icon in addition to other text included in the link. Manual DOM Inspection: Locate the icon. Verify the string value used for the aria-label attribute set on the SVG. In some cases, the text alternative may also be inside of a node contained within the link. |
| Icon | [STANDALONE USED IN A BUTTON] A text alternative MUST be provided for the icon when it is the only element used in a button, set via the accessibilityText OR tooltip parameter on the button. |
SAIL: Verify the accessibilityText or tooltip parameter value used for the button. Screen Reader: Navigate to the button using the TAB or SHIFT+TAB keys. The screen reader should announce a text alternative for the icon. axe DevTools: Run a page scan, run the scan in a browser, not Appian Designer. If the icons has no text alternative, the error will be identified as "Buttons must have discernable text". ARC Toolkit: Run the Interactive Controls test, run the test in a browser, not Appian Designer. If the icon has no text alternative, the error will be identified as "No label for button element". Manual DOM Inspection: Locate the button. Verify the presence of a <span> node within the button that contains a text alternative for the icon. This <span> will use the CSS class of will "button---accessibilityhidden" and should contain either the accessibilityText or tooltip parameter value. |
| Icon | [USED WITH TEXT IN A BUTTON] A text alternative MUST be provided for the icon ONLY if the button label text does not already convey the same information as the icon. If a text alternative is needed for the icon, it MUST be set via the accessibilityText parameter on the button. |
SAIL: Verify the accessibilityText or tooltip parameter value that describes the icon is used for the button. Screen Reader: Navigate to the button using the TAB or SHIFT + TAB keys. The screen reader should announce a text alternative for the icon in addition to other text included in the button. Manual DOM Inspection: Locate the button. Verify the presence of a <span> node within the button that contains a text alternative for the icon. This <span> will use the CSS class of will "button---accessibilityhidden" and should contain either the accessibilityText or tooltip parameter value. |
| Icon | [STANDALONE, CONVEYS INFORMATION] A text alternative that conveys the same information as the icon MUST be provided for the icon via the altText, caption, or accessibilityText parameter when there is no adjacent text that conveys the same information. Use a caption only if the purpose of the icon may not be universally understood based on its appearance. |
SAIL: Verify the altText or caption parameter value used for the icon and it is set to a value that conveys the same information as the icon. Screen Reader: Put the screen reader into Browse mode and read the icon. The screen reader should announce a text alternative for the icon that conveys the same information as the icon. Manual DOM Inspection: Locate the icon. Verify the string value used for the aria-label attribute set on the SVG. |
| Icon | [DECORATIVE/REDUNDANT] A text alternative MUST NOT be provided for icons that are purely decorative or where text is output adjacent to the icon that conveys the same information as the icon. | SAIL: Verify the altText and caption parameters used for the icon are null. Screen Reader: Put the screen reader into Browse mode and read the icon. The screen reader should ignore the icon and announce nothing. Manual DOM Inspection: Locate the SVG icon. Verify the SVG has focusable="false", tabindex="-1", and aria-hidden="true" set on it, and there is no aria-label attribute set on the SVG. |
| Image of Text | Images that contain text MUST NOT be used unless the image is a logo or the font used in the image cannot be accurately rendered by a web browser. | Visual inspection. Manual DOM Inspection: Locate the image, determine the image source. Determine if the text is embedded in the image or if it uses CSS to be overlaid on the image. |
| Tooltip | Tooltips made visible on mouse hover MUST be able to become visible using only a keyboard (typically by navigating to the tooltip with the TAB or SHIFT+TAB keys). | Identify where tooltips are used in the interface. For each tooltip, navigate to the element that spawns the tooltip on mouse hover using the TAB or SHIFT + TAB keys with the keyboard. |
| Stamp | Tooltips that convey important information MUST NOT be set via the tooltip and helpTooltip parameters on a!stampField. |
SAIL: Inspect a!stampField and ensure the tooltip and helpTooltip parameters either do not exist or are set to a null value. Screen Reader: Put the screen reader into Browse mode and read the stamp. This is an important testing method because some tooltips set on stamps cannot be made visible on mouse hover or with a keyboard, they are available only to screen readers. |