Cornerstone OnDemand LMS accessibility evaluation

Date evaluated: September 2026
Report date: October 2026

Overview

The Center for User Experience (UX) evaluates digital content using the Web Content Accessibility Guidelines (WCAG) version 2.1, Levels A and AA as our technical standard, using both manual and automated testing methods.

Our manual testing methods include checking for: 

• keyboard and screen reader support
• reflow at high levels of magnification
• accessible video and audio content
• sufficient color contrast

We may also identify usability barriers.

This evaluation is not comprehensive and should not be used as a replacement for internal quality assurance of a product. We find patterns of accessibility barriers and show examples of the types of barriers we find. If you have questions about this evaluation, please contact centerforux@wisc.edu.

For more about WCAG conformance, refer to W3C's Understanding Conformance Levels.

Test conditions

• Device: Dell Latitude 7440
• Operating system: Windows 11 Education Version 23H2 for x64-based Systems
• Browser: Google Chrome
• Screen reader: NVDA

Workflows tested

1. Barriers found in Learner tasks and repeated across roles
   • Log in to PDS Online
   • LMS menu and navigation elements (user settings, navigation links)
   • Update User Profile
   • Browse training on calendar
   • Search for training
   • Register for training
   • Withdraw from training
2. Barriers found in Manager tasks
   • Search for an employee
   • View an employee’s profile
   • Navigate an employee’s transcript
   • Add external training to transcript
3. Barriers found in Administrator tasks
   • Log in to pilot environment
   • Search for events and sessions
   • Reset a password
   • Add/update an instructor
   • Create a new event
   • Assign a training

Accessibility and usability barriers found in testing

Blockers found in testing

The Center for UX identified two blockers in testing. In all roles and workflows, between 300% and 400% browser zoom, the tester was blocked from completing tasks that involved using the Select dialog to input information in a form (barrier 1.10). In the Learner role, this magnification blocker primarily affects the Update User Profile workflow. In the Administrator workflows, there is a keyboard trap that blocked the tester from completing any tasks that involved using a Description field's Rich Text Editor, such as the Create New Event or Copy Event pages (barrier 3.6).

1. Barriers found in Learner tasks and repeated across roles

1.1 Some buttons and input fields lack clear, descriptive names

Across all user roles, there are instances where buttons or input fields are named strangely or fail to describe what the button or field actually is. This mostly affects screen reader users, but there are some instances where a lack of a clear, visible text label may also affect sighted users. Examples in the Learner workflows include: 

• • • “Please select” is often announced as part of the button name for buttons like Cancel or Submit, which is atypical and unnecessary. Users know they can select it as long as it has a programmatic role of button.

    • On the training calendar page, the button to switch the view to "this week only" (right caret icon) lacks a visible text label and is announced as “View controls,” which is vague and unclear.

    • Some Select input fields, such as Select Primary Employee Type in the Update User Profile workflow, are announced as a “clickable list with one item, read only” and then the button to open the Select dialog is announced as “Select an organizational unit,” which doesn’t match the visual text label for the field, nor the heading in the Select dialog once it opens. 

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Operable: Labels or instructions are provided when content requires user input or selection. (WCAG 3.3.2)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.2 Login error messages for PDS Online are provided in a dialog that does not trap keyboard focus

When a user tries to log in without a required field filled in (such as password), or incorrect credentials, the error message dialog does not trap keyboard focus and is not announced when it opens. This makes it difficult for users navigating by keyboard or screen reader to enter the dialog in order to access the content and close the dialog. 

Relevant accessibility guidelines:

• • • Operable: Interactive elements receive focus in a way that makes sense. (WCAG 2.4.3)
    • Robust: Make users of assistive technology aware of important changes in content. (WCAG 4.1.3)

1.3 Some forms use tables for layout and lack properly associated input labels

The Forgot Username page uses table structure for layout of the form, so even though it is invisible to visual users, screen reader users hear the announcement of “table,” which could be confusing. Additionally, the Email input field lacks a properly associated label, so it is announced as just “Edit, blank.”

Relevant accessibility guidelines:

• • • Perceivable: Information, structure, and relationships conveyed through presentation are communicated by assistive technology. (WCAG 1.3.1)
    • Robust: UI component names are communicated by assistive technology. (WCAG 4.1.2)

1.4 Lack of status announcements throughout (error, confirmation, search results)

Across all user roles, there is a consistent lack of confirmation announcements upon successful submission of forms, error announcements upon unsuccessful attempts to submit, and on most search pages, announcement of the number of search results (or no results found). 

Relevant accessibility guidelines:

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

1.5 Low contrast buttons, button text, and focus states

Throughout the LMS, several buttons use low contrast icons, low contrast text, and/or a keyboard focus state that has low contrast against the background color or default state. 

Example 1: Search button is a light gray magnifying glass icon that has low contrast against the white background.

Example 2: Button to close My Team side pane uses dark gray text ("Done") that is hard to read on the blue button.

Example 3: Search button is dark blue and currently receiving keyboard focus, indicated by a black outline around the button. It's difficult to see the black outline because it blends in with the dark blue color of the button itself.

Relevant 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: Meaningful visuals, interactive elements, and interaction states are distinguishable from the background and from their default state. (WCAG 1.4.11)

1.6 Suggested search results list is difficult to navigate with a screen reader, and auto-announcement of results list prevents user from hearing current search query

When entering a search query in the global search and the Training search, the list of suggested results is automatically announced by a screen reader, and the user can tab through the list of trainings with the Tab key. However, if the user tries to navigate the list of suggested results with arrow keys (which is the expected or typical navigation pattern), nothing is announced. Additionally, there is no way to hear what the currently entered text is in the search query because the suggested results keep auto-announcing. 

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.7 Some links open in new tab or window without prior warning or consistency

Across all user roles, there are some instances where links open in a new tab without a prior warning announced to screen reader users. Some links have a visual indicator (external/opens in new tab icon), but some links don’t have any visual indication. The experience of interacting with a link is often inconsistent and unexpected for all users.

Relevant accessibility guidelines: 

• • • Operable: Users understand what each link will do. (WCAG 2.4.4)
    • Understandable: Web pages appear and operate in predictable ways. (WCAG 3.2)

1.8 Tabbed interaction pattern for LMS navigation menu is unexpected and not announced properly to screen reader users

The LMS navigation menu is a group of five tabs, but they are not announced as tabs to a screen reader user (just “Home, submenu, 1 of 5”), so it takes lots of trial and error to figure out how to navigate between the five main navigation items and their submenus. This interaction pattern is unexpected and primarily a barrier for screen reader users, but could also be frustrating for keyboard users.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.9 In tabbed navigation menu, each submenu item has a low-contrast focus state

There is no focus outline provided for keyboard users when navigating through the submenu links. The only visual indication of focus is a slight change in the background color (from light gray to gray).

Relevant accessibility guidelines:

• • • Perceivable: Meaningful visuals, interactive elements, and interaction states are distinguishable from the background and from their default state. (WCAG 1.4.11)

1.10 Blocker: Content in Select dialogs gets cut off starting at 175% zoom and becomes unusable between 300% and 400% zoom

When an input field requires the user to select from a list of options ("Organizational Units"), the “Select” dialog that opens gets cut off on the sides (left, right, top, and bottom) starting at 175% browser zoom. At 200–250% zoom it becomes difficult to use, and at 300% zoom or higher, the dialog becomes unusable because some of the text content is completely outside of the viewport. 

Relevant accessibility guidelines:

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

1.11 Content in side panes and tooltips sometimes gets cut off at 250% zoom and higher

Depending on the placement of a help tooltip, sometimes the content in the tooltip region gets cut off on the left or right side of the screen at 250% browser zoom and higher.

Relevant accessibility guidelines:

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

1.12 Horizontal scrolling is required to view all page content when magnified at 200% zoom and higher

Across all user roles, horizontal scrolling is often required to view or access all page content starting at 200% browser zoom. On some pages, there are also floating or fixed (frozen position) elements that overlap with other content such as buttons, which could make it difficult or frustrating to complete certain interactions. 

Relevant accessibility guidelines:

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

1.13 Tooltip content is not accessible by keyboard or screen reader

Across all Manager and Admin workflows, many pages contain general help tooltips (gray question mark icons) that are not reachable by keyboard or announced by a screen reader.

In a few workflows, there are also additional tooltips that appear upon hovering over a submenu link, such as “View Transcript” in the Manager workflow when searching for an employee. These tooltips can be triggered by keyboard, but are not announced by a screen reader. Additionally, interactive elements such as links within the tooltip content are not reachable by keyboard.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Operable: All functionality is available from a keyboard. (WCAG 2.1.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.14 Inconsistent interaction pattern for Select fields — some open a dialog and some open a new browser window

Across all user roles, there are certain input fields that require the user to select from a list of options. However, these input fields do not always use the same interaction pattern. Some “Select” fields open a dialog, while others open a new browser window.

Relevant accessibility guidelines:

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

1.15 Misleading screen reader announcements for Select field’s role and instructions for interaction

Related to the previous barrier, in addition to the inconsistency of whether “Select” fields open in a dialog or in a new browser window, there are also inconsistencies and inaccuracies in how these input fields are announced to screen reader users. Some fields are announced as an element that “opens dialog,” but upon selection, it opens a new browser window instead.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.16 Some pages are untitled, often those opened for Select field interactions

Throughout the LMS, some pages are untitled, especially those opened as part of the “Select” field interactions noted in previous barriers. This makes the experience of navigating and entering information in those fields even more confusing.

Relevant accessibility guidelines:

• • • Operable: Each web page has a meaningful title. (WCAG 2.4.2)

1.17 Some tables with sortable column headers are not properly announced by screen reader, sometimes also not visually indicated

Throughout the LMS, there are inconsistencies in how tables with sortable column headers are announced by a screen reader. Sometimes they are announced properly, but sometimes they are just announced as the column header name and “button” without further context.

Sometimes there is also no visual indication (e.g., sort icon with up and down arrows) that the column is sortable.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, values, and states are communicated by assistive technology. (WCAG 4.1.2)

1.18 More Actions submenu on Transcript page is not accessible by keyboard or screen reader

Across all user roles, the Transcript page contains a “More actions” submenu (down caret button to the right of “View Training Details”) that is not accessible by keyboard or screen reader.

If a user needs to withdraw from a training, the only way to do so is to select “View Training Details” to go to the full training page, where the user can then access the “More actions” submenu button on that page in order to select “Withdraw” from that submenu.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Operable: All functionality is available from a keyboard. (WCAG 2.1.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.19 Calendar date picker is difficult to use with a screen reader due to missing, improper, or abbreviated names and table structure

Across all user roles, there are screen reader announcement issues with the calendar date picker widget.

When the calendar picker is used as a filter on the training calendar page, it is announced as a table with abbreviated day of the week headers (“We,” “Th,” etc.) which makes it hard to understand as one navigates. 

When the calendar picker is used as part of a date input field, there is some variance in how it announces depending on the page/workflow. In some workflows it is announced more similarly to the filter example, with table structure and abbreviated headers. In other workflows such as Update User Profile, it announces the date without the underlying table structure — however, it only works when the user navigates up and down with the arrow keys, while navigating left or right causes an announcement of “blank” instead of the date.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.20 Browsing training calendar with a screen reader requires excessive or unexpected navigation mode switching, and no instructions are provided

There are a lot of interactive components on the training calendar page, and it is not always clear how to interact with them because they use inconsistent/unexpected navigation patterns and there are no instructions provided for how to navigate with a screen reader. 

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

1.21 Orange and white color scheme may result in low contrast

The Cornerstone default color scheme (orange and white) does not meet WCAG color contrast requirements for regular-sized text. It passes at level AA for large text, but ideally it is best to use color pairings with a contrast ratio of at least 4.5:1 for all text.

Relevant 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)

1.22 Search training filters are icons with no visible text label

While there are labels announced by a screen reader, it may be difficult for visual users to search for a training using the available filters because they are only represented by icons, without text labels.

Relevant accessibility guidelines:

• • • Operable: Labels or instructions are provided when content requires user input or selection. (WCAG 3.3.2)

1.23 Illogical focus and reading order for "Select a Session" button on training pages

The only purpose of the “Select a Session” button (in the event callout card on the upper right of any training page) is that if a user selects it, their focus jumps to the bottom of the page where a user can select “View Details” and request a training. However, this card and button are at the end of the page’s focus and reading order for assistive technology like keyboards and screen readers. This results in a confusing experience because the “Select a Session” button is just sending them back to the content they just read/interacted with.

Relevant accessibility guidelines:

• • • Perceivable: Assistive technology presents content to users in the proper order. (WCAG 1.3.2)
    • Operable: Interactive elements receive focus in a way that makes sense. (WCAG 2.4.3)

1.24 Placement and icons used for User Profile and Settings buttons is confusing  

The person icon button is a link that takes users to the User Profile Overview page, while the gear icon is a button that opens a submenu where users can view their account preferences, get help, or log out. In many applications, a person icon is typically used to open the My account/Log out menu, so the placement and icons used for these two buttons could be confusing for new users of the LMS.

Relevant accessibility guidelines:

• • • Usability, may affect all users

2. Barriers found in Manager tasks

2.1 Illogical focus order on Users page

On the Users page, the search filter input fields receive focus in this order: input fields in first column receive focus top to bottom, then second column top to bottom, then third column top to bottom. However, there is an input field (OU Type) at the end of the first column that receives focus last.

Relevant accessibility guidelines:

• • • Operable: Interactive elements receive focus in a way that makes sense. (WCAG 2.4.3)

2.2 Buttons to print or download user search report lack clear labels and prior warnings about link action

On the Users search page, the print button is announced as “print graphic button,” and users may assume it will open a print dialog because that is the typical, expected behavior for print buttons. Instead, selecting the button opens a new browser window. The button gave no indication that it was technically a link to open a new web page. 

Similarly, the Excel button is announced as “Excel graphic button” with no additional context or warning about what will happen upon selecting it. It opens a new browser window where the user search report is downloaded as an Excel file. It is unclear why the file is not downloaded in the user’s current window.

Relevant accessibility guidelines:

• • • Operable: Users understand what each link will do. (WCAG 2.4.4)
    • Understandable: Web pages appear and operate in predictable ways. (WCAG 3.2)

2.3 When viewing User Record, Expand/Collapse section buttons are not uniquely labeled

When viewing an employee profile (User Record), the buttons to expand or collapse a section of the page are not uniquely labeled, which makes it more tedious to figure out which section the button belongs to before interacting with it.

Relevant accessibility guidelines:

• • • Operable: Labels clearly and accurately describe the topic or purpose. (WCAG 2.4.6)

3. Barriers found in Administrator tasks

3.1 Poor error handling

In several Administrator workflows, there are instances where the error message is not located directly near the field(s) that have errors. The error message is also not announced by a screen reader, so it requires more time and effort than it should for the user to navigate around to figure out what is wrong and then correct the error. On some pages, the red text used to display the error message also fails WCAG color contrast requirements (for example, the contrast ratio is 2.8:1 on the Add Instructor page).

Relevant 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)
    • Understandable: Users know an error exists and what is wrong. (WCAG 3.3.1)
    • Robust: Make users of assistive technology aware of important changes in content. (WCAG 4.1.3)

3.2 Confusing placement of Create New Event button

On the Manage Events page, the button “Create New Event” is visually located in the lower right after all the search filter fields, which makes it look like the final step or element to select in the process of searching for an event. However, selecting this button actually opens a new page where the user can create a new event. Despite the button’s label, due to its visual placement alone, users may be likely to accidentally click it when they are intending to launch a search.

Relevant accessibility guidelines:

• • • Usability, may affect all users

3.3 Last two columns in Events results table do not contain tabular data

The Manage Events search results table contains some content that should not be in a table. The last two columns (8 and 9) lack column headers and do not contain true tabular data; instead, column 8 contains two links and a button, while column 9 contains the button’s submenu items. This makes navigating the table and interactive elements very confusing.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Understandable: Make web pages appear and operate in predictable ways. (WCAG 3.2)

3.4 Misleading role and unclear label for Copy Event button

In the Manage Events search results table, one of the submenu items in the “more actions” (...) button is “Copy Event.” Typically, users may expect a Copy button to copy information to their clipboard. In this case, however, the Copy Event button is actually a link that opens a new page. This is unexpected behavior based on the role and label of the button.

Relevant accessibility guidelines:

• • • Operable: Users understand what each link will do. (WCAG 2.4.4)
    • Understandable: Web pages appear and operate in predictable ways. (WCAG 3.2)

3.5 Several pages use tables for layout and lack properly associated input labels

The Copy Event page and the Add Vendor/Add Instructor pages contain forms that use tables for layout and lack properly associated labels for input fields. 

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)

3.6 Blocker: Description field’s Rich Text Editor is a keyboard trap and requires HTML knowledge to write or edit with a screen reader

Any tasks that involve using a Description field in the Admin role are not accessible to keyboard users, and may be extremely difficult or impossible for screen reader users. Upon entering the Rich Text Editor (which is the default editor for a Description field), pressing the Tab key results in adding visual tab spacing to the text description, and there is no way to exit the Description field with a keyboard alone (keyboard trap).

When navigating with a screen reader, users might be able to switch into reading mode and use the arrow keys to get out of the field and access the rest of the page content. However, if a screen reader user needs to write or edit the description, the only way to do this is to switch to the HTML editor and interact with the text field that way. This requires knowledge of basic HTML, which many users likely do not have.

Relevant accessibility guidelines:

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

3.7 Process of uploading a file is two steps, which is unclear based on labels, and no instructions are provided

When uploading a file attachment in the Create New Event workflow, users may think that once they select “Upload,” that is the end of the process. However, selecting Upload triggers new content to load that asks the author to select the file visibility settings before saving or canceling. This may be confusing for many users, but may be particularly difficult for screen reader users because there is no status announcement and the Save and Cancel buttons don’t include the word “file” or “attachment” in the label, so it may be unclear that these Save and Cancel buttons are related to the file upload process.

Relevant accessibility guidelines:

• • • Usability, may affect all users and especially users of assistive technology

3.8 Some buttons lack visible focus indicators

Some buttons, such as the Upload button on the Copy Event page or the Cancel, Save as Draft, and Publish buttons on the Create Group page, lack visible indicators of keyboard focus. This could make it very difficult for keyboard users to use the page, and could introduce errors if they accidentally cancel when they meant to save, or publish when they meant to cancel, etc. 

Relevant accessibility guidelines:

• • • Operable: Each element that receives keyboard focus has a visible indicator. (WCAG 2.4.7)

3.9 Most “Add” buttons open a new window, some without prior warning

Most “+ Add” buttons are actually links that open a new window, but only some of them have a prior warning announced as part of the element label (link text). The Create New Event workflow has a lot of these “buttons.”

Relevant accessibility guidelines:

• • • Operable: Users understand what each link will do. (WCAG 2.4.4)
    • Understandable: Web pages appear and operate in predictable ways. (WCAG 3.2)

3.10 Text color for inactive vendors/instructors is low contrast

When searching for a vendor or instructor, any inactive entities will appear in the search results table as grayed out, indicated by gray text on the light gray background. However, this color combination has a contrast ratio of 2.8:1 and is difficult to read.

Relevant 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)

3.11 Vendor/instructor results tables lack semantic column headers

As a screen reader user navigates the table that contains search results for vendors or instructors in the system, the column headers (Instructor Name, Location, etc.) are not announced.

Relevant accessibility guidelines:

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

3.12 Text in Create Assignment side pane gets cut off at 250% zoom or higher

There are five steps (pages) in the Create Assignment workflow, but at 250% browser zoom or higher, the text is cut off in the left side pane that lists each of the five steps. The following screenshot shows the page at 300% zoom.

Relevant accessibility guidelines:

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

3.13 Page reloads upon changing radio button selection

In the Assign Training workflow, the Email settings radio button grouping triggers the page to reload upon changing the radio button selected. Rather than a true radio button grouping, the page seems to use Javascript to route the user to different links/versions of the page depending on which radio button is selected. This issue also occurs on the Manage Events and Sessions page.  

Relevant accessibility guidelines:

• • • Understandable: Changing a selection does not automatically cause a change of context. (WCAG 3.2.2)

3.14 Required field is not announced as such, and only visually indicated sometimes

In several pages and workflows, there are instances where required input fields are not announced as “required” by assistive technologies like screen readers. In some workflows such as Assign Training, the “Select Users” button is not announced as a “required” field; it is only visually indicated as such by a red asterisk.

In other workflows, such as Add Instructor (or Vendor), there is neither visual nor auditory (screen reader) indication that a field is required until the user tries to save or submit.

Relevant accessibility guidelines:

• • • Perceivable: Information and content structure is clearly communicated to users of assistive technology like screen readers. (WCAG 1.3.1)
    • Robust: UI components’ names, roles, and values are communicated by assistive technology. (WCAG 4.1.2)