Documentation

Kitchen Sink documentation of style: 'Delos' of skin: 'ILIAS'

Button

Purpose: Buttons trigger interactions that change the system’s or view's status. Acceptable changes to the current view are those that do not result in a complete replacement of the overall screen (e.g. modals).
Composition: Button is a clickable, graphically obtrusive control element. It can bear text.
Effect: On-click, the action indicated by the button is carried out. A stateful button will indicate its state with the engaged state.

Background: Wording rules have been inspired by the iOS Human Interface Guidelines (UI-Elements->Controls->System Button) Style rules have been inspired from the GNOME Human Interface Guidelines->Buttons. Concerning aria-roles, see: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role

glyph: Glyphs are used if the enclosing Container Collection can not provide enough space for textual information or if such an information would clutter the screen.
links: Links are used to trigger Interactions that do not change the systems status. They are usually contained inside a Navigational Collection.

Usage

Composition

Interaction

If an action is temporarily not available, Buttons MUST be disabled by setting as type 'disabled'.
A button MUST NOT be used for navigational purpose.

Wording

The caption of a Button SHOULD contain no more than two words.
The wording of the button SHOULD describe the action the button performs by using a verb or a verb phrase.
Every word except articles, coordinating conjunctions and prepositions of four or fewer letters MUST be capitalized.
For standard events such as saving or canceling the existing standard terms MUST be used if possible: Save, Cancel, Delete, Cut, Copy.
There are cases where a non-standard label such as “Send Mail” for saving and sending the input of a specific form might deviate from the standard. These cases MUST however specifically justified.

Style

If Text is used inside a Button, the Button MUST be at least six characters wide.
The Button MUST be designed in a way it is perceived as important and active, but not clickable, if the Button is engaged.

Accessibility

DOM elements of type "button" MUST be used to properly identify an element as a Button if there is no good reason to do otherwise.
Button DOM elements MUST either be of type "button", of type "a" accompanied with the aria-role “Button” or input along with the type attribute “button” or "submit".
If the Button is carrying the focus (e.g. by tabbing) and is visible it MUST always be visibly marked (e.g. by some sort of highlighting).
All Buttons visible in a view MUST be accessible by keyboard by using the ‘Tab’-Key.
The engaged state MUST be reflected in the "aria-pressed" -, respectively the "aria-checked"-attribute if active. If the Button is not engaged (which is the default), the aria-attribute can be omitted.

Parents

Descendants