Slate by Technolutions accessibility evaluation

Date evaluated: August 2026
Report date: September 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. Application status portal (student-facing)

2. Recommendation submission (community/faculty/staff-facing)
3. Applicant-reported issue (student-facing)

Note: The Center for UX evaluated two student-facing application forms created with Slate in October 2025. The barriers found in the 2025 evaluation are not listed in this document, but reflected the same programmatic issues and patterns as the barriers found in this 2026 evaluation. There was no evidence of meaningful improvement in Slate software’s accessibility level between October 2025 and September 2026. 

Accessibility and usability barriers found in testing

Barriers repeated across workflows tested

Lack of status and state announcements

Throughout the student- and staff-facing workflows tested, there is a consistent lack of status and state announcements for screen reader users. This could make navigating the application process difficult, confusing, or frustrating for users with visual or reading disabilities who rely on screen readers.

Relevant accessibility guidelines:

• • • Robust: UI component names and state changes are communicated by assistive technology. (WCAG 4.1.2)
    • Robust: Make users of assistive technology aware of important changes in content. (WCAG 4.1.3)

Form inputs lack accessible labels

Throughout the student- and staff-facing workflows tested, there is a consistent lack of accessible labeling in forms. Typically a visual label is present, but upon entering the form input field, the label is not announced by a screen reader. Users must navigate backward to access the visual text label in order to understand what question they’re answering. This could make navigating the application process difficult, confusing, or frustrating for users with visual or reading disabilities who rely on screen readers.

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)

Poor reflow on mobile and at high magnification on desktop

Throughout the student- and staff-facing workflows tested, there are several pages and tasks that are difficult to view or complete on mobile devices or at high levels of magnification on desktop (up to 400% zoom). This could make navigating the application process difficult for users with visual or motor disabilities who rely on magnified screens or devices with vertical orientation. 

Relevant accessibility guidelines:

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

1. Application status portal (student-facing)

1.1 No confirmation announcements upon sending recommender reminders or upon submitting decision form 

After sending a reminder to a recommender, there is no screen reader announcement that confirms the reminder has been sent. There is also no screen reader announcement after submitting a decision. (There are also no visual confirmation messages shown after performing these tasks, but these can be set up internally.) 

Expected behavior: There should be both visual and auditory confirmation messages provided to users after completing tasks like sending reminder emails or submitting the decision form.

Relevant accessibility guidelines:

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

1.2 Form input labels are not properly associated or announced in decision form 

In the Decision Reply Form, the label that corresponds to the group of checkboxes is either missing or not properly associated. There is no label announced by a screen reader when a user enters the checkbox grouping, so the user must navigate backward to understand what question they’re answering with their checkbox selection. 

Expected behavior: When a screen reader user tabs into a group of checkboxes or radio buttons, the question should be announced so the user knows what question they’re answering with their checkbox selection.

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.3  X and checkmark images do not have alt text and are the only content in first column of table

In the application checklist table, the X and checkmark images (✕ and ✓) are announced as unlabeled graphics, and each image is located in a table column that is separate from the column that contains the actual status text (e.g., “Awaiting”). The result is a tedious and confusing experience when navigating the checklist table with a screen reader.

Expected behavior: Ideally, if the X and checkmark images always match the status text (e.g., X always means “Awaiting”), then each image should be located in the same column as its status text and marked as decorative because the images provides redundant information. Or the images may not need to be included in the table at all.

Relevant accessibility guidelines:

• • • Perceivable: Visual content has a text alternative that provides the same information to non-visual users. (WCAG 1.1.1)

1.4 Poor reflow on mobile and at high magnification on desktop

At high levels of magnification (400%) on desktop and on mobile devices, some text is cut off in the application checklist on the portal home page, and two buttons become smushed into one “mega button” on the Decision Reply Form page. (The "mega button" behavior also occurs in barrier 2.9 on the recommendation submission page.)

Relevant accessibility guidelines:

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

1.5 Low color contrast of white text on light gray and green backgrounds

Throughout the portal, the banner at the top often has white text on a light gray or green background. Some buttons in hover state also have white text on a light gray background. These color pairings have a contrast ratio of 2.9:1 (white on green) and 1.9:1 (white on light gray), which is significantly less than the required 4.5:1 contrast ratio for 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.6 Some links rely on color to indicate interactivity, including in focus and hover states

Throughout the portal, there are some clickable links that are only visually indicated as links by their blue color. This could make it difficult to distinguish links from regular text for users who are colorblind or have low vision. Additionally, link appearance is inconsistent — one link (“Add New”) is underlined all the time in the table that lists applicant references (recommenders' names), but the other links in the table are never underlined. This could make it seem like “Add New” is the only link on the page.

Expected behavior: Links should be underlined, ideally in all UI states, but at the very least in focus and hover state (when keyboard or mouse users have their cursor over the link). Additionally, link appearance should be consistent. 

Relevant accessibility guidelines:

• • • Perceivable: Color is not the only way of distinguishing information. (WCAG 1.4.1)

1.7 Not clear how to return to portal home page from Recommendations page

When a user is on the Recommendations page, there is no “Back” or “Home” link or button that enables the user to easily return to the portal home page. There is a Continue button below the table that lists references (recommender names) and statuses, but it is not clear what action the Continue button will perform or what page it may take the user to. 

Expected behavior: It should be clear to users what the Continue button is meant to do — if it is meant to return users to the portal home page, it would make more sense if the button were labeled something like “Return to home.” Or there should be a “Back” link or button at the top of the page to give users a quick and easy way to return to home.

Relevant accessibility guidelines: 

• • • Usability, affects all users and may especially impact users of assistive technologies

1.8 "Greater than" symbols are used in link text

When a decision update letter is available, there is a “View Update >>” link that appears on the portal home page, but the “>>” characters are not decorative images; they are “greater than” symbols inserted into the text. Their announcement as “greater greater” could be confusing or tedious for screen reader users, and it could make interacting with the link difficult for users of speech recognition software. 

Expected behavior: If a symbol must be used, consider using the right arrow (→) character instead, or don’t use any symbol at all. There are other ways to call visual attention to a “View update” link or button. 

Relevant accessibility guidelines:

• • • Usability, particularly impacting users of assistive technology

2. Recommendation submission (community/faculty/staff-facing)

2.1 PDF previewer does not allow screen reader to access document content

Slate’s PDF previewer does not allow screen reader software to access the document content, even when the PDF is a fully accessible document that would otherwise be readable in Adobe Acrobat. This results in an inequitable experience because the PDF previewer feature only benefits sighted people, while users of assistive technology would have to download the PDF and open it in a separate application in order to access the content.

Expected behavior: The PDF previewer should enable assistive technology access.

Relevant accessibility guidelines:

• • • Perceivable: Visual content that communicates meaning has a text equivalent that is communicated by assistive technology. (WCAG 1.1.1)
    • Perceivable: Information about content structure is communicated by assistive technology. (WCAG 1.3.1)
    • Robust: Web content is compatible with assistive technologies. (WCAG 4.1)

2.2 Illogical focus and reading order in PDF previewer navigation tools

When navigating through the PDF previewer navigation tools (next page, print, zoom in/out buttons, etc.), the buttons do not receive keyboard focus in a logical order that is consistent with their visual presentation. This also affects the order in which the buttons are announced by a screen reader.

Expected behavior: It generally makes sense for interactive elements to receive focus in top-down, left-to-right reading order. In this case, it might make sense to begin with the zoom in/out buttons, then jump to the page navigation arrow(s) and print button. 

Relevant accessibility guidelines:

• • • Perceivable: Assistive technology presents content to users in a meaningful order. (WCAG 1.3.2)
    • Operable: Elements receive focus in an order that preserves meaning. (WCAG 2.4.3)

2.3 Link to preview PDF opens in new tab without prior warning

The link to preview a PDF opens in a new tab without a prior warning for users of assistive technology like screen readers. There is a visual icon that indicates the link opens in a new tab, but this only benefits sighted users.

Expected behavior: When the link to preview a PDF has keyboard/screen reader focus, “opens in new tab” should be part of the link’s accessible label that is announced to screen reader users. 

Relevant accessibility guidelines:

• • • Perceivable: Visual content that communicates meaning has a text equivalent that is communicated by assistive technology. (WCAG 1.1.1)
    • Understandable: Make web pages appear and operate in predictable ways. (WCAG 3.2)

2.4 “Return” link in PDF previewer may cause confusion due to duplicate tab

Because the PDF previewer opens in a separate tab, it is confusing that the previewer tools contain a “Return” link. If a user selects the “Return” link, it does reload the user's previous page (in this case the recommendation submission form). However, this results in two tabs being open, and the user may be confused about which tab to continue their work in. 

Expected behavior: Consider whether the PDF previewer needs the “Return” link. While there may be an argument for keeping the “Return” link (i.e., it’s better for users to have two duplicate tabs open than none if they accidentally close the page), there might at least be a better way to label the button or provide instructions that let the user know what to expect. 

Relevant accessibility guidelines:

• • • Usability, affects all users and may especially impact users of assistive technologies

2.5 “Choose File” button lacks accessible screen reader label

The “Choose File” button does not have an accessible label that is announced to screen reader users. Before uploading a file, it is announced as “Invalid entry,” and after uploading a file, the button is announced as whatever the uploaded file name is. 

Expected behavior: The button should be announced as “Choose File” to a screen reader user. In addition to the button name, there should also be state announcements that indicate the current state, i.e., “Choose File, no file chosen” or “Choose File, current attachment is [file name].” 

Relevant accessibility guidelines:

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

2.6 Deletion of attachment is only visually indicated; no confirmation announcement for screen reader users 

When the user deletes an attachment, there is only a visual indication of this change (strikethrough text formatting). There is no confirmation announcement that immediately follows the deletion of the file, and if the user revisits the file upload section at a later time, there is no state announcement that indicates the attachment has been deleted. This could lead screen reader users to believe a deleted attachment is still there. 

Expected behavior: After deleting an attachment, there should be a prompt screen reader announcement that confirms the file’s deletion. Additionally, when the user revisits the file upload section, any previously deleted attachments should be announced with a state of “deleted” or “removed.” 

Relevant accessibility guidelines:

• • • Perceivable: Visual content that communicates meaning has a text equivalent that is communicated by assistive technology. (WCAG 1.1.1)
    • Robust: Make users of assistive technology aware of important changes in content. (WCAG 4.1.3)

2.7 No confirmation announcement upon saving or submitting a recommendation 

After saving a recommendation for later, there is no screen reader announcement that confirms the recommendation is saved. There is also no screen reader announcement after submitting a recommendation. 

Expected behavior: A visual success message should be accompanied by an auditory confirmation message provided to screen reader users after saving for later or submitting a recommendation.

Relevant accessibility guidelines:

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

2.8 Form input labels are not properly associated or announced in recommendation submission form 

In the recommendation form’s Likert scale questions (Applicant Ratings), the labels that correspond to each group of radio buttons are either missing or not properly associated. There is no label announced by a screen reader when the user enters each question grouping, so the user must switch into a different navigation mode and navigate backward to understand what question they’re answering. This could make filling out the form extremely tedious and frustrating for users of assistive technology. 

There are also other questions in the form with missing or improperly associated labels, such as the Overall Assessment radio button grouping and the signature (text entry) field. 

Expected behavior: When a screen reader user tabs into a text entry field or a group of radio buttons, the question should be announced so the user knows what question they’re answering with their selection or text entry.

Relevant accessibility guidelines:

• • • Perceivable: Information, structure, and relationships conveyed through presentation are communicated by assistive technology. (WCAG 1.3.1)
    • Understandable: Provide labels or instructions for inputs. (WCAG 3.3.2)
    • Robust: UI component names are communicated by assistive technology. (WCAG 4.1.2)

2.9 Poor reflow on mobile and at high magnification on desktop

At high levels of magnification (400%) on desktop and on mobile devices, two buttons become smushed into one “mega button” on the recommendation submission page. (Refer to barrier 1.4 for a screenshot of the “mega button” behavior.)

Relevant accessibility guidelines:

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

2.10 Fixed position of Recommendation Status box makes it difficult to view/interact with form on mobile and at high magnification on desktop

The Recommendation Status box has a permanently fixed position in the upper right of the page, which makes it difficult to view and interact with the form on mobile and at high levels of magnification (175% zoom or higher) on desktop. 

Expected behavior: The Recommendation Status box ideally should not be in a fixed (frozen) position on the page. Users should be able to scroll past it and not necessarily have it in view the whole time they are filling out the form. Alternatively, if the box remains in a fixed position, users should at least be able to dismiss or collapse/hide the Recommendation Status box so it takes up less space. 

Relevant accessibility guidelines:

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

3. Applicant-reported issue (student-facing)

3.1 Deleting an attached file in an application does not work unless attachment is replaced with another file 

When a user tries to delete a document that was previously saved in their application, the system does not actually remove the document unless the user replaces it with another file.

Expected behavior: The user should be able to remove attached documents, and the document should be deleted from the record. One of our users experienced a scenario where they had attached multiple documents and they wanted to remove one of them. They had to reach out for assistance because they could not delete the document in a way that would stick.

Relevant accessibility guidelines:

• • • Usability, affects all users and may especially impact users of assistive technologies