DesignPLUS Accessibility Evaluation

Date evaluated: 11/24/25

Overview

This document contains the findings of an accessibility evaluation performed by the Center for User Experience (UX). We evaluate 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, and 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.

For more about WCAG conformance refer to: https://www.w3.org/WAI/WCAG21/Understanding/conformance#levels

Test conditions

• Device: MacBook Pro 16”
• Operating system: Tahoe 26.1
• Web browser: Chrome
• Screen reader: VoiceOver

Elements we reviewed

1. Sidebar (instructor facing)
2. Upload/embed (instructor facing)
3. Multi Tool (instructor facing)
4. Landing page designed with template (student facing)

Accessibility and usability barriers

Element 1: Sidebar

Usability barrier - confusingly named button 

Barrier: The parenthetical text on the button for opening the DesignPLUS sidebar is read aloud by the screen reader as the button name.

This barrier would primarily relate to the following accessibility guidelines:

• Understandable - User interface components and navigation must be understandable.

Expected behavior: The parenthetical short cut listed on the button helps sighted users know how to access the shortcut in the future. However, hearing the shortcut read by a screen reader as the button name is a very confusing experience. I would expect the button to read to a screen reader user “Open DesignPLUS,” rather than reciting the keyboard shortcut as though it were part of the name. Find a way to help screen reader users know the shortcut without having it read as the button name.

Keyboard navigation barrier 

Barrier: When navigating by keyboard, the user encounters a hidden link which looks clickable (and is announced as a link), but which only suggests a keyboard shortcut. Seeing the button next to the text makes a user assume they can tab to the button next. Instead, the user has to tab through the whole interface to arrive at the button. 

This barrier would primarily relate to the following accessibility guidelines:

• Understandable - User interface components and navigation must be understandable.

• Operable - User interface components and navigation must be operable.

Expected behavior: I would expect to be able to get to the button right after the link. The “link” (which is not clickable) is instead serving as a tool tip. The user cannot click the link, though the screen reader announces it as a link. I would expect no link, but simply access to the button earlier in the tabbing order. Recommend finding another way to create a tool tip for the keyboard shortcut.

Usability barrier - confusing notification

Barrier: “You have 1 notification. Select this to skip to the footer” doesn’t make sense when a user begins tabbing through the interface. 

This barrier would primarily relate to the following accessibility guidelines:

• Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

• Operable - User interface components and navigation must be operable.

• Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Expected behavior: There is a lack of consistent naming for notification and footer, and no antecedent to the pronoun “this.” “Skip to the footer” doesn’t make sense in the context of exploring the panel. Micro-copy like “Read and close notification” might be more descriptive. 

Keyboard navigation barrier

Barrier: Mouse is required to scroll to further options until the notification is dismissed. A user is given the option to dismiss the notification earlier, but the text is confusing. Reaching the notification by keyboard after dismissing the option to go to the footer takes a long time by keyboard navigation.

This barrier would primarily relate to the following accessibility guidelines:

• Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

• Operable - User interface components and navigation must be operable.

• Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Expected behavior: I expect to always be able to see my keyboard focus, and not for keyboard focus to move behind an element.

Magnification barrier

Barrier: When magnified beyond 250% the full content of the contextual menu is not visible, nor can a user scroll to see if there are more menu items. The logo also becomes very pixilated. 

This barrier would primarily relate to the following accessibility guidelines:

• Perceivable - User interface components and navigation must be perceivable.

• Operable - User interface components and navigation must be operable

Expected behavior: I would expect to have access to all menu items. WCAG 2.1 AA standards suggest full functionality up to at least 400%.

Element 2: Upload/Embed

The tester found no barriers while reviewing this element.

Element 3: MultiTool

The tester found no barriers while reviewing this element.

Element 4: Landing page (student facing)

The tester created a home page from the templates, then tested the resulting home page. The tester found no barriers while reviewing this element.