More users can use the admin with the tools they need
Semantic structure: Headings, landmarks, and roles are used so screen readers can announce and navigate the interface. Buttons are buttons, links are links, and sections are identifiable.
Labels and announcements: Controls have accessible names (labels or aria attributes) where needed. Dynamic changes (e.g. success or error) can be announced so screen reader users get feedback.
No "accessibility mode": These patterns are part of the default experience. You don't enable "screen reader mode"; the admin is built to work with assistive tech from the start.
More users can use the admin with the tools they need. For everyone, everywhere.
<!-- seo-geo: content-enrichment -->
In practice
Language Management — semantic structure, labels and announcements, no accessibility mode. On this page, More users can use the admin with the tools they need is covered in detail: what it looks like in the admin, the exact controls it exposes, and how it behaves when you use it day to day. Because more users can use the admin with the tools they need is part of Multi-language & Accessibility — translated locales, keyboard navigation, screen-reader-friendly structure, and RTL support — the settings you touch here interact with the rest of the feature; when in doubt, open the feature overview and follow the docs in order.
Testing with a real screen reader
The patterns on this page are verified with NVDA on Windows and VoiceOver on macOS — the two screen readers most agencies can test without extra tooling. If you maintain a custom admin screen, run it through the same checklist: landmark navigation, focus visibility, and announced state changes cover most of what users report as "the screen reader missed it".
Accessibility regressions are treated as bugs — report them through contact support with the screen reader and version you used.
See also
Need a hand? Contact support or head back to the Multi-language & Accessibility guide.