Introduction

This document outlines key UX patterns used in our Intershop Progressive Web App, with a focus on accessibility and user guidance.
The goal is to provide a consistent and inclusive experience across all user journeys, while supporting users with a wide range of needs — including those who rely on screen readers, keyboard navigation, or other assistive technologies.

This guide focuses on design-level decisions and interaction patterns that go beyond technical compliance, aiming to improve clarity, predictability, and efficiency in the user experience.

Fundamental accessibility rules for development — such as color contrast, focus handling, semantic structure, and keyboard operability — are already covered in our Accessibility Easy Check Checklist and aligned with the Web Content Accessibility Guidelines (WCAG 2.2.).

For more general information about accessibility in the PWA, see Accessibility.

UX Patterns

Navigation Patterns

Skip Links for Long Listings

On pages with multiple content blocks, we provide "Skip listing" links before long sections, such as the filter list, account navigation, or quick order form.

The "Skip listing" link is generated by the <ish-skip-content-link> component that can be wrapped around any long listing or content block.

This skipping approach improves the user experience for the following reasons:

• Allows users to bypass repetitive or scroll-intensive content.
• Especially useful for keyboard and screen reader users.
• Makes navigation faster and less tiring.

Form Patterns

Focus Management on Validation Errors

On form submission, the focus automatically jumps to the first invalid field.

This approach was chosen because it:

• Reduces cognitive load and improves error recovery.
• Assists screen reader users in identifying errors efficiently.

Avoid Disabled Buttons

Buttons should generally remain active and focusable to improve usability, reduce cognitive load, and provide clear guidance for assistive technology users.
However, for short forms or optional secondary actions, disabling the button until the input is valid can be appropriate.

Large forms (8 fields or more, e.g., registration form):

• The submit button remains active, even if some fields are invalid.
• Focus moves to the first invalid field after submission to guide users in correcting errors.
• Inline error messages are provided next to each field and announced via aria-describedby.

Primary page button (e.g., Continue checkout):

• The button remains active at all times.
• Focus management and validation feedback are provided as needed.
• Accessible descriptions are provided via aria-describedby.

Short forms (e.g., login forms):

• The button is disabled if inputs are invalid.
• Focus moves to the first invalid field when the user attempts submission.
• Inline error messages are provided and announced via aria-describedby.

Optional forms and secondary actions (e.g., uploading a CSV file):

• The button remains disabled until the input is valid.
• Inline feedback and accessible descriptions are provided via aria-describedby.

Buttons disabled due to roles, rights, or rules (e.g., for deleting a cost center):

• Visually styled as disabled to indicate the button is inactive.
• The button remains focusable.
• Accessible descriptions are provided via aria-disabled, aria-describedby, and, for icons, the title attribute.

Reasons for this approach:

• Improves usability and reduces cognitive load by allowing repeated attempts on large forms and primary actions.
• Screen reader users remain informed when a button is inactive and understand why it cannot be used.
• Disabling buttons for short or optional forms ensures that users cannot submit invalid data while keeping the experience predictable.
• Error summaries are recognized as a good accessibility pattern, providing an overview of all errors; however, they are currently not implemented in our forms.

Password Autocomplete

Password input fields have autocomplete attributes enabled to support accessibility and modern security practices.

Rationale for enabling autocomplete:

• Reduces cognitive load and typing effort for users with disabilities and ensures a better user experience for all users.
• Supports WCAG Success Criterion 1.3.5 (Identify Input Purpose) by making form fields programmatically determinable (WCAG 2.2 compliance).
• Integrates with password managers, which store credentials securely and promote strong, unique passwords, reducing risks like password reuse or weak credentials.

The standard PWA prioritizes accessibility over PCI DSS requirements that suggest disabling autocomplete on password fields.
For more details on PCI DSS compliance, see the Security Standard PCI DSS 4.0 guide.

Component Behavior

Links with Icons Do Not Require Underlines

Text links that include a decorative icon, either leading or trailing (e.g., arrow, external link), are not underlined.

Reasons for this approach:

• Icons serve as a clear visual affordance for clickability.
• Avoids visual clutter while maintaining clarity.
• Still meets contrast and recognition standards for visual users.

Popovers Open on Click Instead of Hover

Interactive popovers (e.g., info bubbles) now open on click, not on hover.

Reasons for this approach:

• Hover interactions are not accessible on touch devices.
• Keyboard and screen reader users can now reliably trigger and dismiss popovers.
• Improves overall predictability and control for all users.

Summary

The patterns described here help ensure that our PWA is not only accessible in a technical sense, but also usable, predictable, and efficient for everyone.
Consistently applying these guidelines creates better experiences for all users while reducing friction for those who rely on accessible design.