Adding a button

Aus besondere tipps
Version vom 6. Mai 2021, 20:12 Uhr von Heiko (Diskussion | Beiträge) (Button checks extended.)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Adding a button[Bearbeiten]

check list[Bearbeiten]

  • Ensure that the button has a textual representation. That means it has either a text caption like ordinary buttons or an alt tag set that explains the image of the button. Why? AT has to describe the button to blind users in a text message. Speech recognition needs a name for the button so it can be called by voice command.
  • Ensure that every button in the user interface where the button lives has a unique textual representation. that means that two different buttons must not use the same name in a view or dialog. E.g. instead of having two buttons labelled "add" better use "Add heading", "Add text". Why? Many users of screen readers use special navigation dialogs so they can quickly reach an element with a given name. If two buttons have the same name the user doesn't know which he or she must pick to trigger the desired action. Also speech recognition software needs a unique identifier for the button to trigger the action. People with cognitive disabilities can find out the meaning of the button more easily because they need not read the context of the button. The same holds true for people that use a strong magnification, since they also can loose the context.
  • Ensure that the button can be reached by keyboard navigation e.g. by tabbing or swiping.
  • ensure that the button identifies itself as button either by using a native button or by assigning the aria role button. In short: Make sure that it not only looks like a button but also has all semantics of a button.
  • Ensure that the button can be activated by mouse, keyboard (space and enter when it has the focus) and also by speech recognition software.
  • Ensure that the button can be recognized even when using strong magnification or changed colors. Why? People with visual impairments often tweak the colors on the screen for easier reading and use high zoom factors. So try to use icons for buttons that are distinguishable even with high zoom factors.
  • Ensure that the button is big enough so that people with motoric disabilities can click the button. Why? Those users have difficulties in controlling the mouse. If the button is big enough they have better chances to hit the button.
  • If the button results in a dialog or opens other parts of the UI make shure that the focus is brought to that area. Why? A screenreader user won't notice a dialog that opens somewhere within the UI until it gets the focus.
  • If the button changes its state like pressed make sure that this state is also shown to the AT. This is done by special accessibility properties.

Here are some references: