Custom Controls Roles

Why It Matters

• Screen readers rely on roles to describe elements. A <div> with no role is just a generic container. A <div role="tablist"> is announced as a tab interface. Without the role, the user has no idea how to interact with it.
• Roles set user expectations. When a screen reader says "listbox," the user knows they can arrow through options. When it says "slider," they know they can adjust a value. The role tells users what behavior to expect.
• Native HTML elements have built-in roles. A <button> already has the button role. A <select> already has the listbox role. When you build custom versions, you need to manually provide what native elements give you for free.
• Missing roles create confusion. Without a role, a custom date picker might be announced as a series of meaningless text blocks. Users cannot figure out what they are looking at or how to use it.

How to Assign Roles Correctly

1. Use native HTML elements whenever possible. Before building a custom control, check if a native element already does the job. A real <button> is almost always better than a <div role="button">.
2. Pick the right ARIA role for the widget type. Use role="tablist" for tab interfaces, role="dialog" for modals, role="slider" for range inputs, role="menu" for dropdown menus, and so on. The WAI-ARIA specification defines dozens of roles for different widget patterns.
3. Pair roles with required ARIA properties. Many roles expect additional attributes. A role="slider" needs aria-valuemin, aria-valuemax, and aria-valuenow. A role="checkbox" needs aria-checked. The role alone is not enough.
4. Do not override semantic HTML roles. Adding role="button" to an <a> tag changes its announced purpose. Only do this when the element truly behaves as a button, not as a link.
5. Test with a screen reader. Navigate your custom controls using a screen reader to verify they are announced correctly. If the screen reader says the wrong thing, the role is wrong or missing.

Common Mistakes

• Using role="button" without keyboard support. A role sets expectations. If you mark something as a button, users expect it to respond to Enter and Space key presses. Adding the role without the behavior is worse than not adding it at all.
• Inventing roles that do not exist. ARIA roles must come from the specification. Making up role="fancy-dropdown" is meaningless to assistive technology and will be ignored.
• Applying multiple conflicting roles. An element should have one clear role. Assigning both role="button" and role="link" creates confusion about what the element actually is.
• Forgetting about child roles. Some roles require specific children. A role="tablist" should contain elements with role="tab". A role="menu" should contain role="menuitem" elements. The structure matters as much as the individual role.