Senior FE WCAG Flashcards
What does WCAG stand for?
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.
What does WCAG cover?
Guidelines for accessibility like text alternatives, keyboard navigation, color contrast, focus management, and screen reader support.
What are the four principles of WCAG?
POUR
1. Perceivable,
2. Operable,
3. Understandable,
4. Robust
What does “WCAG 2.1 Level AA” refer to?
A set of accessibility guidelines that include required criteria for mid-level compliance, ensuring broad accessibility without being overly strict.
What types of disabilities does WCAG 2.1 address?
Visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.
What are ARIA roles?
Attributes used to define accessible web content and applications for users with assistive technologies.
When should ARIA roles be used?
When native HTML elements don’t provide the needed accessibility functionality.
What is the difference between ARIA roles and semantic HTML?
Semantic HTML is preferred because it has built-in accessibility;
ARIA should be used as a supplement, not a replacement.
What is the purpose of ARIA attributes like aria-label, aria-hidden, or aria-live?
To improve screen reader interaction by describing elements, hiding content, or notifying updates dynamically.
What does “accessible design” mean?
Designing digital experiences that can be used by as many people as possible, regardless of disability or impairment.
What is Section 508?
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.
What is ADA compliance?
Adherence to the Americans with Disabilities Act, ensuring equal access to digital content for individuals with disabilities.
What is accessibility remediation?
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.
What does “compliance” mean in the context of accessibility?
Meeting the legal and technical standards defined by WCAG, ADA, Section 508, etc.
What is the difference between aria-label and aria-labelledby?
aria-label provides an explicit text label directly on the element;
aria-labelledby references the ID of another element to derive the label.
How does aria-hidden="true" affect screen readers?
It hides the element and all of its children from screen readers, even though they remain visible visually.
What is the effect of setting tabindex="-1" on an element?
It removes the element from the tab order but allows it to receive focus programmatically.
When would you use role="button" in combination with JavaScript?
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.
How does a screen reader interpret <button aria-pressed="true">?
It reads the button as a toggle and announces it as “pressed” to the user, helping convey state.
What HTML element should be used for dynamic content that needs to alert screen reader users?
Use a container with aria-live="polite" or aria-live="assertive" to announce content changes.
What’s the difference between aria-live="polite" and aria-live="assertive"?
polite waits until the user is idle to announce changes; assertive interrupts the screen reader immediately.
Why is semantic HTML preferred over ARIA roles?
Semantic elements (like <button>, <nav>, <main>) have built-in accessibility support and behaviors, reducing the need for custom scripting or attributes.
What are some common ARIA roles used in UI components?
role="dialog", role="alert", role="button", role="tablist", role="tabpanel", role="checkbox", etc.
What is “focus trapping” and when should it be used?
Focus trapping keeps keyboard navigation within a container (e.g., modal) until it’s closed, ensuring users don’t tab out of context.
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-labelledbyto reference the modal’s title. - Use
aria-describedbyto 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:
<div id="myModal" role="dialog" aria-modal="true" aria-labelledby="modalTitle" aria-describedby="modalDescription"> <h2 id="modalTitle">Delete Item</h2> <p id="modalDescription">Are you sure you want to delete this item? This action cannot be undone.</p> <button>Cancel</button> <button>Delete</button> </div>
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 <a href="#main">Skip to main content</a>.
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.
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.
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
<button>element or addrole="button",tabIndex="0", and keyboard handlers (onKeyDown for Enter/Space).
Where is the accessibility issue in this button?
<div onClick={handleClick}>
Submit
</div>
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 <button> element or add role=”button”, tabIndex=”0”, and keyboard handlers (onKeyDown for Enter/Space).</button>
<div role="button" onclick="submitForm()">Submit</div>
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.
<h1>Main Title</h1> <h3>Subsection</h3>
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).
<input type="text" id="search">
What’s missing for accessibility?
There is no label associated with the input. Add a <label for="search">Search</label> or use aria-label.
<ul> <li>Item 1</li> <div>Extra Info</div> </ul>
What’s the semantic issue in this code?
A <div> cannot be a direct child of <ul>. Only <li> elements are valid. This breaks semantics and could confuse assistive tech.
<button aria-hidden="true">Next</button>
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.
<div tabindex="0"> <p>Content block</p> </div>
Why might adding tabindex=“0” here be problematic?
Unless the div is interactive, making it focusable adds unnecessary tab stops and may confuse keyboard users.
<a href="#" onclick="openModal()">Open Modal</a>
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 <button> for actions that don’t navigate.
<div aria-label="Search form"> <input type="text" aria-label="Search" /> <button>Go</button> </div>
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:
<form role="search"> <input id="search" type="text" aria-label="Search" /> <button type="submit">Go</button> </form>
<img src="graph.png" alt="Graph">
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”.
<label>Email</label> <input type="email" id="email">
Why might this be an issue?
The <label> is not associated with the input. Add for="email” to the label or nest the input inside the label for proper association.
.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.
<p> Click <a href="download.pdf">here</a> to download the file. </p>
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.
<form> <input type="text" placeholder="Email"> <button type="submit">Submit</button> </form>
What’s the WCAG issue here?
Using only a placeholder instead of a visible <label> fails WCAG 2.1 AA, which requires programmatically associated labels for form inputs.
<div style="color: red;"> * Required field </div>
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.
<audio controls autoplay> <source src="audio.mp3" type="audio/mp3"> </audio>
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.
<div role="dialog"> <h2>Settings</h2> <p>Change your preferences here.</p> </div>
What’s missing for WCAG 2.1 AA compliance?
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.
<button onclick="openHelp()"> ? </button>
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.
<input type="text" aria-required="true">
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.
<video controls> <source src="intro.mp4" type="video/mp4"> </video>
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).
<video controls> <source src="intro.mp4" type="video/mp4"> <track src="intro-captions.vtt" kind="captions" srclang="en" label="English"> </video>
<nav> <a href="/home">Home</a> <a href="/about">About</a> <a href="/contact">Contact</a> </nav>
What improvement could be made for screen reader navigation?
Add aria-label="Primary navigation” or wrap the <nav> in a <header>/<footer> with context. WCAG 2.1 AA encourages landmarks with clear roles and labels for easier navigation.
Who must comply with Section 508?
Federal agencies and any organization that provides services to them, including contractors and vendors.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
Does ADA specify WCAG?
No, but in practice, WCAG 2.1 Level AA is treated as the standard in legal cases.
What standard does Section 508 follow?
Since 2017, it officially aligns with WCAG 2.0 Level AA.
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.
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
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.
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.
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.
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.
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)
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.
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.
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.
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.
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).
Name a popular color contrast tool.
The Color Contrast Analyzer by TPGi or built-in contrast tools in browser extensions like Axe or WAVE.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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().
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.
How can you move focus after a route change in React?
Use a ref on a landmark element (like <h1> or <main>) and call .focus() in a useEffect() that runs when the route changes.
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.
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.
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.
What are the possible values for aria-live?
"off" (default), "polite" (waits until screen reader is idle), and "assertive" (interrupts the current speech).
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.
What’s the best way to associate a label with an input in React?
Use <label htmlFor="inputId"> and <input id="inputId">, or wrap the input inside the label. Always ensure the relationship is programmatically clear.
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).
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".
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).
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
<h1 id="page-heading" tabIndex="-1">Welcome</h1>
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").
How do you announce dynamic content changes with aria-live in React?
<div aria-live="polite">
{statusMessage && <p>{statusMessage}</p>}
</div>
Wrap dynamic updates in a container with aria-live="polite” or ”assertive” so screen readers announce changes automatically.
How do you make a modal accessible in React?
return (
<div role="dialog" aria-modal="true" aria-labelledby="modal-title">
<h2 id="modal-title">Subscribe</h2>
<p>Get updates in your inbox.</p>
<button onClick={closeModal}>Close</button>
</div>
);
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).
How do you link a label and input correctly in React?
<label htmlFor="email">Email</label> <input id="email" type="email" />
Use htmlFor on the label to match the input’s id. This creates a programmatic label association, essential for screen readers.
How do you associate a field with an error message in React using ARIA?
<input id="username" aria-describedby="username-error" />
{hasError && <div id="username-error">Username is required.</div>}
Use aria-describedby to connect input fields to descriptive elements like error messages.
How do you provide keyboard accessibility for a custom button built with a div?
<div
role="button"
tabIndex="0"
onClick={handleClick}
onKeyDown={(e) => {
if (e.key === 'Enter' || e.key === ' ') handleClick();
}}
>
Submit
</div>
Add role="button”, tabIndex=“0”, and keyboard handling for Enter and Space to simulate button behavior.
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.
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.
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.
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.
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
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.
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.
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.
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.
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 <button>) — this is redundant and can confuse assistive tech.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Is accessibility only about compliance?
No. While laws matter, accessibility is ultimately about inclusion, usability, and building products that serve everyone fairly.
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.
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.
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
<div
role="button"
aria-grabbed={isDragging}
tabIndex={0}
onKeyDown={(e) => {
if (e.key === 'Enter') startDrag();
if (e.key === ' ') dropItem();
}}
>
Drag me
</div>
// Live region to announce actions
<div aria-live="assertive" className="sr-only">
{dragStatusMessage}
</div>
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.
<ul role="tree">
<li role="treeitem" aria-expanded="true" aria-level="1" aria-selected="false">
Fruits
<ul role="group">
<li role="treeitem" aria-level="2" aria-selected="true">Apple</li>
<li role="treeitem" aria-level="2" aria-selected="false">Banana</li>
</ul>
</li>
</ul>
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.
<input
type="text"
role="combobox"
aria-expanded={isOpen}
aria-controls="combo-options"
aria-activedescendant={highlightedId}
onKeyDown={handleKeyDown}
/>
<ul id="combo-options" role="listbox">
{options.map((opt) => (
<li
key={opt.id}
id={opt.id}
role="option"
aria-selected={opt.id === highlightedId}
>
{opt.label}
</li>
))}
</ul>
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.
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.
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
<h2 ref={contentRef} tabIndex={-1}>
Loaded Content
</h2>
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
<div aria-live="polite" className="sr-only">
{toastMessage}
</div>
Tip: Use “assertive” if the message is critical (e.g., “Payment failed”), otherwise prefer “polite” to avoid interrupting users.
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.
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.
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.
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).
Why should you avoid reusing ids in conditional rendering?
React may remount elements with duplicate ids (e.g., in forms or modals), which breaks ARIA references like aria-labelledby or aria-describedby. Ensure each id is unique.
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.
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.
What’s a common mistake when building accessible forms in React?
Relying on placeholder text instead of proper <label htmlFor="id"> associations. Placeholders disappear and aren’t announced by all screen readers as labels.
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.
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.
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.
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.
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.
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)
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
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.
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.
How do you track progress in remediation?
How do you track progress in remediation?
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.
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.
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.
What’s wrong with this component, and how can we improve its accessibility?
const SubmitButton = () => (
<div onClick={handleSubmit}>Submit</div>
);
The div is not keyboard-accessible and lacks semantic meaning. It should be replaced with a <button>, or at minimum, use ARIA and keyboard handlers.</button>
const SubmitButton = () => (
<button onClick={handleSubmit}>Submit</button>
);
How can we improve accessibility in this custom dropdown?
<input type="text" value={selected} onChange={() => {}} />
<ul>
{options.map(opt => (
<li key={opt}>{opt}</li>
))}
</ul>
This lacks ARIA roles, labeling, and keyboard support. Use role="combobox", aria-expanded, aria-controls, and aria-activedescendant.
<input
type="text"
role="combobox"
aria-expanded={isOpen}
aria-controls="dropdown-list"
aria-activedescendant={highlightedId}
/>
<ul id="dropdown-list" role="listbox">
{options.map(opt => (
<li
key={opt}
id={`opt-${opt}`}
role="option"
aria-selected={opt === selected}
>
{opt}
</li>
))}
</ul>
How can we make this modal accessible?
const Modal = () => (
<div className="modal">
<h2>Settings</h2>
<p>Adjust your preferences</p>
</div>
);
The modal is missing key ARIA attributes (role="dialog", aria-modal) and focus trapping.
const Modal = () => (
<div
role="dialog"
aria-modal="true"
aria-labelledby="modal-title"
className="modal"
>
<h2 id="modal-title">Settings</h2>
<p>Adjust your preferences</p>
</div>
);
For full accessibility, you’d also trap focus and return it on close.
What’s wrong with this label/input pair?
<label>Email</label> <input type="email" />
The label is not associated with the input, so screen readers may not connect them.
<label htmlFor="email">Email</label> <input type="email" id="email" />
How can we improve this notification for screen reader users?
{toast && <div>{toast}</div>}
There’s no aria-live region to announce the message dynamically.
<div aria-live="polite">
{toast && <div>{toast}</div>}
</div>
What’s wrong with this required field?
<input type="text" placeholder="Username" required />
- No
<label>associated. -
Placeholderis not a proper label. - No screen reader indication that the field is required.
<label htmlFor="username">Username <span aria-hidden="true">*</span></label> <input type="text" id="username" name="username" required aria-required="true" />
What’s wrong with this form error message?
<input type="text" id="email" /> <div>Email is required</div>
- Error message is not associated with the input.
- Screen readers won’t announce the error automatically.
<input type="text" id="email" aria-describedby="email-error" /> <div id="email-error" role="alert"> Email is required </div>
What’s the issue with this custom button?
<div onClick={doAction}>Click Me</div>
- Not focusable with keyboard.
- No keyboard event support.
- No semantic role.
<div
role="button"
tabIndex="0"
onClick={doAction}
onKeyDown={(e) => {
if (e.key === "Enter" || e.key === " ") doAction();
}}
>
Click Me
</div>
Still better to use <button> unless absolutely necessary.</button>
What’s wrong with this collapsible section?
<div onClick={toggle} className="header">More Info</div>
<div className="content">Details...</div>
- No semantic grouping.
- No ARIA to indicate state.
- No keyboard accessibility.
<button
aria-expanded={isOpen}
aria-controls="details-panel"
onClick={toggle}
>
More Info
</button>
<div id="details-panel" hidden={!isOpen}>
Details...
</div>
What’s wrong with this tab component?
<ul> <li>Tab 1</li> <li>Tab 2</li> </ul> <div>Content for Tab 1</div>
- No roles or ARIA states.
- No keyboard navigation (left/right arrows).
- No focus management.
<div role="tablist">
<button
role="tab"
aria-selected={activeTab === 0}
aria-controls="panel-0"
id="tab-0"
onClick={() => setActiveTab(0)}
>
Tab 1
</button>
<button
role="tab"
aria-selected={activeTab === 1}
aria-controls="panel-1"
id="tab-1"
onClick={() => setActiveTab(1)}
>
Tab 2
</button>
</div>
<div
role="tabpanel"
id="panel-0"
aria-labelledby="tab-0"
hidden={activeTab !== 0}
>
Content for Tab 1
</div>
<div
role="tabpanel"
id="panel-1"
aria-labelledby="tab-1"
hidden={activeTab !== 1}
>
Content for Tab 2
</div>
How do you make a slider accessible?
<input type="range" min="0" max="100" />
This works, but for a custom slider (e.g. div-based), you need ARIA roles and full keyboard handling.
<div
role="slider"
tabIndex="0"
aria-valuemin={0}
aria-valuemax={100}
aria-valuenow={value}
aria-label="Volume"
onKeyDown={(e) => {
if (e.key === "ArrowRight") setValue(value + 1);
if (e.key === "ArrowLeft") setValue(value - 1);
}}
>
Volume: {value}
</div>
Explain each principle of WCAG
The four principles of WCAG (Web Content Accessibility Guidelines) are:
- 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).
- Operable – User interface components and navigation must be operable (e.g., keyboard accessibility, enough time to read content).
- Understandable – Information and the operation of the user interface must be understandable (e.g., readable content, predictable navigation).
- Robust – Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.
> Tip: Use the acronym POUR to remember:
Perceivable, Operable, Understandable, Robust
