Kuali Build Accessibility and Usability Information

This document contains the findings of an accessibility evaluation performed by the Center for User Experience. This is not a comprehensive list of barriers. Kuali Build is a no-code form and workflow automation platform.

Date evaluated: 2/23/23
Report date: 3/1/23

Overview

The Center for 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.

Get Help

  • Contact the DoIT Help Desk for general assistance or to report an accessibility or usability barrier.
  • Contact the Low Code Solutions support form for assistance with Kuali Build

Test conditions

  • Device: MacBook Air
  • Operating system: MacOS Monterey
  • Web browser: Chrome
  • Screen reader: VoiceOver

Pages tested

  1. Sample door access application

Barriers found in testing

1. Dropdown menus lack role announcement

When a user places focus on a field that exposes a dropdown menu, the menu is not announced via screen reader. The following screenshot shows the VoiceOver output announcing "Building, edit text," while a dropdown menu is displayed visually. 

Combobox element labeled Building with screen reader output reading Building, edit text

Relevant WCAG guidelines:

  • People using assistive technology should understand all components (Name, value, role). WCAG 4.1.2

2. Visual order does not always match keyboard navigation order 

Some form elements do not receive focus from a keyboard or screen reader in the same order as they are displayed visually. For example, although the elements "Person Last Name" and "Person First Name" are displayed side-by-side in the following screenshot, the Tab order of the fields goes from top to bottom before moving left to right across columns. "Campus ID" ends up between the last and first name fields in the keyboard order. 

Form fields in a grid labeled Person Last Name, Person First Name, Campus ID, and Badge Proxy Number

Some dynamic elements, like the calendar popup that appears on date select fields, are entered at the end of the keyboard navigation order instead of being inserted adjacent to the user's current focus. 

Calendar popup on date selection field

Relevant WCAG guidelines:

  • The correct reading sequence can be programmatically determined. WCAG 1.3.2

3. Lack of status messages on dynamic content 

There is no announcement via screen reader when dynamic elements appear on the page after user action, such as error message popups. These messags are added to the beginning or end of the page, which can make it difficult for screen reader users to discover and interact with content. 

Relevant WCAG guidelines:

  • Assistive technology notifies users about updated content that doesn't take focus. WCAG 4.1.3


Keywords:
evaluation, automated testing, manual testing, low code, no code, lcs 
Doc ID:
163351
Owned by:
Leah B. in IT Accessibility and Usability
Created:
2026-08-14
Updated:
2026-08-18
Sites:
IT Accessibility and Usability