Best practices for using buttons in your application and component reference material
Buttons enable users to execute specific actions directly on a page. By distinguishing buttons from links, using consistent styles, and following established patterns, we ensure that users can quickly identify actions and complete their tasks with confidence.
Keep these general principles in mind when using buttons:
Guideline | Best Practice |
---|---|
Usage | Use buttons for in-page actions only. Do not use buttons for navigation or links for in-page actions to avoid confusion. |
Alignment | Center-align text within buttons for a consistent, balanced appearance. |
Capitalization | Use title-case for button text (e.g., “Submit Form”, “View Account Details”). |
Abbreviations | Use abbreviations only if they are widely recognized (e.g., “FAQ”) and won’t confuse users. |
The primary button represents the most crucial action on a page.
Aspect | Best Practice |
---|---|
Usage | Reserve one primary button per page for the key action. Avoid multiple primary buttons to prevent confusion. |
Content | Use verb-first phrases connected to the page title. For example, “Submit Request” after a heading like “Request Access.” |
Style | Give the primary button a prominent color, and optionally include an icon to the left of the text for important actions. |
Visual Hierarchy | Ensure the primary button stands out the most, followed by secondary, then tertiary buttons. Place it prominently so it’s easily noticed. |
Secondary buttons support the primary action but are less critical.
Aspect | Best Practice |
---|---|
Usage | Use for safe, reversible actions. For irreversible actions (like “Delete Account”), prompt confirmation. |
Content | Secondary actions should complement the primary action, providing additional choices where appropriate. |
Style | Less prominent than the primary button, but still clearly visible. |
Visual Hierarchy | Secondary buttons rank below the primary button in prominence, guiding users first to the main action. |
Tertiary buttons are link-style buttons for less critical actions.
Aspect | Best Practice |
---|---|
Usage | Ideal for less critical actions or when multiple secondary actions might overwhelm the interface. Use sparingly for accessibility reasons. |
Content | Ensure the text is descriptive and actionable, e.g., “Edit Details” rather than “Edit.” |
Style | Styled as a link but behaves like a button. |
Visual Hierarchy | Less prominent than both primary and secondary buttons, providing low-priority actions without distracting from the main tasks. |
Do | Don’t |
---|---|
Keep buttons concise (3 words or less). | Overload buttons with lengthy instructions. |
Use title case to help buttons stand out. | Use all caps or sentence case for actions, which can reduce scannability and consistency. |
Limiting button text length ensures scannability and encourages providing context in surrounding elements on the page. Title-case styling helps users quickly identify and understand actions.
Blazor Telerik UI for Blazor Button Documentation | Button Accessibility - Telerik UI for Blazor
For technical details and integration guidance:
Buttons enable users to execute specific actions directly on a page. By distinguishing buttons from links, using consistent styles, and following established patterns, we ensure that users can quickly identify actions and complete their tasks with confidence.
Keep these general principles in mind when using buttons:
Guideline | Best Practice |
---|---|
Usage | Use buttons for in-page actions only. Do not use buttons for navigation or links for in-page actions to avoid confusion. |
Alignment | Center-align text within buttons for a consistent, balanced appearance. |
Capitalization | Use title-case for button text (e.g., “Submit Form”, “View Account Details”). |
Abbreviations | Use abbreviations only if they are widely recognized (e.g., “FAQ”) and won’t confuse users. |
The primary button represents the most crucial action on a page.
Aspect | Best Practice |
---|---|
Usage | Reserve one primary button per page for the key action. Avoid multiple primary buttons to prevent confusion. |
Content | Use verb-first phrases connected to the page title. For example, “Submit Request” after a heading like “Request Access.” |
Style | Give the primary button a prominent color, and optionally include an icon to the left of the text for important actions. |
Visual Hierarchy | Ensure the primary button stands out the most, followed by secondary, then tertiary buttons. Place it prominently so it’s easily noticed. |
Secondary buttons support the primary action but are less critical.
Aspect | Best Practice |
---|---|
Usage | Use for safe, reversible actions. For irreversible actions (like “Delete Account”), prompt confirmation. |
Content | Secondary actions should complement the primary action, providing additional choices where appropriate. |
Style | Less prominent than the primary button, but still clearly visible. |
Visual Hierarchy | Secondary buttons rank below the primary button in prominence, guiding users first to the main action. |
Tertiary buttons are link-style buttons for less critical actions.
Aspect | Best Practice |
---|---|
Usage | Ideal for less critical actions or when multiple secondary actions might overwhelm the interface. Use sparingly for accessibility reasons. |
Content | Ensure the text is descriptive and actionable, e.g., “Edit Details” rather than “Edit.” |
Style | Styled as a link but behaves like a button. |
Visual Hierarchy | Less prominent than both primary and secondary buttons, providing low-priority actions without distracting from the main tasks. |
Do | Don’t |
---|---|
Keep buttons concise (3 words or less). | Overload buttons with lengthy instructions. |
Use title case to help buttons stand out. | Use all caps or sentence case for actions, which can reduce scannability and consistency. |
Limiting button text length ensures scannability and encourages providing context in surrounding elements on the page. Title-case styling helps users quickly identify and understand actions.
Blazor Telerik UI for Blazor Button Documentation | Button Accessibility - Telerik UI for Blazor
For technical details and integration guidance:
For more examples, visit the Storybook.
The content of the button, typically text.
The size of the button.
The border radius of the button.
The type of the button.
If true, the button will be disabled.
If true, the button will render as a child component.
For more examples, visit the Storybook.
Gets or sets the child content.
Gets or sets the text of the button.
Gets or sets the tab index of the button.
Gets or sets the text for image alternate text.
Sets an icon.
Sets the icon color.
Sets an image for the button.
Gets or sets the button style. Options are Primary, Secondary, and Standard. Default is Standard.
Gets or sets the input type of the button. Options are Button, Submit, and Reset. Default is Button.
Gets or sets the size of the button. Options are Small, Medium, and Large. Default is Medium.
If true, disables this field on render.
If true, displays a busy indicator when this field is busy.
Gets or sets the busy text.