Style a primary button with clear hover, active, disabled, and keyboard focus states without relying on color alone.
Requirements
Keep focus visible with :focus-visible
Make disabled buttons non-interactive
Do not remove the browser outline without a replacement
Show a hint
Write down the input contract and the failure cases before coding.
local runtime
RUNTIME OUTPUT
Use your CSS runtime locally, then compare with solution.css.
Use your local runtime, then review the reference solution
LEARN FROM THE SOLUTION
Why the solution works.
Each state has a distinct purpose: hover confirms pointer affordance, active gives immediate press feedback, focus-visible supports keyboard navigation, and disabled communicates unavailable action without silently hiding it.
What this exercise teaches
Pseudo-classes
Focus indicators
Accessible controls
A PRACTICAL PLAN
Work through Build a keyboard-friendly button with intent.
Translate the contract.Turn the requirements into a short checklist before editing your-solution.css.
Use the example as evidence.Predict the result for the supplied input, then add one boundary case such as an empty value, a limit, or unexpected input.
Review the implementation.Compare your choices against solution.css only after a real attempt.
EXERCISE FAQ
Before you move on.
What does “Build a keyboard-friendly button” teach?
This beginner CSS exercise focuses on Pseudo-classes, Focus indicators, Accessible controls. Its requirements define the exact behavior to implement before you write code.
How should I validate this CSS solution?
Apply the CSS to a small HTML fixture in your browser, check narrow and keyboard states, then compare the design decisions in solution.css.
When should I open the reference solution?
Attempt Build a keyboard-friendly button first. Then open the read-only solution file to compare the contract, edge-case handling, and implementation choices—not simply to copy the final code.
