Web button design covers how large a button is, how it looks in each state and what its label says. A good button is easy to hit, obvious in purpose and clearly different from the content around it.
Buttons carry the main actions on any page, which is why they are one of the first components to check when adapting web design templates. This guide covers size, spacing, states, contrast and wording.
Use real buttons for actions
The first decision is the element itself. MDN describes the button element as an interactive element activated by a user with a mouse, keyboard, finger, voice command, or other assistive technology, which then performs an action such as submitting a form or opening a dialog. A native button brings keyboard activation, focus handling and a recognisable role for screen readers without any extra code. The reference is the MDN page for the button element.
A common rule separates buttons from links. A link takes the visitor somewhere else, while a button does something on the current page, such as sending a form, opening a menu or toggling a setting. Styling a link like a button is acceptable for a prominent call to action that navigates, but the underlying element should still match the behaviour. A clickable generic container with a script attached loses the free behaviour a native element provides and must rebuild it by hand.
Inside a form, the type matters. MDN notes that a button inside a form without type=”button” acts as a submit button. Secondary actions such as clearing a field or opening a helper panel need an explicit type, otherwise they will send the form unexpectedly. How buttons fit into complete forms is covered in the guide to web form design.
Visual hierarchy follows from purpose. A page should present one primary action per view in the strongest style, with secondary actions in a quieter outline or text style. When every button shouts, nothing stands out, and visitors lose the cue that tells them where the main path continues.
Size and spacing for fingers and pointers
Small buttons are a frequent cause of mis-taps. The W3C sets a floor in its criterion on target size: the size of the target for pointer inputs is at least 24 by 24 CSS pixels, with exceptions such as inline links within text. The enhanced criterion goes further and asks for at least 44 by 44 CSS pixels. Both are documented on the W3C’s Understanding pages for target size (minimum) and target size (enhanced).
Google’s web.dev guidance on accessible tap targets suggests a minimum recommended touch target size of around 48 device independent pixels on a site with a properly set mobile viewport. It adds that an icon only 24 pixels wide can be brought up to that size with padding, and that touch targets should be spaced about 8 pixels apart, horizontally and vertically.
The approaches differ in numbers but agree in principle: the visible shape of a button can be modest as long as the clickable area is generous. Padding does this job without changing the look of the icon or text inside.
Spacing protects against wrong taps. MDN advises that large amounts of interactive content, including buttons, placed in close visual proximity to each other should have space separating them, which benefits people who may accidentally activate the wrong control. Two buttons that sit directly against each other, such as “Save” and “Delete”, are a particular risk, so they need separation and a visual difference in weight.
On narrow screens, full-width buttons often work well. They give a large target, line up with form fields and are easy to reach with a thumb. On wide screens the same button can shrink back to a width that fits its label, rather than stretching across the whole content area.
States: hover, focus, active and disabled
A button communicates through its states. Each one tells the visitor something different, and each needs a distinct look.
| State | What it signals | Design guidance |
|---|---|---|
| Default | The control is available | Clear boundary or fill that separates it from the page |
| Hover | A pointer is over the control | Subtle change in colour or shadow; never the only cue |
| Focus | The keyboard is on the control | Visible outline or ring with strong contrast |
| Active | The control is being pressed | Slightly deeper tone to confirm the press |
| Disabled | The action is not available | Reduced emphasis, with a nearby explanation of why |
The focus requirement comes from the W3C’s Understanding Focus Visible page, and MDN’s button reference covers the disabled attribute.
Focus deserves the most care. The W3C states that any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. Removing the browser’s default outline without a replacement fails this, and it leaves keyboard users guessing which button is selected. Test by pressing Tab through the page and watching for a clear indicator on every button.
Hover alone cannot carry meaning, because touch screens have no hover. Anything revealed only on hover, such as a label or extra action, needs another route for touch and keyboard users.
Disabled buttons need a light touch. MDN explains that the disabled attribute prevents the user from interacting with the button: it cannot be pressed or focused. A control that cannot receive focus is invisible to keyboard exploration, and greyed-out text is often too faint to read. Where possible, keep the button active and explain the problem when it is pressed, for example by naming the missing required field. If a button must be disabled, put the reason in text close by.
Loading states complete the picture. After a press that takes time, a visible change on the button, such as a short progress label, prevents double submissions and reassures visitors that something is happening.
Contrast and colour
A button has to be readable and recognisable. For its label, the W3C asks for text to have a contrast ratio of at least 4.5:1, with large-scale text allowed to meet 3:1, as set out in the Understanding page for contrast (minimum).
The button shape has its own rule. The criterion on non-text contrast requires a contrast ratio of at least 3:1 against adjacent colours for visual information required to identify user interface components and states. For a ghost or outline button, this means the border must stand out from the background; a pale grey line on white fails the test even though it looks tidy.
Colour should never be the sole signal. A red button for a destructive action works better when its label also says “Delete” and the confirmation names what will be removed. Visitors with colour vision differences, and those viewing under bright light, will not read the meaning from hue alone.
Brand colours often need adjustment to become buttons. A bright mid-tone fill may look lively in a logo yet fail against white label text. The guide to choosing a palette that stays readable explains how to test pairs before committing, and a darker shade of the same hue usually fixes the problem without losing the brand feel.
Labels that say what happens next
The words on a button matter as much as its shape. A good label is a verb phrase that states the result: “Send message”, “Download receipt” or “Create account”. Vague labels such as “Submit” or “Click here” leave visitors to infer the outcome from the surrounding text.
Keep labels short, and keep them consistent. Nielsen Norman Group’s heuristic on consistency says users should not have to wonder whether different words, situations or actions mean the same thing, and the Nielsen Norman Group article on consistency and standards explains it in depth. In practice, a site should not alternate between “Buy now”, “Purchase” and “Order” for the same step.
Icon-only buttons need special attention. MDN warns that buttons that only display an icon do not have an accessible name, which means a screen reader cannot announce their purpose. Adding visible text next to the icon is the most robust fix, and where space forces an icon alone, an accessible name must still be supplied through text or an ARIA attribute.
Capitalisation and punctuation should stay uniform. Sentence case reads naturally and handles long translations better than all capitals. Avoid terminal full stops on button text.
Finally, test the design in context. Presenting a design inside a browser frame shows how the button looks next to real content, as described in the guide to browser mockup templates, and a quick review on an actual phone reveals problems that a desktop preview hides.
Frequently asked questions
How large should a website button be?
At minimum, the clickable area should reach 24 by 24 CSS pixels under the W3C criterion, and many guidelines recommend larger, such as 44 by 44 CSS pixels or about 48 device independent pixels on touch screens.
Should a button be a link or a button element?
Use a button element for actions on the current page and a link for navigation. Styling can look identical, but the element tells browsers and assistive technology what will happen.
Is it acceptable to remove the focus outline?
Only if it is replaced with a clear alternative indicator. Without a visible focus state, keyboard users cannot see which control is active.
Should unavailable buttons be disabled?
Sometimes, but a disabled control cannot be focused and is often hard to read. Keeping it active and explaining the problem on press is often clearer.
Does this site supply button sets to download?
No. This independent site hosts no button graphics or files. It explains design principles that apply in any design tool or theme.
