Question
Amazon Connect CCP ↔ Custom UI Component: Is Screen Reader Support Guaranteed?
Nia Byte
0 reputation · 23 Jul 2026, 20:30 UTC
99.8K views1
Loading…
0 reputation · 23 Jul 2026, 20:30 UTC
The goal is to ensure that agents using Amazon Connect’s Contact Control Panel (CCP) with screen readers can interact with both the default controls and any custom UI elements added through the SDK. The default CCP implements ARIA attributes for core call controls and status indicators, and offers keyboard navigation and high‑contrast mode. However, the SDK documentation states that developers must explicitly add ARIA labels to custom components for full accessibility coverage. This raises uncertainty about whether screen readers will automatically recognize custom widgets or if they will be inaccessible without manual ARIA implementation. Additionally, high‑contrast and text‑size adjustments may not propagate to third‑party widgets, potentially creating gaps in visual accessibility. The following questions remain:
1. Does the Amazon Connect SDK automatically apply ARIA roles to custom components, or is explicit labeling required in every version?
2. Will high‑contrast mode and text‑size settings reliably affect custom widgets embedded in the CCP?
3. Are there known browser‑specific differences in screen‑reader behavior for custom CCP components?
33775 reputation · 24 Jul 2026, 03:31 UTC
No, screen reader support is not guaranteed for custom UI components added via the Amazon Connect CCP SDK. While the default CCP provides ARIA attributes for its core controls, these accessibility features do not extend automatically to developer-implemented widgets.
When extending the CCP with a custom UI, the responsibility for accessibility shifts from AWS to the developer. The following distinctions apply to the implementation:
The Amazon Connect SDK does not inject ARIA roles, labels, or descriptions into custom HTML elements. If you add a custom button or status indicator, it will be invisible or unlabeled to a screen reader unless you explicitly define the appropriate attributes (e.g., role="button", aria-label="End Call"). This is true across all current SDK versions.
High-contrast mode and text-size adjustments do not automatically "force" a custom widget to be accessible. The behavior depends on your CSS strategy:
awsem, rem) or inheriting from the parent container will generally respect text-size changes.While modern browsers (Chrome, Firefox, Edge) generally handle ARIA consistently, behavior can diverge regarding ARIA live regions (used for real-time call status updates). Some screen readers may prioritize default CCP announcements over custom live regions depending on the browser's accessibility tree implementation.
To ensure your custom components meet accessibility standards, perform these targeted checks:
role and a descriptive aria-label.Diagnostic Detail Needed: Are you using a third-party UI framework (e.g., Material UI, Tailwind, Bootstrap) for your custom components? Some frameworks provide built-in accessibility primitives that simplify this process, while others require manual overrides to prevent CSS collisions with the CCP.
Use comments to ask for clarification. Post a solution as an answer.
5,760 reputation · 23 Jul 2026, 20:57 UTC
The Amazon Connect Streams API (v1.10+) provides connect.core.getAccessibilitySettings() and connect.core.onAccessibilitySettingsChanged to read the CCP’s high‑contrast toggle and font‑scale value. Custom UI components do not receive these settings automatically; they must subscribe to the event and apply the returned values (e.g., toggle a .high-contrast class or adjust font-size using rem units).
Additionally, for screen readers to reach the custom markup inside the CCP iframe, the iframe itself needs a meaningful title attribute (and, for JAWS, role="application") so the accessibility tree includes the inner document. Without this, even perfectly ARIA‑labelled inner elements may be ignored.