Class RoleNames
This is the toolkit's word and not the platform's, and it has to be, because two of the
three platforms cannot supply one. UI Automation localizes a control type itself and does it
well, so Windows uses this for the eight roles it has no word for at all. AppKit has
NSAccessibilityRoleDescription(), which looked like the answer until it was measured:
it localizes against the calling process's bundle, and a JVM launched from a jar has
none โ so on a wholly pt-BR desktop VoiceOver said "checkbox" and "slider" in English inside its
own Portuguese sentences. macOS therefore uses this for every role. AT-SPI2 needs none: its role
names are a fixed vocabulary that the reader translates.
Resolved under the node's own locale, not the ambient one (ยง1.7). A dialog in another
language names its own controls in that language, and the bridge answering a platform's question
is usually not on the user-interface thread โ so this goes through
I18n.resolve(String, String, Locale) rather than I18nString.get().
The English is the fallback and never a translation. A locale no scene has retained, or a language nobody has written a file for, answers the English word, which is a reader saying "button" in the wrong language rather than saying nothing.
-
Method Summary
Modifier and TypeMethodDescriptionstatic @Nullable StringenglishOf(Accessible.Role role) static StringkeyFor(Accessible.Role role) static Stringof(Accessible.Role role, Locale locale)
-
Method Details
-
keyFor
- Parameters:
role- a role- Returns:
- the key its phrase lives under,
limn.role.<lower-case-name>
-
of
- Parameters:
role- a rolelocale- the locale to speak in, which is the node's own and not the process's- Returns:
- the phrase, or the English when nothing translates it
-
englishOf
- Parameters:
role- a role- Returns:
- the English phrase, without consulting any bundle. For the tests that check the catalogue's own shape, and for a caller with no locale to speak of
-