Senior FE WCAG Flashcards
(174 cards)
1
Q
What does WCAG stand for?
A
Web Content Accessibility Guidelines – a technical standard by W3C outlining how to make digital content accessible. Most organizations aim to meet WCAG 2.1 Level AA.
2
Q
What does WCAG cover?
A
Guidelines for accessibility like text alternatives, keyboard navigation, color contrast, focus management, and screen reader support.
3
Q
What are the four principles of WCAG?
A
POUR
1. Perceivable,
2. Operable,
3. Understandable,
4. Robust
4
Q
What does “WCAG 2.1 Level AA” refer to?
A
A set of accessibility guidelines that include required criteria for mid-level compliance, ensuring broad accessibility without being overly strict.
5
Q
What types of disabilities does WCAG 2.1 address?
A
Visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.
6
Q
What are ARIA roles?
A
Attributes used to define accessible web content and applications for users with assistive technologies.
7
Q
When should ARIA roles be used?
A
When native HTML elements don’t provide the needed accessibility functionality.
8
Q
What is the difference between ARIA roles and semantic HTML?
A
Semantic HTML is preferred because it has built-in accessibility;
ARIA should be used as a supplement, not a replacement.
9
Q
What is the purpose of ARIA attributes like aria-label, aria-hidden, or aria-live?
A
To improve screen reader interaction by describing elements, hiding content, or notifying updates dynamically.
10
Q
What does “accessible design” mean?
A
Designing digital experiences that can be used by as many people as possible, regardless of disability or impairment.
11
Q
What is Section 508?
A
Section 508 is a U.S. federal law that requires all electronic and information technology developed, procured, maintained, or used by federal agencies to be accessible to people with disabilities.
12
Q
What is ADA compliance?
A
Adherence to the Americans with Disabilities Act, ensuring equal access to digital content for individuals with disabilities.
13
Q
What is accessibility remediation?
A
It’s the process of identifying and fixing existing accessibility issues in a product to ensure compliance with WCAG and legal standards like ADA or Section 508.
14
Q
What does “compliance” mean in the context of accessibility?
A
Meeting the legal and technical standards defined by WCAG, ADA, Section 508, etc.
15
Q
What is the difference between aria-label and aria-labelledby?
A
aria-label provides an explicit text label directly on the element;
aria-labelledby references the ID of another element to derive the label.
16
Q
How does aria-hidden="true" affect screen readers?
A
It hides the element and all of its children from screen readers, even though they remain visible visually.
17
Q
What is the effect of setting tabindex="-1" on an element?
A
It removes the element from the tab order but allows it to receive focus programmatically.
18
Q
When would you use role="button" in combination with JavaScript?
A
When using a non-semantic element (like <div> or <span>) as a button, you must also manage keyboard interactions (Enter/Space) and focus styles manually.
19
Q
How does a screen reader interpret <button aria-pressed="true">?
A
It reads the button as a toggle and announces it as “pressed” to the user, helping convey state.
20
Q
What HTML element should be used for dynamic content that needs to alert screen reader users?
A
Use a container with aria-live="polite" or aria-live="assertive" to announce content changes.
21
Q
What’s the difference between aria-live="polite" and aria-live="assertive"?
A
polite waits until the user is idle to announce changes; assertive interrupts the screen reader immediately.
22
Q
Why is semantic HTML preferred over ARIA roles?
A
Semantic elements (like <button>, <nav>, <main>) have built-in accessibility support and behaviors, reducing the need for custom scripting or attributes.
23
Q
What are some common ARIA roles used in UI components?
A
role="dialog", role="alert", role="button", role="tablist", role="tabpanel", role="checkbox", etc.
24
Q
What is “focus trapping” and when should it be used?
A
Focus trapping keeps keyboard navigation within a container (e.g., modal) until it’s closed, ensuring users don’t tab out of context.
25
How do you make a custom modal accessible?
To make a custom modal accessible:
- Use `role="dialog"` to indicate it's a dialog window.
- Add `aria-modal="true"` to notify assistive technologies that the rest of the app is inert.
- Use `aria-labelledby` to reference the modal's title.
- Use `aria-describedby` to reference additional descriptive content (optional but recommended).
- Trap focus inside the modal while it’s open, and return focus to the triggering element when closed.
- Ensure the modal can be dismissed with the Escape key.
**Example:**
```
```
Delete Item
Are you sure you want to delete this item? This action cannot be undone.
26
What is skip navigation and how is it implemented?
It's a link at the top of the page that allows keyboard users to skip repetitive content. Implement it with an anchor link like `Skip to main content`.
27
What are some common keyboard interaction expectations for accessible components?
Use `Tab` to move focus, `Enter`/`Space` to activate buttons, arrow keys for navigating menus or tablists, and `Esc` to close modals.
28
How do screen readers interpret visually hidden elements?
If the element is hidden with `visibility: hidden` or `display: none`, it's ignored. If hidden with `.sr-only` or `clip` techniques, it's still read by screen readers.
29
What is a "focus indicator" and why is it important?
- It’s not focusable or operable via keyboard.
- No semantic meaning as a button.
- Fix: Use a `
30
Where is the accessibility issue in this button?
```
Submit
```
Why is this not accessible, and how would you fix it?
- It’s not focusable or operable via keyboard.
- No semantic meaning as a button.
- Fix: Use a
31
```
Submit
```
What is missing in this button implementation?
The `div` is not focusable and does not support keyboard interaction. To make it accessible, you need to add `tabindex=“0”` and handle `Enter` and `Space` key events manually.
32
```
Main Title
Subsection
``` What’s the accessibility issue here?
Skipping heading levels (h2 is missing) may confuse screen reader users. Headings should follow a logical hierarchy (e.g., h1 → h2 → h3).
33
```
```
What’s missing for accessibility?
There is no label associated with the input. Add a `` or use `aria-label`.
34
```
- Item 1
Extra Info
A `
` cannot be a direct child of `
- `. Only `
- ` elements are valid. This breaks semantics and could confuse assistive tech.
35
```
```
What’s wrong with this button?
`aria-hidden="true”` hides the button from screen readers, making it unusable for assistive tech users. Interactive elements should not be hidden.
36
```
```
Why might adding `tabindex=“0”` here be problematic?
Content block
Unless the `div` is interactive, making it `focusable` adds unnecessary tab stops and may confuse keyboard users.
37
```
Open Modal
```
What’s the potential accessibility issue?
`href=“#”` without preventing default behavior can cause the page to jump to the top. Also, it’s better to use `
38
```
```
What’s redundant or problematic here?
Both the parent `div` and the `input` have `aria-labels`. Nested `labels` can create confusion or be ignored. Use one clear label method.
Improved example:
```
```
39
```
```
What’s wrong with the alt attribute?
```
What’s wrong with the alt attribute?
“Graph” is too vague. Alt text should describe what the graph shows, e.g., `alt="Line graph showing sales growth from January to June”`.
40
```
```
Why might this be an issue?
The `
41
```
.button {
background-color: #ffffff;
color: #f1f1f1;
}
```
What’s the WCAG 2.1 Level AA issue here?
The contrast ratio between the text color and background is too low. WCAG 2.1 AA requires at least 4.5:1 for normal text. This fails that requirement.
42
```
Click here to download the file.
``` Why is this not WCAG 2.1 Level AA compliant?
Link text like “here” lacks context. WCAG 2.1 requires descriptive link text so users know where the link goes, especially when using screen readers.
43
```
```
What’s the WCAG issue here?
Using only a placeholder instead of a visible `
44
```
* Required field
```
What might cause this to fail WCAG 2.1 AA?
Relying solely on color to convey meaning (e.g., red asterisk) fails success criterion 1.4.1 (Use of Color). There must be text or symbols for users who can’t perceive color.
45
```
```
What’s the accessibility issue?
Autoplaying audio without a way to stop or control it can fail WCAG 2.1 AA (1.4.2 – Audio Control). Autoplay should be avoided or must have user controls.
46
```
```
What’s missing for WCAG 2.1 AA compliance?
Settings
Change your preferences here.
A modal dialog needs to manage keyboard focus (2.1.1, 2.4.3) and trap focus inside the dialog. It also should use `aria-modal="true”` and link heading via `aria-labelledby`.
47
```
```
What’s the WCAG issue here?
The button has no accessible name (`label` or `aria-label`). This violates 4.1.2 – Name, Role, Value. Screen readers won’t announce what the “?” button does.
48
```
```
Is this sufficient to indicate required fields?
No. WCAG 2.1 AA requires that visual cues and instructions accompany required fields (3.3.2). `aria-required` helps screen readers, but users also need a visible indicator.
49
```
```
What could be missing for WCAG 2.1 AA?
Missing: No captions or transcript provided.
Why it matters: WCAG 2.1 AA requires captions for videos with audio to ensure accessibility for deaf or hard-of-hearing users (Success Criterion 1.2.2).
```
```
50
```
```
What improvement could be made for screen reader navigation?
Add `aria-label="Primary navigation”` or wrap the `
51
Who must comply with Section 508?
Federal agencies and any organization that provides services to them, including contractors and vendors.
52
How is Section 508 different from WCAG?
Section 508 is a legal requirement for U.S. federal entities, while WCAG is a set of guidelines maintained by the W3C. Section 508 incorporates WCAG 2.0 Level AA into its requirements.
53
What is ADA compliance in digital products?
ADA compliance refers to ensuring that websites and digital services are accessible under the Americans with Disabilities Act, which prohibits discrimination against individuals with disabilities in public spaces—including online.
54
What types of organizations are subject to ADA?
Businesses that are open to the public (Title III), employers with 15+ employees (Title I), and state and local governments (Title II) must comply with ADA, including their digital content.
55
Is there a specific standard for ADA web compliance?
While ADA does not define a specific technical standard, WCAG 2.1 Level AA is widely accepted as the benchmark for ADA digital accessibility.
56
What are the legal consequences of failing ADA compliance?
Organizations can face lawsuits, fines, and be required to remediate inaccessible content. ADA lawsuits related to websites have increased significantly in recent years.
57
How does ADA relate to accessibility in mobile apps?
ADA compliance also applies to mobile apps, which are considered extensions of public-facing services. Apps must be accessible to screen readers and meet similar principles as web content.
58
What’s the relationship between Section 508 and the Rehabilitation Act of 1973?
Section 508 is an amendment to the Rehabilitation Act, focusing on making digital information and technology accessible to individuals with disabilities.
59
How can an organization demonstrate compliance with Section 508?
By conducting accessibility audits, remediating issues, using WCAG 2.0/2.1 Level AA as a guide, and providing documentation (e.g., VPAT – Voluntary Product Accessibility Template).
60
What’s a VPAT and why is it important?
A VPAT (Voluntary Product Accessibility Template) is a document that shows how accessible a product is. It’s often required in government procurement to demonstrate Section 508 compliance.
61
Can private companies be sued under Section 508?
Not directly. Section 508 applies to federal agencies. However, private companies working with the federal government must comply. ADA, not Section 508, is what applies to private-sector lawsuits.
62
What’s a good summary of the difference between ADA and Section 508?
ADA is a civil rights law focused on preventing discrimination in all public domains (including digital). Section 508 is a procurement law focused on ensuring federal technology is accessible.
63
What’s an example of a WCAG violation?
Low color contrast (e.g., light gray on white) or a modal that doesn’t trap focus for keyboard users.
64
What is the ADA in relation to digital accessibility?
The Americans with Disabilities Act is a civil rights law that prohibits discrimination against people with disabilities, including in digital spaces like websites and mobile apps.
65
What’s a real-world ADA compliance issue?
A blind user can’t complete an online checkout with a screen reader — this can lead to lawsuits under the ADA.
66
Does ADA specify WCAG?
No, but in practice, WCAG 2.1 Level AA is treated as the standard in legal cases.
67
What standard does Section 508 follow?
Since 2017, it officially aligns with WCAG 2.0 Level AA.
68
Can private companies be sued under Section 508?
Not directly. Section 508 applies to federal government entities. Private companies are more likely subject to ADA lawsuits.
69
What’s a simple way to summarize WCAG, ADA, and Section 508?
- WCAG = The guidelines
- ADA = The civil rights law
- Section 508 = The federal procurement law
70
Why does accessibility matter beyond compliance?
It ensures inclusion, improves UX, serves over 1 billion people with disabilities, and makes good business and design sense.
71
What is Axe?
Axe is an automated accessibility testing tool that scans web pages for WCAG violations.
It’s available as a browser extension and can also be integrated into CI pipelines.
72
What is Lighthouse?
Lighthouse is a Chrome DevTools tool that audits web pages for performance, SEO, and accessibility. It provides a score and recommendations based on WCAG standards.
73
What is WAVE?
WAVE (Web Accessibility Evaluation Tool) is a browser extension by WebAIM that visually identifies accessibility issues directly on the page using icons and overlays.
74
What are NVDA, JAWS, and VoiceOver?
They are screen readers used to test how assistive technologies interact with web content:
- **NVDA** (Windows, free)
- **JAWS** (Windows, paid, widely used in enterprise)
- **VoiceOver** (built into macOS and iOS)
75
What type of issues can automated tools like Axe or Lighthouse miss?
Automated tools can't detect contextual or UX-related issues like poor link text, missing instructions, or improper heading hierarchy. Manual testing is still essential.
76
How do screen readers help in accessibility testing?
They simulate how users with visual impairments interact with your app, helping test semantic structure, focus flow, and ARIA implementation.
77
What is keyboard-only testing?
A manual technique where you navigate the UI using only the keyboard (Tab, Shift+Tab, Enter, Space, arrows) to ensure all functionality is accessible without a mouse.
78
Why is combining manual and automated testing important?
Automated tools catch obvious code-level issues, while manual testing validates real-world usability for screen reader and keyboard users.
79
What is the role of color contrast analyzers?
These tools check whether text has sufficient contrast against its background, ensuring compliance with WCAG contrast ratio requirements (e.g., 4.5:1 for normal text).
80
Name a popular color contrast tool.
The **Color Contrast Analyzer** by TPGi or built-in contrast tools in browser extensions like Axe or WAVE.
81
What is the significance of accessibility audit reports?
They document identified issues, severity, affected components, and remediation steps — crucial for compliance tracking and communicating with stakeholders.
82
What makes a UI component “accessible”?
An accessible UI component supports keyboard interaction, proper focus management, semantic HTML, ARIA attributes where needed, and screen reader compatibility.
83
What are accessibility audits?
Comprehensive evaluations of a digital product to identify accessibility issues using both manual and automated testing methods, often resulting in a detailed report and remediation plan.
84
What’s the difference between manual and automated accessibility testing?
Automated tools catch code-level issues (like missing alt attributes), while manual testing evaluates context, keyboard navigation, screen reader behavior, and visual usability.
85
Why is manual testing essential in accessibility?
Because tools can miss complex issues like ambiguous link text, improper reading order, or confusing ARIA usage — human judgment is required.
86
How does Agile or Scrum relate to accessibility?
Incorporating accessibility into Agile/Scrum ensures it's considered in every sprint — not just as a final step. It becomes part of Definition of Done and QA acceptance criteria.
87
What is an accessibility-minded design system?
A collection of reusable components and patterns that are built to be accessible out of the box, helping teams consistently implement accessible UI across products.
88
Why is accessibility in design systems valuable?
It promotes scalability, reduces redundant work, and ensures teams follow accessibility best practices without reinventing the wheel for every component.
89
What does it mean to shift accessibility left in development?
It means addressing accessibility early in the design and development process — not waiting until the QA or remediation phase to fix issues.
90
Did you know accessibility can improve SEO?
Yes! Accessibility best practices like proper heading structure, semantic HTML, and avoiding keyboard traps also benefit SEO. Search engines, like screen readers, rely on clear structure and meaningful content, so accessible apps often rank better in search results.
91
In a single-page application (SPA), what should you do after a route changes?
Manually move focus to the top of the new content (e.g., a heading or `main` region) to prevent screen reader users from staying on old content. This can be done using `useEffect` and `ref.focus()`.
92
Why doesn't focus update automatically when navigating between routes in a React SPA?
Because the page doesn't reload like in traditional navigation. Focus stays where it was unless updated manually.
93
How can you move focus after a route change in React?
Use a `ref` on a landmark element (like `` or `
` or ``) and call `.focus()` in a `useEffect()` that runs when the route changes.
94
What is `@react-aria`?
A library from Adobe that provides accessible hooks and components built on WAI-ARIA best practices. It helps implement complex UI (like dropdowns and comboboxes) accessibly.
95
What’s a benefit of using libraries like `@reach/dialog` or `react-aria`?
They manage focus, keyboard interaction, ARIA roles, and announcements for you — saving time and reducing the risk of accessibility bugs.
96
Why use `aria-live` in React apps?
To notify screen reader users when **dynamic content** (like form errors or updates) changes without needing to refresh or move focus.
97
What are the possible values for `aria-live`?
`"off"` (default), `"polite"` (waits until screen reader is idle), and `"assertive"` (interrupts the current speech).
98
How should you announce dynamic form errors in React?
Use `aria-live="assertive"` on a container that updates with error messages, or move focus to the first error. Always associate errors with fields using `aria-describedby`.
99
What’s the best way to associate a label with an input in React?
Use `
100
How do you make custom inputs (e.g., date pickers) accessible?
Use semantic HTML when possible, and if not, ensure proper ARIA roles, labels, keyboard handling, and screen reader support (or use an accessible library).
101
How do you manage keyboard focus in modals or dialogs in React?
Trap focus inside the modal while it's open, return focus to the trigger on close, and use ARIA attributes like `role="dialog"` and `aria-modal="true"`.
102
Why is it important to return focus to the triggering element after a modal closes?
It maintains keyboard navigation context for users who don’t use a mouse, improving usability and compliance with WCAG 2.4.3 (Focus Order).
103
How do you manage focus after a route change in a React SPA?
```
// In a layout or route component
useEffect(() => {
const heading = document.getElementById("page-heading");
if (heading) heading.focus();
}, [location.pathname]);
// Heading element
Welcome
``` Use a `useEffect` to set focus on a heading or main content area when the route changes. Ensure the target is focusable (e.g., `tabIndex="-1"`).
104
How do you announce dynamic content changes with aria-live in React?
```
{statusMessage &&
```
Wrap dynamic updates in a container with `aria-live="polite”` or `”assertive”` so screen readers announce changes automatically.
{statusMessage}
}
105
How do you make a modal accessible in React?
```
return (
);
```
Use `role="dialog”` and `aria-modal="true”` with labeled elements. Also trap focus and return focus to the trigger on close (handled separately in code).
Subscribe
Get updates in your inbox.
106
How do you link a label and input correctly in React?
```
```
Use `htmlFor` on the label to match the `input’s id`. This creates a programmatic label association, essential for screen readers.
107
How do you associate a field with an error message in React using ARIA?
```
{hasError &&
Username is required.
}
```
Use `aria-describedby` to connect input fields to descriptive elements like error messages.
108
How do you provide keyboard accessibility for a custom button built with a div?
```
{
if (e.key === 'Enter' || e.key === ' ') handleClick();
}}
>
Submit
```
Add `role="button”`, `tabIndex=“0”`, and keyboard handling for `Enter` and `Space` to simulate button behavior.
109
How can you measure accessibility success using Lighthouse?
By running a Lighthouse audit in Chrome DevTools, you get an accessibility score (0–100) based on WCAG checks. A score above 90 indicates strong baseline accessibility, but manual testing is still required for full coverage.
110
Why is Lighthouse not enough for full accessibility validation?
Lighthouse only tests for automatable issues (e.g., missing alt attributes, contrast, ARIA roles). It doesn’t check keyboard flow, screen reader behavior, or contextual content issues — so it must be supplemented with manual testing.
111
What does a reduction in accessibility issues mean in practice?
It shows that remediation efforts are working. You can measure issue reduction by tracking open vs. resolved accessibility issues over time in your backlog or via audit reports.
112
How do you track screen reader testing results?
Create a test plan covering core flows and expected behaviors (labels, announcements, focus order). Document results across screen readers (e.g., NVDA, JAWS, VoiceOver) and report pass/fail per device and scenario.
113
What metrics can you use to show accessibility improvements over time?
- Lighthouse score trends
- Number of WCAG violations (before/after audits)
- Manual test case pass rate (e.g., 90%+ in screen reader/keyboard-only flows)
- Reduced user complaints or support tickets related to access
- Time-to-resolution for accessibility bugs
114
How can accessibility be added to QA or CI pipelines?
By integrating tools like axe-core, jest-axe, or cypress-axe, you can fail builds when key accessibility rules are violated — helping catch regressions early.
115
What role do user feedback and support tickets play in measuring accessibility?
Direct feedback from users with disabilities (or support requests related to usability issues) can reveal real-world problems and help track improvements beyond automated test results.
116
How do you communicate accessibility progress to non-technical stakeholders?
Use simple metrics like score increases, resolved issues, improved keyboard/screen reader support, and user feedback. Visuals (before/after) and Lighthouse reports also help tell the story.
117
Is using ARIA always a good idea?
No. Misusing ARIA can make accessibility worse. It's better to use **semantic HTML** first. ARIA should only be used when native elements can't provide the needed functionality.
118
What’s a common mistake when using ARIA roles?
Adding ARIA roles to elements that already have a semantic role (e.g., adding `role="button"` to a `
119
Why is “all ARIA is good” a misconception?
Because ARIA doesn't add functionality by itself — and when used incorrectly (e.g., `aria-hidden="true"` on active UI), it can break screen reader access entirely.
120
Are automated accessibility tools enough?
No. Automated tools only detect about **30–50%** of accessibility issues. They miss critical things like keyboard navigation, screen reader context, and meaningful content relationships.
121
What’s the risk of relying solely on automated tools like Axe or Lighthouse?
You’ll likely miss issues related to **focus management**, **meaningful link text**, **dynamic content announcements**, and other **manual-check-only criteria**.
122
What should supplement automated testing for full accessibility coverage?
Manual testing with keyboard, screen readers (e.g., NVDA, VoiceOver), and real-world scenario walkthroughs by QA or users with disabilities.
123
What’s a better mindset than “just add ARIA to fix it”?
**"Use native HTML first."** Semantic elements come with built-in accessibility. Only add ARIA when absolutely necessary and follow the spec carefully.
124
Do only blind users benefit from accessibility features?
No. Accessibility benefits a wide range of users, including those with motor, cognitive, auditory, and visual impairments — and even users in temporary or situational limitations.
125
Do screen readers only read text?
No. Screen readers interpret **semantic structure**, **labels**, **roles**, and **states** — not just visible text. They rely on proper HTML, ARIA, and focus management.
126
Is adding `alt=""` always wrong?
No. An empty `alt` attribute is correct for **decorative images** that should be ignored by screen readers. It prevents unnecessary noise.
127
Does accessibility only matter for users with disabilities?
No. Accessibility improvements help **everyone** — like closed captions in noisy environments, or keyboard navigation for power users.
128
Is accessibility a one-time fix?
No. Accessibility is **ongoing** — it must be considered throughout design, development, and QA, especially as features change and grow.
129
Is making a site accessible expensive or slow?
Not if built-in from the start. Retrofitting can be costly, but integrating accessibility early in development is efficient and scalable.
130
Do JavaScript-heavy apps inherently break accessibility?
Not necessarily. React and other JS frameworks can be accessible if developers follow best practices, use semantic HTML, manage focus, and test thoroughly.
131
Can visual testing replace screen reader testing?
No. Visual QA catches layout issues, but screen reader testing is essential to verify **auditory output**, focus flow, and hidden relationships.
132
Is accessibility only about compliance?
No. While laws matter, accessibility is ultimately about **inclusion**, **usability**, and building products that serve everyone fairly.
133
If no one complains, is the app accessible?
Not necessarily. Many users simply **give up** when facing barriers. Lack of complaints doesn’t equal lack of problems.
134
What’s the main challenge in making drag-and-drop interfaces accessible?
Drag-and-drop UIs are often mouse-dependent by default. To make them accessible, you must support **keyboard controls**, provide **clear instructions**, and use ARIA attributes like `aria-grabbed`, `aria-dropeffect`, and `aria-describedby`.
135
How can you make a drag-and-drop experience usable for screen reader users?
Provide **status updates** via `aria-live` regions, clearly announce when items are picked up or dropped, and offer **keyboard commands** for reordering or moving items (e.g. using arrow keys + Enter).
```
// Example drag item
{
if (e.key === 'Enter') startDrag();
if (e.key === ' ') dropItem();
}}
>
Drag me
// Live region to announce actions
{dragStatusMessage}
```
136
What ARIA roles are used in accessible tree views?
Use `role="tree"`, `role="treeitem"`, and `role="group"` with `aria-expanded`, `aria-level`, and `aria-selected` to define hierarchy, expand/collapse states, and navigation behavior.
```
-
Fruits
- Apple
- Banana
137
How do you make a custom combo box accessible?
Use role="combobox" on the input, link it with the listbox using aria-controls, and point to the active option using aria-activedescendant.
```
-
{options.map((opt) => (
- {opt.label} ))}
138
What is the role of `aria-activedescendant` in a combo box?
It allows the input to keep focus while pointing to the currently active item in the dropdown list. The screen reader will read the value of the `aria-activedescendant` target.
139
Why is focus management important in asynchronous UIs?
Because dynamic updates (like spinners, modals, or toasts) can cause screen readers or keyboard users to lose context if focus is not **intentionally handled**.
140
How should focus be handled after a loading spinner is removed?
After async content loads, move focus to a heading or main content area to help screen reader and keyboard users regain context.
```
useEffect(() => {
if (!isLoading && contentRef.current) {
contentRef.current.focus();
}
}, [isLoading]);
// Target focusable content area
Loaded Content
```
141
How can screen readers be notified of async updates like toast messages?
Use a visually hidden element with aria-live to announce the message without shifting focus.
```
// Toast component
{toastMessage}
```
Tip: Use "assertive" if the message is critical (e.g., “Payment failed”), otherwise prefer "polite" to avoid interrupting users.
142
What ARIA role is appropriate for a live toast or alert?
Use `role="status"` (polite updates) or `role="alert"` (assertive, interrupting updates). These are automatically treated as `aria-live` regions by screen readers.
143
What is a key pitfall when building custom interactive widgets?
Not supporting **keyboard interaction**, failing to manage focus, or misusing ARIA roles can break accessibility. Follow **WAI-ARIA Authoring Practices** for patterns like tabs, sliders, and accordions.
144
Why can React apps break screen reader behavior?
React apps often update the DOM without reloading the page, which can confuse screen readers if focus and ARIA attributes aren't properly managed. You must **manually manage focus and state updates** to ensure accessibility.
145
What’s a common focus management mistake in React apps?
Not resetting focus after route changes or dynamic content updates. In SPAs, focus remains on old elements unless you **explicitly move it** to the new content (e.g., a heading or main container).
146
Why should you avoid reusing `id`s in conditional rendering?
React may remount elements with duplicate `id`s (e.g., in forms or modals), which **breaks ARIA references** like `aria-labelledby` or `aria-describedby`. Ensure each `id` is unique.
147
Why can dynamic components with conditional rendering cause accessibility issues?
Components that appear/disappear conditionally (e.g., modals, dropdowns) can **steal or trap focus**, or leave the screen reader on a removed element. Always **handle focus in and out** explicitly.
148
What’s a best practice when using portals for modals in React?
Ensure you **trap focus inside the portal** while open, return focus to the trigger when it closes, and apply ARIA roles like `role="dialog"` and `aria-modal="true"` to the container.
149
What’s a common mistake when building accessible forms in React?
Relying on placeholder text instead of proper `
150
Why is `aria-live` tricky in React?
React may **batch state updates**, so dynamic announcements might not be read if the element is added and removed too quickly. Use persistent `aria-live` containers and let content update inside them.
151
How do React keys affect accessibility?
Reusing or missing `key` props can cause React to incorrectly re-render list items, which may confuse screen readers tracking focus or live updates. Always use **stable, unique keys**.
152
Why might screen readers not read dynamic content updates in React?
If the updated content isn't **within a persistent element with `aria-live`**, or if the change happens too quickly, screen readers may skip it. Keep `aria-live` containers in the DOM at all times.
153
What’s a gotcha when using SVGs in React?
By default, screen readers may **read raw markup** unless SVGs are marked decorative (`aria-hidden="true"`) or given meaningful labels using `role="img"` and `aria-label`.
154
What’s the first step in an accessibility remediation effort?
Conduct an **accessibility audit** (manual + automated) to identify issues and create a prioritized backlog based on impact and severity.
155
How do you prioritize accessibility issues for remediation?
Focus on:
- **High-impact** issues first (e.g., no keyboard access, unreadable content)
- Issues affecting **core flows** (navigation, forms, modals)
- Severity based on **WCAG conformance levels** (A, AA, AAA)
156
What tools help identify issues during remediation?
Use a combination of:
- **Automated tools** (Axe, Lighthouse, WAVE)
- **Screen readers** (NVDA, VoiceOver, JAWS)
- **Keyboard-only testing**
- **Manual walkthroughs** for real-world usability
157
Why is it important to test with real assistive technologies during remediation?
Because automated tools can’t detect all issues — only ~30–50%. Real AT testing reveals problems with context, flow, and actual user experience.
158
What teams should be involved in remediation?
**Developers**, **Designers**, **QA**, and sometimes **Legal/Product**. Accessibility is a shared responsibility and remediation often involves collaboration across disciplines.
159
How do you track progress in remediation?
How do you track progress in remediation?
160
How do you ensure accessibility issues don’t return after remediation?
Integrate accessibility checks into **CI pipelines**, add accessibility to the **Definition of Done**, and conduct **regression testing** during releases.
161
What’s the role of user feedback in remediation?
Feedback from users with disabilities can uncover real-world issues that audits miss and validate that fixes actually improve usability.
162
Why is documentation important in remediation?
Documenting issues, fixes, and decisions ensures consistency, helps onboard others, and creates a record for audits or legal compliance.
163
What’s wrong with this component, and how can we improve its accessibility?
```
const SubmitButton = () => (
Submit
);
```
The div is not keyboard-accessible and lacks semantic meaning. It should be replaced with a
164
How can we improve accessibility in this custom dropdown?
```
{}} />
-
{options.map(opt => (
- {opt} ))}
This lacks ARIA roles, labeling, and keyboard support. Use `role="combobox"`, `aria-expanded`, `aria-controls`, and `aria-activedescendant`.
```
-
{options.map(opt => (
- {opt} ))}
165
How can we make this modal accessible?
```
const Modal = () => (
);
```
Settings
Adjust your preferences
The modal is missing key ARIA attributes (`role="dialog"`, `aria-modal`) and focus trapping.
```
const Modal = () => (
);
```
For full accessibility, you’d also trap focus and return it on close.
Settings
Adjust your preferences
166
What’s wrong with this label/input pair?
```
```
The label is not associated with the input, so screen readers may not connect them.
```
```
167
How can we improve this notification for screen reader users?
```
{toast &&
{toast}
}
```
There’s no `aria-live` region to announce the message dynamically.
```
{toast &&
```
{toast}
}
168
What’s wrong with this required field?
```
```
- No `
169
What’s wrong with this form error message?
```
Email is required
```
- Error message is not associated with the input.
- Screen readers won’t announce the error automatically.
```
Email is required
```
170
What’s the issue with this custom button?
```
Click Me
```
- Not focusable with keyboard.
- No keyboard event support.
- No semantic role.
```
{
if (e.key === "Enter" || e.key === " ") doAction();
}}
>
Click Me
```
Still better to use
171
What’s wrong with this collapsible section?
```
More Info
Details...
```
- No semantic grouping.
- No ARIA to indicate state.
- No keyboard accessibility.
```
Details...
```
172
What’s wrong with this tab component?
```
- Tab 1
- Tab 2
Content for Tab 1
```
- No roles or ARIA states.
- No keyboard navigation (left/right arrows).
- No focus management.
```
Content for Tab 1
Content for Tab 2
```
173
How do you make a slider accessible?
```
```
This works, but for a custom slider (e.g. div-based), you need ARIA roles and full keyboard handling.
```
{
if (e.key === "ArrowRight") setValue(value + 1);
if (e.key === "ArrowLeft") setValue(value - 1);
}}
>
Volume: {value}
```
174
Explain each principle of WCAG
The four principles of WCAG (Web Content Accessibility Guidelines) are:
1. **Perceivable** – Information and user interface components must be presented to users in ways they can perceive (e.g., text alternatives for images, captions for videos).
2. **Operable** – User interface components and navigation must be operable (e.g., keyboard accessibility, enough time to read content).
3. **Understandable** – Information and the operation of the user interface must be understandable (e.g., readable content, predictable navigation).
4. **Robust** – Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.
