Frequently Asked Questions

Web accessibility means designing and developing websites so that people with disabilities can use them. This includes people with visual, auditory, motor, and cognitive impairments. An accessible website works with assistive technologies like screen readers, provides keyboard navigation, uses sufficient color contrast, and includes text alternatives for non-text content.

WCAG 2.1 (Web Content Accessibility Guidelines version 2.1) is the international standard for web accessibility published by the World Wide Web Consortium (W3C). It defines success criteria organized under four principles: Perceivable, Operable, Understandable, and Robust (POUR). WCAG 2.1 has three conformance levels: A (minimum), AA (recommended for most sites), and AAA (highest). Most laws and regulations reference WCAG 2.1 Level AA as the baseline.

WCAG 2.2, published in October 2023, adds 9 new success criteria on top of WCAG 2.1. New criteria include Focus Not Obscured, Dragging Movements, Target Size (minimum), Consistent Help, Redundant Entry, and Accessible Authentication. WCAG 2.2 also removes success criterion 4.1.1 Parsing. If you comply with WCAG 2.1 AA, you're most of the way to 2.2 compliance.

The most common issues include: missing alternative text on images, insufficient color contrast (below 4.5:1 ratio for normal text), missing form labels, empty links or buttons without accessible names, missing document language, and empty headings. These six issues account for over 96% of detected errors according to the WebAIM Million report.

Automated accessibility testing tools can detect approximately 30-40% of WCAG issues. They excel at finding missing alt text, color contrast failures, missing form labels, duplicate IDs, and structural issues. The remaining 60-70% requires manual testing — such as evaluating alt text quality, testing keyboard navigation flows, and verifying screen reader announcements.

While no single federal law explicitly mandates website accessibility, ADA Title III has been consistently interpreted by courts to cover websites of businesses open to the public. The Department of Justice issued a final rule in 2024 requiring state and local government websites to meet WCAG 2.1 AA. Over 4,000 ADA web accessibility lawsuits were filed in 2023 alone, with plaintiffs winning or settling the vast majority of cases.

The European Accessibility Act (EAA) is an EU directive that requires digital products and services to be accessible starting June 28, 2025. It applies to e-commerce websites, banking services, e-books, transportation services, and more. The EAA references the EN 301 549 standard, which maps to WCAG 2.1 AA. Non-compliance can result in fines and market access restrictions.

Section 508 of the Rehabilitation Act requires US federal agencies and organizations receiving federal funding to make their electronic and information technology accessible. It was updated in 2017 to align with WCAG 2.0 AA standards. This includes federal websites, internal tools, procurement, and any technology funded by federal grants or contracts.

ADA web accessibility lawsuits typically settle between $5,000 and $150,000 for small to mid-size businesses. Legal defense costs $10,000-$50,000 even if you win. Serial plaintiff firms often target e-commerce sites, hospitality, food service, and retail. The average settlement is significantly more expensive than proactive remediation, which typically costs $2,000-$15,000 depending on site complexity.

A11yScope uses a headless browser (Puppeteer) to fully render your page including JavaScript content, then runs axe-core — the industry-standard accessibility testing engine by Deque Systems — to check against 38+ WCAG 2.1 AA rules. The entire scan takes approximately 6 seconds and produces a detailed report with specific code fixes for every issue found.

Yes. A11yScope offers a free tier with 3 scans per month. No account or credit card is required. Simply enter a URL on the homepage and get your accessibility report in seconds. For unlimited scans, PDF report export, and continuous monitoring, the Pro plan is available at $19/month. The Agency plan at $49/month adds multi-site management, team access, and white-label reports.

axe-core is an open-source accessibility testing engine created and maintained by Deque Systems. It's the most widely used accessibility testing library in the world, also used by Google Lighthouse, Microsoft Accessibility Insights, and browser DevTools. A11yScope uses axe-core because of its proven accuracy, comprehensive WCAG rule coverage, and zero false-positive commitment.

Yes. Unlike some accessibility checkers that only analyze static HTML, A11yScope uses a real browser engine to fully render your page. This means React, Vue, Angular, and other JavaScript framework content is fully loaded and tested. Dynamic content, single-page applications, and client-side rendered components are all included in the scan.

A11yScope's own website scores 98 out of 100 on our accessibility scanner with zero WCAG violations detected. We practice what we preach — our site is built with semantic HTML, proper heading structure, sufficient color contrast, keyboard navigation, and screen reader compatibility.

Add an alt attribute to every <img> tag that describes the image content. For informational images, write a concise description (e.g., alt="Team meeting in conference room"). For decorative images that don't convey content, use an empty alt attribute (alt=""). For complex images like charts, provide a brief alt text and a longer description nearby or via aria-describedby.

WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). To fix contrast issues: darken your text color or lighten the background (or vice versa). Use a contrast checker tool to verify ratios. Common fixes include changing light gray text (#999) to darker gray (#595959) against white backgrounds.

Every form input needs an associated label. The preferred method is using a <label> element with a 'for' attribute matching the input's 'id': <label for="email">Email</label><input id="email" type="email">. Alternatively, use aria-label for inputs where a visible label isn't appropriate, or aria-labelledby to reference existing text on the page.

Ensure all interactive elements (links, buttons, form fields, menus) are reachable and operable with keyboard alone. Use semantic HTML elements that are naturally focusable. Add visible focus indicators (:focus-visible styles). Implement logical tab order. Avoid keyboard traps where focus gets stuck. For custom widgets, add appropriate ARIA roles and keyboard event handlers.

No. Accessibility overlay widgets (like AccessiBe, UserWay, AudioEye) add a JavaScript layer on top of your site but do not fix the underlying code issues. Multiple studies and advocacy organizations have documented that overlays often introduce new accessibility barriers, interfere with screen readers, and provide a false sense of compliance. Over 800 accessibility advocates have signed an open letter against overlays. The recommended approach is fixing your actual code.