Expose Name, Role, and Value for Custom Controls | BeforeMerge Rules | BeforeMerge

Explore
Accessibility
Expose Name, Role, and Value for Custom Controls

Expose Name, Role, and Value for Custom Controls

For all UI components, the name, role, state, and value must be programmatically determinable—use native elements or correct ARIA. (WCAG 2.1 SC 4.1.2)

Why This Matters

Screen reader users can't tell what a custom widget is, what it does, or its current state.

Related Rules

Use Semantic HTML Elements

Quality

HIGH

Add Alt Text to Images

Quality

HIGH

Ensure Keyboard Navigation

Quality

CRITICAL

Maintain Color Contrast Ratio

Quality

HIGH

Catch this automatically on every PR

BeforeMerge scans your pull requests against this rule and dozens more. Get actionable feedback before code ships.

Join Waitlist Browse All Rules

BeforeMerge

AI-native code review knowledge base. Structured rules that catch what linters miss.

Product

Features
Explore
Pricing
Docs
GitHub

Company

About
Blog
Contributors
Contributing

Legal

Privacy Policy
Terms of Service
MIT License

Peter Krzyzek

Features Explore

Rules Skills Knowledge Prompts

Pricing Blog Contributors Install Guide

Why this matters

Custom <div>-based toggles, tabs, and menus expose nothing to assistive tech unless given a role, accessible name, and live state. Prefer native elements; reach for ARIA only when no native option fits.

Good: <button aria-pressed="true"> or a proper ARIA tablist with synced state. Bad: a clickable <div> toggle with no role, name, or aria-* state.