Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Common WCAG failures include missing image alternatives, inaccurate video captions, keyboard barriers, low contrast, inaccessible forms, and layouts that break when users zoom. These can prevent people with disabilities from using a site, but a technical failure does not automatically determine legal liability. The applicable law, jurisdiction, organization, barrier, and circumstances matter.
What WCAG failures can create barriers?
The ten patterns below are practical, high-impact examples—not a statistically ranked list. WCAG conformance is determined by its success criteria, organized around content being perceivable, operable, understandable, and robust. The W3C lists techniques and failure examples to help interpret those criteria, but they are not the only ways to meet a criterion. See the WCAG 2.2 standard and WCAG techniques and failures.
1. Images have missing or unhelpful text alternatives
A screen reader cannot infer the purpose of an informative image from its appearance. A filename such as “chart-final2.png” is not a useful alternative. Missing alternatives can exclude people who are blind or cannot perceive the image.
Relevant criterion: WCAG 1.1.1, Non-text Content (Level A). Fix: Give informative images concise alternative text that communicates the information or function relevant in context. For a linked image, describe the link’s purpose. Mark purely decorative images so assistive technology can ignore them; do not make their alternative text repeat nearby copy.
#1 Best Overall
2. Videos lack accurate captions
Captions that omit dialogue or meaningful sounds can make prerecorded video incomprehensible to people who are deaf or hard of hearing. Auto-generated captions may contain errors, especially for names, technical terms, or noisy audio.
Relevant criterion: WCAG 1.2.2, Captions (Prerecorded) (Level A). Fix: Review captions against the video, correcting speech and adding meaningful sound cues where needed. W3C documents omitted dialogue and important sound effects among caption failures in its techniques and failures.
3. Core tasks cannot be completed with a keyboard
Menus, dialogs, links, and other controls may work with a mouse but fail when someone uses Tab, Shift+Tab, Enter, Space, or arrow keys. A keyboard user may also become trapped in a widget with no way to move focus out.
Free tools Windows power users keep installed
One-click scans. No signup required.
Relevant criteria: WCAG 2.1.1, Keyboard, and 2.1.2, No Keyboard Trap (Level A). Fix: Try each essential task without a mouse. Confirm that controls can be reached, operated, and exited using the keyboard, and that focus moves in a logical order.
4. Keyboard focus is invisible or hidden behind page content
If the current focus is hard to see, keyboard users may lose track of where they are. Sticky navigation, banners, or footers can also cover the focused control, making it difficult or impossible to continue.
Relevant criteria: WCAG 2.4.7, Focus Visible (Level AA), and WCAG 2.2’s 2.4.11, Focus Not Obscured (Minimum) (Level AA). The latter says: “When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” That is the W3C criterion’s wording, not a requirement that no part of a component may ever be covered. Fix: Keep a clear focus indicator and check focused elements while sticky content is present. See the W3C’s explanation of what’s new in WCAG 2.2.
5. Text or controls have inadequate contrast
Low contrast can make text difficult to read and can make interface parts—such as an input boundary or meaningful icon—hard to distinguish. Text contrast and non-text contrast have separate criteria. A color choice alone does not establish a failure; the relevant colors and rendered states must be assessed.
Rank #2
Relevant criteria: WCAG 1.4.3, Contrast (Minimum) (Level AA), for text, and 1.4.11, Non-text Contrast (Level AA), for applicable interface components and graphical objects. Fix: Measure foreground and background colors in the states users encounter, including hover, focus, disabled, and error states where applicable, and adjust combinations that do not meet the relevant criterion.
6. Visual structure is missing from the markup
A page may look as if it has headings, lists, or a data table while its code exposes none of those relationships. People navigating by headings or using a screen reader may then have to interpret an undifferentiated block of content.
Relevant criterion: WCAG 1.3.1, Info and Relationships (Level A). Fix: Use heading elements in a meaningful hierarchy, list markup for lists, and appropriate row and column headers for data tables. Do not rely on larger type, indentation, color, or spacing alone to communicate relationships.
7. Forms lack labels, instructions, or useful error messages
A field’s visual prompt may not be programmatically connected to the field. A person may not know what information is required, what format to enter, or which entry caused an error. This can affect people using screen readers, voice control, or cognitive supports.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Relevant criteria: WCAG 3.3.1, Error Identification (Level A); 3.3.2, Labels or Instructions (Level A); and, where applicable, 3.3.3, Error Suggestion (Level AA). Fix: Associate each field with a persistent label, explain requirements before entry, and identify errors in text. When possible, state how to correct an error rather than relying only on color or a generic alert.
8. Content or tasks break when users zoom or narrow the viewport
At increased text size or a narrow viewport, content may overlap, disappear, or require scrolling in two directions to read a normal text column. Controls can also become unreachable or lose functionality. That can block users with low vision or people who need larger text or a reflowed layout.
Relevant criteria: WCAG 1.4.4, Resize Text; 1.4.10, Reflow; and 1.4.12, Text Spacing (Level AA). Fix: Test zoom and viewport changes, as well as increased text spacing. Ensure content and functionality remain available and readable under the conditions and exceptions set out in the relevant WCAG criteria; avoid fixed layouts that clip or overlap content.
9. Unexpected context changes or time limits interrupt tasks
A form that submits as soon as a field changes, or a page that unexpectedly navigates when an element receives focus, can disorient people who need more time to understand or operate the interface. A session timeout can also erase work before someone can finish.
Recommended Free Tools
Relevant criteria: WCAG 3.2.1, On Focus, and 3.2.2, On Input (Level A); and 2.2.1, Timing Adjustable (Level A), where it applies. Fix: Do not trigger a change of context solely because focus or a value changed unless users have been advised of the behavior. For applicable time limits, provide a way to turn them off, adjust them, or extend them as the criterion requires. Not every timed interaction has the same requirements or exceptions.
10. Custom controls do not expose their name, role, state, or value
A custom-built control can look and behave like a button to a sighted mouse user while assistive technology cannot identify what it is or whether it is selected, expanded, or disabled. Some users may also be unable to operate it from the keyboard.
Rank #4
Relevant criteria: WCAG 4.1.2, Name, Role, Value (Level A), and 2.1.1, Keyboard (Level A). Fix: Prefer native HTML controls where they fit the task. If a custom widget is necessary, provide its accessible name, role, state, and value, keep them accurate as the interface changes, and implement the expected keyboard behavior. W3C includes incomplete accessibility API support for custom controls among its documented failure examples.
Does every website have to meet WCAG 2.1 AA?
No single answer applies to every site. WCAG is a technical standard; legal obligations depend on the jurisdiction, the type of organization, the applicable law, and the facts. In the United States, the ADA addresses state and local governments under Title II and businesses open to the public under Title III. The Department of Justice’s specific web-accessibility rule establishes a WCAG standard for covered Title II state and local government entities; it does not create that same rule for every private website. Other ADA duties, including effective communication and equal opportunity, may still matter in a particular situation. See the DOJ’s Guidance on Web Accessibility and the ADA.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →For entities covered by the Title II rule, the technical standard is WCAG 2.1 Level AA. The rule covers web content and mobile apps an entity provides or makes available, including through contracts and other arrangements. The DOJ describes exceptions for specified content and situations; they are not a blanket exemption for old content or vendor-provided material. Consult the Title II regulations and the DOJ’s web rule fact sheet for scope and exceptions.
As of October 4, 2026, following the DOJ’s April 2026 extension, the Title II compliance dates are April 26, 2027, for covered entities serving populations of 50,000 or more, and April 26, 2028, for covered entities under 50,000 and special district governments. These dates apply to the covered entities described by the rule, not to every website. Check the DOJ’s first-steps guidance for current deadlines and rule status; rulemaking can change.
The W3C identifies WCAG 2.2 as the current WCAG 2 Recommendation represented in its sources, published December 12, 2024, and recommends using the latest version. WCAG 2.2 added nine success criteria beyond WCAG 2.1. That makes WCAG 2.2 useful for broader accessibility work, but it does not change the Title II rule’s specified WCAG 2.1 AA standard. See the WCAG 2 overview and WCAG 2.2.
A WCAG failure can be evidence of an access barrier; it is not, by itself, a universal conclusion that a particular organization has violated the law or will be sued. Nor does a conformance claim guarantee immunity. For a specific dispute or legal obligation, get advice from qualified counsel familiar with the relevant jurisdiction and entity.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsCan an accessibility checker tell you whether a site conforms?
An automated checker can help find some detectable problems, but a pass score cannot establish whole-site conformance. Many issues require human judgment: whether alternative text conveys the right information, whether a keyboard journey makes sense, or whether an error message helps someone recover.
Use a layered review rather than a homepage-only scan:
- Define the target. Identify the law and WCAG version and conformance level that apply to the organization and the work. Do not assume the Title II rule governs a private business.
- Inventory real journeys. Include important page templates and tasks such as signing up, searching, paying, submitting forms, and using account controls. Include content and components supplied by vendors.
- Run automated checks. Treat flagged items as leads to verify and document, not as a complete verdict.
- Test manually. Use the keyboard through complete journeys; inspect focus visibility, labels, errors, zoom, reflow, and content order. Include assistive-technology testing appropriate to the site and its users.
- Assign fixes and retest. Give each issue an owner, fix it in the shared component or template where possible, then repeat the affected task. Record the pages, criteria, findings, and retest results.
A screenshot may help a team document a visual state, but it cannot tell you whether markup exposes relationships, a control works from a keyboard, or a screen reader receives the right information. ScreenshotNeo is a screenshot API and MCP server that can capture page images; it is not an accessibility checker or a WCAG certification service.
Or skip the browser setup
For a visual record of a page state during an audit, ScreenshotNeo takes a screenshot with one GET request. This does not replace keyboard, markup, or assistive-technology testing.
ScreenshotNeo API documentation
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp- Cookie and consent banners are accepted and removed, along with 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off.
- Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing; responses indicate the page verdict and billing status.
- An MCP server gives AI agents tools for screenshots, page information, and PDF capture.
- The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots.
Sign up for 1,000 free screenshots a month with no card.
How to prioritize remediation
Start with barriers that stop people from completing an essential task, then fix shared components that affect many pages. A single inaccessible dialog used across the site may matter more to access than a minor issue on a rarely visited page.
- Prioritize blocked tasks, including navigation, account access, payment, and form submission.
- Fix reusable templates and components at their source, then check every place they appear.
- Include vendor-controlled content and integrations in ownership and retesting plans; contractual delegation does not automatically remove a covered public entity’s responsibilities.
- Keep an issue log tied to the applicable criterion, affected journey, responsible owner, fix, and retest.
- Recheck when content, code, vendors, or design systems change; accessibility can regress after a repair.
Accessibility remediation is strongest when automated checks, manual keyboard review, assistive-technology testing, and repeatable ownership work together. The legal standard to apply depends on the organization and its circumstances, so treat a list of failures as a way to find and fix barriers—not as a substitute for legal analysis.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
