Ivanti Neurons (WiscIT) Accessibility and Usability Information

Low contrast focus indicator for search bar

The light blue focus indicator that outlines the search bar when it receives keyboard focus has low contrast with some portions of the Bucky Badger background image. In some areas, the contrast ratio of the blue line against the image background is as low as 1.2:1. This could cause difficulty for keyboard users with low vision or color blindness. The focus outline should have at least a 3:1 contrast ratio with every part of the background image. 

Video: Monochrome demo of search bar with keyboard focus

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Meaningful visual cues are distinguishable from the background. (WCAG 1.4.11)

In Profile Settings, tabs lack a visible focus indicator

When using a keyboard to navigate through the Profile Settings options (General Settings, Password), the tabs lack a visible focus indicator. 

Video: Keyboard demo of Profile Settings tabs navigation

This barrier primarily relates to the following accessibility guidelines:

• Operable: Provide ways to help users navigate, find content, and determine where they are. (WCAG 2.4.7)

Profile menu does not close when user tabs or clicks out of it

Once the Profile menu is open, the user must either click on the Profile icon again or tab backwards to the icon and select it via keyboard in order to close the menu. This is typically not the expected behavior for a Profile menu, and it could cause confusion or difficulty for users with cognitive disabilities or for users with low vision at high levels of magnification.

This barrier primarily relates to the following accessibility guidelines:

• Understandable: Web pages appear and operate in predictable ways. (WCAG 3.2)

At high magnification, Profile menu becomes inaccessible by keyboard and Notifications button appears

At 250% magnification or higher, the Profile menu (once opened) becomes inaccessible by keyboard. Instead of the focus order taking the user into the menu options, keyboard focus continues to jump through the rest of the home page and completely skips over the menu. Additionally, at 250% magnification or higher, the Notifications button appears, but it is not present at default magnification, which creates a different experience for users.

Video: Keyboard demo of home page navigation at 250% magnification

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Content can be magnified without loss of information or functionality. (WCAG 1.4.10)
• Operable: All functionality is available from a keyboard. (WCAG 2.1.1)

At high magnification, Search results page becomes extremely difficult or impossible to use

At 200% magnification, the Search results page has an extremely small scrollable area due to several fixed (frozen position) elements that take up a lot of space on the page. At 250% magnification or higher, the Search results page becomes completely unusable, as the results cannot be viewed or scrolled through at all. 

Video: 200% demo and Video: 250% demo 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Content can be magnified without loss of information or functionality. (WCAG 1.4.10)

Low contrast of search filter buttons in focus and hover states at high magnification

At 250% magnification or higher, the Filter, Sort, and All Dates buttons have low contrast text in keyboard focus state and in hover state (when moused over). 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Text is distinguishable from the background. (WCAG 1.4.3)

Role dropdown in upper left of home page is announced by screen reader as two separate elements, and “No data to display” is not announced

The Role dropdown in the upper left corner of the home page (e.g., “Self Service” with the down caret icon button) is announced by NVDA as two separate elements, which makes navigation confusing and difficult. Additionally, when the down caret button is selected to expand the dropdown, the text that appears (“No data to display”) is not announced.

Video: Screen reader (NVDA) demo of Role dropdown navigation (0:00 to 0:40)

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)

In Profile Settings, using keyboard to open combobox list causes Change Picture dialog to open instead

In Profile Settings, if the user tries to use the Enter key to open a combobox’s list of options (e.g., to change Language or Role), the Change Picture dialog opens instead. This is very frustrating and could prevent keyboard users from making changes to their Language or Role settings. The down arrow key also did not work to open the combobox’s values list.

Video: Keyboard demo of combobox/Change Picture bug (0:40 to 2:00)

This barrier primarily relates to the following accessibility guidelines:

• Operable: All functionality is available from a keyboard. (WCAG 2.1.1)
• Understandable: Web pages appear and operate in predictable ways. (WCAG 3.2)

In Profile Settings, changing a combobox selection reloads home page

In Profile Settings, if the user changes the current selection in a combobox (such as from no language selected to English), the user is prompted in a pop-up dialog to confirm their choice. After making a selection, the home page reloads, which could be jarring and unexpected for many users. There are save and cancel buttons at the bottom of the Profile Settings page, but users do not get the chance to interact with those buttons. After making changes, users should have the opportunity to review all of their choices and select “Save Changes” or “Cancel.” 

Video: Screen reader (NVDA) demo of combobox selection changing context

This barrier primarily relates to the following accessibility guidelines:

• Understandable: Web pages appear and operate in predictable ways. (WCAG 3.2)

Navigating search suggestion list on home page with a screen reader may cause focused text to turn white (disappear)

When using NVDA and the arrow keys to navigate through the search suggestion list on the home page, the currently focused search suggestion turns from black text to white as the user goes through the list.

Video: Screen reader (NVDA) demo of search suggestion list navigation

This barrier primarily relates to the following accessibility guidelines:

• Usability, may impact screen reader users with low vision or reading disabilities

Category tag in service catalog/search results page looks clickable, but is not

In the service catalog or on any search results page, the “tag” text that indicates the category of the item appears like a clickable button. Its appearance may cause confusion or frustration for users. 

This barrier primarily relates to the following accessibility guidelines:

• Usability, may impact all users

At high magnification, scrollable area is too small to use effectively

At high levels of magnification, the form has an extremely small scrollable/viewable area due to several fixed (frozen position) elements that take up a lot of space on the page. 

Video: Magnification demo starting at 200% and going up to 300%

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Content can be magnified without loss of information or functionality. (WCAG 1.4.10)

Nested scrolling occurs when user input is a long description

When the user has entered a long description into an input field, the input field becomes scrollable — however, the web page also has a separate scroll bar for the outer container that contains the full form. The nested scrolling can be confusing and difficult to navigate, especially at higher levels of magnification. 

This barrier primarily relates to the following accessibility guidelines:

• Usability, may affect users with motor or cognitive disabilities

After submitting, “Loading” screen reader announcement continues repeating even after success message appears visually

After submitting a form, the “Loading” message that is announced via screen reader continues repeating for about 15 seconds after the success message (“Request created successfully”) has visually appeared on screen. 

Video: Screen reader demo of announcements after submitting (1:40 to 2:10)

This barrier primarily relates to the following accessibility guidelines:

• Robust: Make users of assistive technology aware of important changes in content. (WCAG 4.1.3)

Empty alert is announced by screen reader upon entering form

When a form loads, the first thing announced upon entering the form is an empty “alert” message. This may confuse screen reader users.

Video: Screen reader demo of empty alert (0:00 to 0:20)

This barrier primarily relates to the following accessibility guidelines:

• Robust: Make users of assistive technology aware of important changes in content. (WCAG 4.1.3)

Reset link is not accessible by keyboard

In input fields where the user has the option to clear their selection (such as in a group of radio buttons), the Reset link cannot be reached or selected by keyboard.

This barrier primarily relates to the following accessibility guidelines:

• Operable: All functionality is available from a keyboard. (WCAG 2.1.1)

Keyboard focus is not visible for calendar picker button

In input fields where the user has the option to open a calendar picker, the calendar picker button does not have a visible indicator of keyboard focus.

This barrier primarily relates to the following accessibility guidelines:

• Operable: Users know which element has keyboard focus. (WCAG 2.4.7)

Low contrast keyboard focus indicator for radio buttons

While there is a visible focus indicator when a user enters a radio button grouping, the blue color used to indicate keyboard focus is extremely difficult to distinguish from the default gray color. The blue focus state color has a 1.2:1 contrast ratio with the gray default button color.

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Meaningful visual cues are distinguishable, with a contrast ratio of at least 3:1. (WCAG 1.4.11)

Instructions or examples are provided after input fields

When instructions or examples are provided to help users know how to format the information they input, these instructions are located after the input field and are not announced to users of assistive technology upon entering the input field. Users may not know the instructions are there unless the overall form contains prior instructions that inform users of what to expect, such as “Instructions and formatting guidance can be found immediately after each field.”

This barrier primarily relates to the following accessibility guidelines:

• Usability, may impact all users and users who navigate with assistive technology in particular

Show full email button is not keyboard accessible

The Show full email button (full screen icon) cannot be reached or interacted with by keyboard alone. 

This barrier primarily relates to the following accessibility guidelines:

• Operable: All functionality is available from a keyboard. (WCAG 2.1.1)

Show full email button is not labeled for screen reader use and lacks state change announcements

The Show full email button (full screen icon) can be reached by screen reader, but it is unlabeled and is announced only as “clickable” without context. Upon selecting it to show or hide the full contents of an email, there is no state change announcement that informs a screen reader user of whether the email is currently displaying in full or not (in other words, toggled on or off).

Video: Screen reader demo of interacting with Show full email button (1:20 to 1:50)

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about elements, including labels, are communicated via screen reader. (WCAG 1.3.1)
• Robust: UI component states are communicated by assistive technology. (WCAG 4.1.2)

Screen reader does not announce current status shown in status bar

While a screen reader announces all of the words shown in the incident status bar (Logged, In progress, Resolved, etc.), there is no announcement that indicates which is the current status. This is an unequal experience because there is visual indication of the current status (color, open circle vs. filled circle, bold text). 

Video: Screen reader demo of interacting with status bar (0:20 to 0:40)

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about elements, including labels, are communicated via screen reader. (WCAG 1.3.1)
• Robust: UI component states are communicated by assistive technology. (WCAG 4.1.2)

No screen reader confirmation announcement after adding a note

There is a visual toast notification that indicates success after adding a note, but there is no corresponding screen reader announcement that confirms the note has been added successfully. 

Video: Screen reader demo of adding a note (0:40 to 1:10)

This barrier primarily relates to the following accessibility guidelines:

• Robust: Make users of assistive technology aware of important changes in content. (WCAG 4.1.3)

Close Incident button is available even when user lacks permissions

The Close Incident button at the bottom of the page appears available and can be selected by the user, but when it is selected, there is an error message that indicates the user does not have rights to update the incident. For any user who does not have permission, the button should be grayed out visually, unable to be selected, and announced as unavailable to screen reader users.

Video: Screen reader demo of trying to Close Incident

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about elements, including labels, are communicated via screen reader. (WCAG 1.3.1)
• Robust: UI component states are communicated by assistive technology. (WCAG 4.1.2)
• Usability, may impact all users

Unclear error message after trying to Close Incident without permissions

After trying to Close Incident without the right permissions, the user gets an error message that reads, “You do not have rights to update Journal.Notes.” This is extremely unclear and may leave users unsure whether the error is related to the action they attempted or something else.

This barrier primarily relates to the following accessibility guidelines:

• Usability, may impact all users

Keyboard focus is not visible for most interactive elements

Most interactive elements do not receive visible keyboard focus when using the tab key to navigate. This makes it very difficult for keyboard users to know where they are on the page at any given time or know what they are selecting.

This barrier primarily relates to the following accessibility guidelines:

• Operable: Users know which element has keyboard focus. (WCAG 2.4.7)

Many buttons and form controls are not labeled

Throughout the app, many buttons and form controls are not labeled for use with assistive technology. When interactive components are not labeled properly, they are announced only as "clickable" without context. This could make it extremely difficult if not impossible for screen reader users to navigate and complete tasks. 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about content structure is communicated by assistive technology. (WCAG 1.3.1)
• Robust: UI component names are communicated by assistive technology. (WCAG 4.1.2)

Lack of heading and landmark structure

Users of assistive technology like screen readers may rely on headings and landmarks to “scan” a page and get a quick sense of where to navigate to. Without this structure, it may be very difficult for screen reader users to navigate. 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about content structure is communicated by assistive technology. (WCAG 1.3.1)

Interface does not support magnification up to 400% zoom

Some elements overlap or crash into each other when a page is magnified. At the top and bottom of most pages, there are fixed elements that take up a lot of space at higher levels of magnification. These fixed elements significantly limit how much of a page users can view or scroll through. 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Content can be magnified without loss of information or functionality. (WCAG 1.4.10)

Tooltips can only be accessed by mouse hover

Throughout the app, tooltips can only be accessed when hovering over them with a mouse. The information contained in tooltips cannot be accessed by keyboard or screen reader users.

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about content is communicated by assistive technology. (WCAG 1.3.1)
• Operable: All functionality is available from a keyboard. (WCAG 2.1.1)

Combobox values are not announced properly

When using a screen reader and keyboard to navigate through combobox values (list of options in a dropdown), sometimes the current selected value is announced repeatedly instead of announcing the other options as the user navigates through the list. In other comboboxes, “blank” is announced repeatedly instead of announcing each option listed. This could make it extremely difficult if not impossible for screen reader users to navigate and complete tasks.

This barrier primarily relates to the following accessibility guidelines:

• Robust: UI component values are communicated by assistive technology. (WCAG 4.1.2)

State changes are not announced

Upon expanding or collapsing an interactive element, there is no screen reader announcement of the change in state (such as "expanded" or "collapsed"). 

This barrier primarily relates to the following accessibility guidelines:

• Robust: UI component states are communicated by assistive technology. (WCAG 4.1.2)

Dialogs are not announced properly when they open

When a pop-up dialog opens, it is not announced properly by a screen reader. Even if the content within the dialog is announced and receives focus, it should still be identified as a "dialog" so that screen reader users can understand new content has appeared that is separated from the rest of the page content. 

This barrier primarily relates to the following accessibility guidelines:

• Robust: UI component names and roles are communicated by assistive technology. (WCAG 4.1.2)

Error messages are not announced when they appear

While error messages appear visually near the affected form field(s), there is not a prompt, dynamic screen reader announcement of the error message. This could make it difficult or frustrating for screen reader users to submit information, perform searches, or complete other tasks in the backend.

This barrier primarily relates to the following accessibility guidelines:

• Robust: Make users of assistive technology aware of important changes in content, such as the existence of errors. (WCAG 4.1.3)

Submenus cannot be opened when screen reader is running

When running the NVDA screen reader, the keyboard arrow keys do not work to open any submenus. This could potentially be due to custom coding (such as custom Javascript) that is not compatible with assistive technology.

This barrier primarily relates to the following accessibility guidelines:

• Robust: UI components are usable with assistive technology. (WCAG 4.1.2)

Tables are used to structure layout of application

Throughout the application, tables are used for layout rather than to present data. In many workflows, form fields are contained within a table, and when that table structure is repeatedly announced by a screen reader, it could make it difficult and frustrating to submit information, perform searches, or complete other tasks. 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about content structure is communicated by assistive technology. (WCAG 1.3.1)

Data tables lack semantic header rows or columns

True data tables, such as those in the Incident, Problem, Change, and CI workflows, lack semantically marked header rows or columns. This could make it very difficult for screen reader users to navigate and understand the information and relationships conveyed by a given table. 

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Information about content structure is communicated by assistive technology. (WCAG 1.3.1)

Language of page is not set

Throughout the application, the HTML document does not have a lang attribute to specify the language of the page as English. 

This barrier primarily relates to the following accessibility guidelines:

• Understandable: Assistive technology can determine the language of a page. (WCAG 3.1.1)

No Skip to Main Content link

The only way to for keyboard users to reach to the main page content is to tab through all repeating content at the top of the focus order (such as the navigation menu). This could be tedious and frustrating for frequent users of the application. Keyboard and screen reader users would benefit from a Skip to Main Content link to enable quick and direct access into the main page content. 

This barrier primarily relates to the following accessibility guidelines:

• Operable: Users who navigate sequentially through content can skip repeating content to more easily enter the main content of the page. (WCAG 2.4.1)

Low color contrast and poor use of color

Throughout the application, there are several instances of low color contrast and poor use of color. Many of these instances are interactive components (such as a button) with low text contrast. In addition to being difficult to read, low text contrast often makes it difficult to identify whether a component is unavailable and therefore intended to be grayed out, which is also a usability barrier in addition to a barrier for people with visual disabilities. Refer to Figures 1 through 6 for screenshots of a few examples.

This barrier primarily relates to the following accessibility guidelines:

• Perceivable: Text is distinguishable from the background, with a contrast ratio of at least 4.5:1 for regular-sized text. (WCAG 1.4.3) 
• Perceivable: Visual information is distinguishable from the background, with a contrast ratio of at least 3:1. (WCAG 1.4.11) 
• Perceivable: Color is not the only way of distinguishing information. (WCAG 1.4.1)

Figure 1, Search for Release

Release page with search bar in upper right. Gray text ("Search for Release") has a contrast ratio of 3.1:1 against the light gray background. 

Figure 2, Show Filters

Incident page with Show Filters button in collapsed toolbar at top. Light blue text ("Show Filters") has a contrast ratio of 1.9:1 against the white background. 

Figure 3, Hide Filters

Incident page with Hide Filters button in expanded toolbar at top. Light blue text ("Hide Filters") has a contrast ratio of 1.8:1 against the light gray background. 

Figure 4, Ticket Progress

Incident page with Ticket Progress column shown. Progress bars are visually indicated by five rectangles, some of which are green to indicate the stages that are complete and some of which are gray to indicate stages that have not been completed yet. The second row pictured is in hover state, which makes the remainder of the progress bar (two gray rectangles) disappear against the gray background. 

Figure 5, Save Record

Incident ticket page with Save Record button in hover state. White text ("Save") has a contrast ratio of 1.6:1 against the light blue button background. 

Figure 6, New Problem

Problem page with New Problem button in hover state. Blue text ("New Problem") has a contrast ratio of 4.1:1 against the light blue button background.