Button
A button is a control you press to make something happen on the current screen.
A real example
When you press “Save draft,” the site saves your changes and tells you if it worked.
Main parts
- 01Visible label
- 02Interaction target
- 03Current state
- 04Keyboard behavior
Use it when
Use a button for actions such as submit, create, delete, or turn something on and off.
Do not use it when
Never use a button to go to another page. Use a link for that.
Name used in code
<button> Before you ship
Give assistive tools the control’s name (accessible name), purpose (role), value, and state. Check keyboard use, visible focus, target size, disabled and busy states, feedback, and recovery.
Outcome: Use Button to solve this user need without losing the current context. User context: When you press “Save draft,” the site saves your changes and tells you if it worked. Recommended pattern: Button. Why it fits: Use a button for actions such as submit, create, delete, or turn something on and off. Do not use it when: Never use a button to go to another page. Use a link for that. Product requirements: Define the default, loading, empty, error, success, and recovery states. Keep user input. Give clear feedback after every action. Accessibility and resilience: Use semantic HTML, full keyboard access, and visible focus. Make the layout work when zoomed and support reduced motion. Follow the project’s current rules. Do not add a new UI library unless the project already uses it. Acceptance criteria: The main task works with keyboard only and at 320px width. Focus and status changes are announced. Check loading, failure, retry, cancel, and reduced-motion paths. Evidence and limits (evidence boundary): The standard covers only the listed scope. It does not choose the visual style, product decision, or Vibulary example. Unknowns to confirm: Product wording, data source, analytics events, supported devices and languages, and platform limits.
Check this request
Review the current use of Button. Definition: A button is a control you press to make something happen on the current screen. Release checks: Give assistive tools the control’s name (accessible name), purpose (role), value, and state. Check keyboard use, visible focus, target size, disabled and busy states, feedback, and recovery. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.