When a button shows one phrase but its accessible name uses unrelated words, a person may speak the words they can see and still reach the wrong control—or no control at all. Matching the spoken name to the visible label makes a club or game help screen easier to understand, especially when several buttons appear together.
Why the wording matters
Consider this clearly hypothetical help panel. One button visibly says Open glossary. Its accessible name is Open glossary of card terms. The extra context is acceptable because the accessible name still contains the words shown on the button, preferably at the beginning.
A second hypothetical button visibly says Open glossary, but its accessible name is Reference tools. A person reading the screen may say “Open glossary”, while assistive voice software is expected to recognise “Reference tools”. The reader cannot infer that unrelated accessible name from the visible words.
A practical comparison for help controls
| Visible label | Accessible name | Clarity |
|---|---|---|
| Open glossary | Open glossary of card terms | Clear match |
| Open glossary | Reference tools | Unclear mismatch |
| Read safety prompt | Read safety prompt before continuing | Clear extra context |
This is a naming issue, not a claim that any particular Jai Club Games screen or app has been tested. For a hypothetical interface, a useful check is simple: read the visible button text, then compare it with the control’s accessible name. If the visible words are included, a spoken request based on the screen has a better chance of identifying the intended control. The name does not need to be identical, but unrelated wording is harder to interpret.
Reference
WCAG 2.2 Success Criterion 2.5.3 says that a control with a visible text label should have an accessible name containing that visible text. The W3C guidance also identifies placing the visible label at the beginning as a good practice. W3C guidance on Label in Name