Accessible component design means making reusable UI work for users with different input methods and assistive technologies instead of adding accessibility only after the interface has been completed. ### 1. Start with Semantic HTML Use native elements whenever they match the intended behavior: ```text Action → button Navigation → link Input description → label Page hierarchy → headings ``` This gives the component a strong accessibility foundation before ARIA is added. ### 2. Provide an Accessible Name Icon-only controls need understandable names. ```jsx ``` A screen reader user should understand what the control does without needing to see the icon. ### 3. Support Keyboard Use Ask: ```text Can I reach this control with a keyboard? Can I operate it? Can I see where focus is? Can I exit the component? ``` This is particularly important for: ```text Modals Dropdowns Menus Tabs Accordions Tooltips Custom selects ``` ### 4. Keep ARIA State Synchronized For an accordion: ```jsx ``` `aria-expanded` must match the actual UI state. Do not hard-code misleading accessibility state. ### 5. Manage Focus for UI That Changes Context When opening a modal: ```text move focus into modal ``` When closing it: ```text return focus to trigger ``` When showing a validation summary after submission: ```text consider moving focus to the summary or first invalid field ``` Focus changes should help navigation rather than surprise users. ### 6. Do Not Hide Focus Indicators Avoid: ```css button:focus { outline: none; } ``` unless another clearly visible focus style replaces it. ### 7. Make Dynamic Changes Understandable Suppose a form displays: ```text Profile saved successfully ``` without moving focus. A live region may help announce the change: ```jsx

{statusMessage}

``` Use live announcements selectively. Announcing every tiny UI update can become noisy. ### 8. Avoid Color-Only Meaning If status is represented as: ```text Green = Active Red = Failed ``` also provide text, icons with accessible names, or another understandable indicator. ### 9. Images Need Appropriate Alternative Text Meaningful image: ```jsx

``` Decorative image: ```jsx

``` The correct alternative text depends on the purpose of the image rather than simply describing every visual detail. ### 10. Reusable Components Should Own Reusable Accessibility Behavior If your design system provides: ```jsx ``` consumers should not need to rebuild its fundamental accessibility behavior every time. The reusable modal should handle appropriate concerns such as: ```text Dialog semantics Focus management Escape behavior Accessible labeling API ``` Similarly, reusable Tabs should coordinate the accessibility behavior expected from tabs rather than leaving every page to reinvent it. ### 11. Test Actual Interaction Automated accessibility checks are useful, but they cannot detect every usability problem. Also test: ```text Keyboard only Screen reader when possible Browser zoom Responsive layouts Form errors Focus behavior ``` ### 12. Accessibility Is Part of Component API Design Suppose a reusable icon button requires a label. Its API should make that easy: ```jsx ``` or require a dedicated accessible-label prop if that better fits the component library. Do not design APIs that make correct accessibility unnecessarily difficult. ### Practical Mental Model ```text Use semantic HTML first ↓ Ensure accessible names ↓ Make keyboard interaction work ↓ Manage focus when needed ↓ Add ARIA only where needed ↓ Keep ARIA synchronized ↓ Test real interaction ``` ### Interview-Ready Answer Accessible [React](/courses/reactjs) components begin with semantic [HTML](/courses/html), provide clear accessible names, support keyboard interaction, preserve visible focus, and manage focus when the UI changes context. ARIA should supplement native semantics rather than replace them. Reusable component libraries should encapsulate repeated accessibility behavior so every consumer does not have to implement it again.