Accessibility

Accessibility (a11y) is the practice of enabling products to be used by people with disabilities. It provides a way for all users to interact with the product, including those who require assistive technologies. Web accessibility focuses on how people with disabilities perceive, understand, navigate, and interact with web-based UIs.

Commitment to WCAG 2.1 Level AA

Blue Yonder invests at two levels to make its products compliant with WCAG 2.1 conformance level AA:

• Platform level — Regular audits of experience system foundation, components, and patterns. Automatic tests of implemented components (Performative Audit to highlight issues and related guidelines).
• Product level — Regular audits of existing products, services, and tools using design specification and code review.

Platform level

Foundation

At the experience system foundation level, accessibility is ensured by monitoring the following aspects:

• Color usage — Experience system colors are tested for both contrast issues and color-blind sensitivity. Foreground text should meet WCAG contrast ratios of 3:1 for large text and 4.5:1 for normal text against the background color.
• Theming — The experience system supports light and dark themes. The default theme for applications is the light theme.
• Illustrations and icons — Avoid using illustrations and images as the only method to convey information, and do not use images that contain text information.
• UX writing — Avoid UPPERCASE labels in components, because uniformly shaped text takes longer for users with cognitive and visual impairments to read. For the same reason, avoid center-aligned text or justified paragraphs (blocks of text). Instead, use left-aligned or right-aligned text according to the user’s locale.

Experience system components

At the experience system component level, accessibility checks and reviews are integrated during the design and development process.

• Component design reviews — Design concepts are reviewed in Figma on a regular basis. The reviews help the design team define meaningful labels, placeholders, and tooltips, and to address color contrast issues.
• Automated accessibility testing — Automated testing supplements, but does not replace, manual accessibility testing. Automated testing validates whether the code is technically compliant, while manual accessibility testing focuses on usability issues. For example, automated testing can identify the presence of alt text for an image, but it cannot determine whether that alt text is relevant to the user. The axe automated testing tool is used to run automated accessibility testing alongside functional testing of components.
• Development support — UX works with development teams to support component focus and keyboard operability. To make components compatible with screen readers, alt text is added to graphical content and landmarks such as header, footer, form, and sidebar are defined to provide a meaningful semantic overview of each page or part of a page.

Product level

To meet accessibility standards, regular audits of products are performed before release to investigate the following aspects:

• Screen reader compatibility — Even when application developers use standard components from the experience system, customizations for each use case may lead to undesired accessibility effects.
• Keyboard navigation — The application should support sequential navigation using the keyboard. Interactive elements must be focused according to the hierarchy to help the user complete their intended task. Focus should be supported by all input devices.
• Custom component audit — Product teams can build custom components to meet their use cases. In these cases, automated and manual accessibility testing are offered to ensure that the new components are accessible.

---

Integration in the design process

An overview diagram of how accessibility fits into the design process (A11Y Infographic) is published on the Accessibility (UXD Confluence) page.

Resources

Related articles

External resources and tools