A webpage should make sense even when someone cannot see its colors, pictures, or layout.
What You Need to Know
A button needs a clear action word, such as Save changes. The native button element already provides keyboard behavior. Avoid making something look clickable without also giving it the right meaning.
Try the Example
Take a look at the example. We’ll explain the important lines right below it.
<button type="button" id="download-button">Download report</button>
<button type="button" aria-label="Close notification">×</button>
<p>The second button has no descriptive text on screen, so it needs an accessible name.</p>Let’s Read the Code
- <button>: The button offers an action; its type or command determines what happens.
- type: Type changes what sort of control or resource the browser uses.
- id: An id uniquely identifies an element on this page.
What the example shows: A visible action name is usually the simplest, strongest button name.
What Happens in the Browser?
Try this with Tab and Shift+Tab. If you can, inspect the accessibility tree too; appearance alone does not tell the whole story.
What does assistive technology receive? The example includes aria-label. These relationships can explain names, states, or descriptions when used correctly. They do not automatically move focus, listen for clicks, or create keyboard handling.
Your Turn
Read both button names aloud without describing the icons.
Common Beginner Mistakes
- Judging the page only by how it looks, without checking its meaning and keyboard behavior.
- Do not name an action by appearance alone such as X or icon.
Key Takeaways
- A button needs a clear action word, such as Save changes.
- <button>: The button offers an action; its type or command determines what happens.
- Test the behavior you expect rather than trusting how the snippet looks in your editor.