Check buttons and forms with a keyboard before you publish
A focused review of native controls, visible labels, focus indicators, form errors, and reduced motion using a small contact form as the example.
An interface can look polished while leaving a keyboard user unable to reach a control or understand a field. A short keyboard review catches practical problems early. It is one part of accessibility work, not a complete certification of the page.
Begin with the element’s job
Use a link when the visitor is going somewhere and a button when the visitor is performing an action. A card that opens a project page needs a destination; a control that changes a preview setting needs an action. Styling a div to look like a button does not give it normal button behavior.
<a href="/templates">Browse templates</a>
<button type="button">Reset preview</button>The reset action still needs an implementation, but the native button supplies a useful interaction foundation. Specify its type so it does not accidentally submit a surrounding form. Keep its label specific enough to understand without the surrounding artwork.
Make labels stay visible
In a contact form, a placeholder can show an example address, but it disappears when typing starts. Use a visible label connected to the field. Give the input a meaningful name if it is part of a real submission.
<label for="inquiry-email">Email address</label>
<input id="inquiry-email" name="email" type="email"
autocomplete="email" placeholder="you@example.com" required>Write a separate hint if you need to explain why the address is requested. The W3C guidance on labeling controls explains the underlying label relationship.
Keep the focus indicator
Press Tab from the beginning of the page and follow the focus through the interface. You should be able to see which control is active at every step. If a reset stylesheet removes the outline, replace it with a deliberate visible treatment rather than leaving focus invisible.
.contact-form :focus-visible {
outline: 3px solid #2563eb;
outline-offset: 3px;
}Inspect this outline against the actual background and around clipped or rounded containers. It should not be cut off by a parent’s overflow rule. A pointer hover effect is not enough because it does not show where keyboard focus is located.
Try failure, not only success
Submit an empty form, an incorrectly formatted address, and a message that is longer than expected. Errors should describe the problem in words and remain near the affected field. Red borders alone cannot explain what went wrong. When a network request fails, preserve the entered message and provide a way to try again.
A visual form template does not provide a backend, spam protection, or secure validation. Add those in your application and test a real submission before showing the form to customers.
Check movement and interruptions
Transitions should not delay access to content, and a loading state should communicate what the application is doing. Respect visitors who prefer less movement; use a simple alternative when the effect is decorative. See MDN’s reduced-motion reference for the media feature.
If a task needs a modal dialog, review focus movement, dismissal, and focus restoration as well as its visual overlay. The W3C dialog pattern covers expectations that a styled panel alone cannot meet.
Keep a repeatable review
For a small page, write down the controls in the order you expect to use them. Compare that order with a keyboard pass at desktop and mobile widths. Add a longer label, increase zoom, and repeat the test. Use the button generator for appearance and the form generator for layout, then review behavior in the real page.