Accessibility
- New
- Explanation
- 6-min read
Dynatrace is committed to building products that are accessible to everyone. We strive to conform with WCAG 2.2 Level AA, the internationally recognized standard for digital accessibility, and we verify our compliance through independent audits. See the Dynatrace Trust Center to learn more about our public commitment to accessible product design and development.
Strato, our design system, is designed for accessibility. The more you use Strato components, the more requirements are satisfied out of the box, reducing the work needed to build accessible, compliant apps.
How to use this page
The sections below describe important accessibility requirements and example Strato components to which the requirement applies. As you design and build apps, always check the documentation for individual Strato components for component-specific guidance and best practices.
Accessible names and roles
Every interactive control must have an accessible name and a correct semantic role. The accessible name is what assistive technologies, such as screen readers, announce to users.
This requirement is met by providing appropriate ARIA labels for icon-only controls, verifying that visible text and accessible names are in sync for text-based controls, and making sure tooltip text matches its corresponding label. Specific requirements vary depending on whether the control uses an icon only, text only, or a combination of icon and text.
| Example components | Documentation |
|---|---|
| Button | Button |
| HelpMenu | HelpMenu |
| IntentButton | IntentButton |
| RunQueryButton | RunQueryButton |
Form field labels
Input fields should have visible and persistent labels. This supports users who may need to refer back to a label while entering data. Placeholder text alone never substitutes for a proper label, since placeholders disappear when users start typing.
For compliant labelling out of the box, use the FormField component plus an appropriate form component inside it. See the individual Strato component documentation for component-specific guidance on labels, placeholders, and hints.
| Example components | Documentation |
|---|---|
| FilterField | FilterField |
| FormField | FormField |
| NumberInput | NumberInput |
| PasswordInput | PasswordInput |
| SearchInput | SearchInput |
| TextArea | TextArea |
| TextInput | TextInput |
Keyboard accessibility and focus
All functionality must be accessible using a keyboard alone. Users who can't use a pointer device such as a mouse rely entirely on keyboard navigation. The focus indicator must always be visible so users can see where they are on the page.
Strato components are designed to meet the two WCAG 2.2 AA focus requirements that focus indicators must meet minimum size and contrast thresholds, and focused elements must never be fully obscured by overlapping content.
You can further ensure a good, accessible experience by maintaining a logical tab order, never trapping keyboard focus, and keeping a clearly visible focus indicator at all times. Follow established keyboard patterns for composite components such as menus, tab panels, and data grids.
| Example components | Documentation |
|---|---|
| DataTable | DataTable |
| Menu | Menu |
| Modal / Dialog | Modal |
| Tabs | Tabs |
State announcements
When a control changes state, for example when a menu opens or an accordion section expands, that change must be communicated programmatically so screen readers can announce it. Without the appropriate state announcement, users who rely on assistive technology wouldn't know whether a panel is open or closed, or whether an action has taken effect.
We support this requirement by ensuring the correct ARIA state attributes on interactive components, so that expanded, collapsed, open, and closed states are conveyed to assistive technologies alongside the control's label.
| Example components | Documentation |
|---|---|
| Accordion | Accordion |
| FilterField | FilterField |
| HelpMenu | HelpMenu |
| IntentButton | IntentButton |
| Menu | Menu |
| SegmentSelector | SegmentSelector |
| TimeframeSelector | TimeframeSelector |
Interactive elements and ARIA
ARIA (Accessible Rich Internet Applications) attributes help make complex and custom UI patterns accessible by communicating roles, states, and properties to assistive technologies. Used correctly, ARIA bridges the gap between custom interactions and the accessibility tree. Used incorrectly, ARIA can mislead assistive technologies and create a worse experience than using no ARIA at all.
To provide high-quality experiences for all users, follow established ARIA authoring patterns for all components, apply tabindex values deliberately and conservatively, and avoid nesting interactive elements inside one another.
Color and status
Color must never be the only way to convey status or meaning. Users with color blindness or low vision may not be able to distinguish between colors, so status must also be communicated with text, an icon, or both.
To ensure that status indicators are accessible, always pair color with a descriptive text label or icon. At the same time, avoid adding redundant icons if a text label already makes the status clear. This keeps the interface clean without sacrificing accessibility.
| Example components | Documentation |
|---|---|
| HealthIndicator | HealthIndicator |
| InformationOverlay | InformationOverlay |
| TerminologyOverlay | TerminologyOverlay |
Alternative text for images
Alt text is the text equivalent of an image. It tells assistive technologies what the image means or does in its specific context, rather than simply describing what it looks like. Images that are purely decorative should be hidden from assistive technology so they don't create unnecessary noise.
Always provide clear, informative alt text for images (except for purely decorative images, which should be hidden from assistive technology), and ensure that no critical information — particularly instructional text — exists only within an image file.
Target size
Interactive controls must meet a minimum target size so they can be reliably activated by users with limited dexterity or those using touch input. This is a WCAG 2.2 AA requirement.
Strato components are designed to meet the minimum 24×24 CSS pixel target size requirement by default. Always keep the minimum target size requirement in mind if you customize component size or density, and build custom controls.
Drag and drop
Any functionality that relies on drag and drop must also be achievable without dragging, to support users who can't perform precise pointer movements. This is a WCAG 2.2 AA requirement.
Ensure this by providing equivalent alternative interactions — such as menu-based move actions or keyboard-operable drag handles — alongside any drag-and-drop functionality, so all users can complete tasks.
| Example components | Documentation |
|---|---|
| DataTable | DataTable |