Custom Controls Labeled

Why It Matters

• Screen readers need names to announce. When a screen reader encounters a custom control without a label, it might say something like "button" or just silence — giving the user zero clue about what the control does.
• Labels provide context for sighted users too. Good labels often double as tooltips, placeholder text, or nearby visible text that helps everyone understand the purpose of a control, not just assistive technology users.
• It is a legal and ethical requirement. Accessibility standards require that all interactive controls have accessible names. Missing labels can create compliance issues and exclude people with disabilities from using your site.
• Custom controls are everywhere. Modern sites are full of custom widgets: color pickers, star ratings, drag-and-drop lists, autocomplete fields. Every one of them needs a label that explains what it does.

How to Label Custom Controls

1. Use aria-label for invisible labels. When there is no visible text to associate with the control, aria-label="Close dialog" gives the element a name that screen readers can announce.
2. Use aria-labelledby to point to visible text. If nearby text already describes the control, reference it with aria-labelledby rather than duplicating the text in an aria-label.
3. Pair icon-only controls with labels. A magnifying glass icon button needs aria-label="Search". A hamburger menu icon needs aria-label="Open navigation menu". Icons alone are not labels.
4. Make labels descriptive and unique. "Click here" or "Button" do not help. "Add item to cart" or "Toggle dark mode" tell the user exactly what will happen when they interact with the control.
5. Test with a screen reader. The best way to verify your labels work is to navigate your custom controls with a screen reader. If the announcements make sense without looking at the screen, your labels are good.

Common Mistakes

• Relying on title attributes as labels. The title attribute is not reliably announced by screen readers and is not a substitute for aria-label or aria-labelledby.
• Using generic labels. Labels like "input" or "control" do not tell the user what the control does. Every label should describe the specific purpose of that specific control.
• Forgetting to update labels when UI changes. If a toggle switches between "Mute" and "Unmute" states, the label needs to update too. A muted speaker still labeled "Mute" is confusing.
• Assuming visual design is sufficient. Just because a control looks obvious to sighted users does not mean it communicates anything to someone using a screen reader. Always provide explicit text labels.