Synonyms: Command button, push button

See also: Menu button, link, toggle switch, switch, tab, accordion

Buttons are used to execute a command (see DIN EN ISO 9241-161: 8.32).

A button consists of a text or graphic label and a visual indicator in order to identify the button as such. A border is usually used as a visual indicator for buttons.

Buttons can be used within other elements, e.g. in tables, tree structures, toolbars, scrollbars, tab panels containing tabs, accordions, input fields, spin buttons, drop-down lists and combined input fields. Deviating requirements concerning the buttons are described in the sections about these elements

Figure 30: Confirm button
No.PropertyDescriptionClassificationReference
@!482ContrastIf the button has a text label, this must have a contrast ratio of at least 4.5:1 with respect to the background.MustEN 301 549: 9.1.4.3, 11.1.4.3
@!483ContrastIf the button has a graphic label, this must have a contrast ratio of at least 3:1 with respect to the background.MustEN 301 549: 9.1.4.11, 11.1.4.11
@!484ContrastIf the button is only identifiable as such on the basis of its color design, the color must have a contrast ratio of at least 3:1 with respect to the neighboring colors.

Note 1: A button might be recognizable as an interactive element on the basis of its border or its background color, for example.

Note 2: The requirement does not apply if the button is clearly identifiable as a button, because of its position or labeling, for example.

MustEN 301 549: 9.1.4.11, 11.1.4.11
@!485LabelThe visible label of the button must correspond to or be contained in the name of the button which is communicated to the Accessibility API (see Label).MustEN 301 549 9.2.5.3, 11.2.5.3
@!486LabelIf the button has a graphic label, the button should have a tooltip with a text label.ShouldWCAG 2.1: 3.3.5 (AAA); DIN EN ISO 9241-143: 9.6.11
@!487Focus visibilityIf the button receives the keyboard focus, the focus indicator must be visible (see Focus indicator).MustEN 301 549: 9.2.4.7, 11.2.4.7
No.PropertyDescriptionClassificationReference
@!488Use of the keyboardIt must be possible to access, operate and exit the button with the keyboard (see Use of the keyboard table).MustEN 301 549: 9.2.1.1, 11.2.1.1, 9.2.1.2, 11.2.1.2
@!489Use of the keyboardFrequently used buttons should have a keyboard shortcut which is documented in the application and the Help option.ShouldDIN EN ISO 9241-171: 9.3.10
@!490Web: Use of the keyboardIt must be possible to skip areas of content with buttons that occur on several pages using the keyboard (see Practical tip: efficient navigation).MustEN 301 549: 9.2.4.1
@!491Use of the keyboardIf a window contains areas with several buttons, a mechanism should be implemented for skipping these page areas with the keyboard (see Practical tip: efficient navigation).ShouldDIN EN ISO 9241-171: 9.3.16, 9.3.17
@!492Use of the pointing deviceIt must be possible to undo or cancel the accidental enabling of the button. To do this, the button may only be enabled when it is released, i.e. only upon the up event and not upon the down event (see Use of the pointing device).MustEN 301 549: 9.2.5.2, 11.2.5.2
@!493UpdatesWhen the button is focused, no change of context may occur.MustEN 301 549: 9.3.2.1, 11.3.2.1
@!494UpdatesIf the enabling of the button causes a new window or a modal pop-up to open, the focus must be placed in the window and/or the pop-up (see Navigation sequence).MustEN 301 549: 9.2.4.3, 11.2.4.3
@!495UpdatesIf an unannounced change of context is performed through the enabling of the button within the current program interface, this must take place according to the current position of the keyboard focus, or the focus must be placed at the beginning of the updated area.MustEN 301 549: 11.2.4.3
@!496UpdatesIf an update is performed through the enabling of the button within the current program interface that requires an interaction on the part of the user, this should take place according to the current position of the keyboard focus. The keyboard focus should remain on the button or be placed at the beginning of the updated area (see Change of context).

Note: User interaction can mean reading a piece of information or the operation of interactive elements.

ShouldWCAG 2.1: 3.2.5 (AAA)
@!497UpdatesIf the button is removed from the program interface as a result of its enabling, the focus should be placed on a neighboring control element or on a control element with which the work can be continued in a coherent way.

Note: This applies, for example, to Delete buttons which refer to a single element.

ShouldWCAG 2.1: 3.2.5 (AAA)
@!498Click areaThe click area of the button should be at least 24 x 24 px (see Use of the pointing device).ShouldWCAG 2.2

Use of the keyboard: button

Permalink "Use of the keyboard: button"
ActionKeyClassification
Focusing of the buttonTABRequired
Exiting the buttonTABRequired
Enabling the buttonSPACE, ENTERRequired

Use of the pointing device: button

Permalink "Use of the pointing device: button"
ActionKeyClassification
Enabling the buttonLeft clickRequired
No.PropertyDescriptionClassificationReference
@!499RoleThe button role must be communicated to the Accessibility API (see Accessibility API).MustEN 301 549: 9.4.1.2, 1.4.1.2, 11.5.2.5
@!500StatusThe status of the button must be communicated to the Accessibility API (see Element status).MustEN 301 549: 9.4.1.2, 11.4.1.2, 11.5.2.5
@!501NameThe button must have a concise and expressive Accessible Name.MustEN 301 549: 9.2.4.6, 11.2.4.6, 9.4.1.2, 11.4.1.2, 11.5.2.
@!502NameIf the button has a description, it must be communicated as an Accessible Description.MustEN 301 549: 9.4.1.2, 11.4.1.2, 11.5.2.5
@!503NameIf the purpose of the button is determined by the visual context, this context must be communicated as part of the Accessible Name or Accessible Description.

Note: The Accessible Name of a button cannot, therefore, be simply “Close” or “Delete” if only the visual context indicates which element is closed or deleted. Instead, the Accessible Name must be “Close pop-up” or “Delete file [file name]”, for instance. Alternatively, the Accessible Description must contain a reference to the element which is to be closed or deleted.

MustEN 301 549: 9.1.3.1, 11.1.3.1, 9.2.4.6, 11.2.4.6, 9.3.3.2, 11.3.3.2
@!504Keyboard shortcutIf the button has a visually perceptible keyboard shortcut, it must be communicated to the Accessibility API.MustEN 301 549: 9.1.3.1, 11.1.3.1
@!505OperationIt must be possible to access, operate and exit the button with assistive technology (see Accessibility API).MustEN 301 549: 9.4.1.2, 11.4.1.2, 11.5.2.12, 11.5.2.17
@!506UpdateUpdates concerning the Accessible Name or status of the button must be communicated to the Accessibility API (see Accessibility API).MustEN 301 549: 9.4.1.2, 11.4.1.2, 11.5.2.15
@!507Desktop: PositionThe size and position of the button must be communicated to the Accessibility API (see Focus indicator).MustEN 301 549: EN 301 549: 11.5.2.5, 11.5.2.13

Practical tip: buttons in Web applications

Permalink "Practical tip: buttons in Web applications"
  • JAWS: [label] button [note on operation with the Enter key]
  • NVDA: [label] button | graphics button
  • Windows Narrator: [label] button

Please note:

  • The type of button (type=reset, type=submit, type=button) is not perceptible with the screen readers.
  • Only NVDA outputs the element <input type=image> as a “graphic button”.

The button should be implemented with the HTML elements <button> or <input type=button>. For graphic buttons, <input type=image> can be used. In forms, <input type=submit> and/or <input type=reset> can be used for the buttons for sending and resetting the inputs.

Label:

  • The labeling of the buttons that are labeled with <button> should take place using the text content.
  • The labeling of the buttons that are labeled with <input> should take place using the value attribute.
  • Buttons that are labeled with <input type=submit> or <input type=reset> do not need to be explicitly labeled because they are labeled automatically by the browser (with “Send” and “Reset”, for instance). The default labeling of the browser can be overridden with the value attribute, however. This is recommended if reference is made to these buttons in the application or the Help option, because the label of the buttons is otherwise different according to the browser.
  • In the case of graphic buttons, the labeling takes place using the alternative text of the graphic (e. g. <input type=image alt=…> and/or <button><img alt=…></button>) or with aria-label. It should be noted that the button label does not describe the graphic, but the purpose of the button.
  • The labeling of the buttons should be concise, unambiguous and expressive. Buttons labeled “Click here” or “Detailed view” are not considered expressive. The label should either be expressive (e.g. “Detailed view of Joe Bloggs”), or the description should explain the purpose of the button (with aria-describedby or title, for example).

Status and type:

  • Buttons can be marked as disabled (disabled).
  • With buttons that are used for navigation or pagination, aria-current can be used to mark the button which refers to the current element.
  • Buttons that are used to show and hide areas should be marked with aria-expanded to communicate the status of the areas (shown or hidden).
  • Buttons that open a pop-up should not be labeled aria-haspopup, even if the attribute is intended for that purpose. This is because, when combined with a button, aria-haspopup causes the element to be output as a menu button. Instead, links should be used with aria-haspopup r buttons that have a text note in the description.

Further information: 4.10.6 The button element - HTML Standard (whatwg.org), 4.10.5.1.21 Button state (type=button) - HTML Standard (whatwg.org), 4.10.5.1.19 Image Button state (type=image) - HTML Standard (whatwg.org), 4.10.5.1.18 Submit Button state (type=submit) - HTML Standard (whatwg.org), 4.10.5.1.20 Reset Button state (type=reset) - HTML Standard (whatwg.org)

If the button is not implemented with the HTML element, in addition to the notes on HTML buttons, it is necessary to take account of the following:

  • The role is communicated with role=button.
  • Disabled buttons can be marked with aria-disabled.
  • The buttons should be visually marked (with a border, for example) so that their role is also perceptible with the use of Windows Contrast Adjustment.

Further information: button role - Accessible Rich Internet Applications (WAI-ARIA) 1.2 (w3.org), Button Pattern | APG | WAI | W3C

Information about this article

You are welcome to send feedback by email about our handout!