Category: Testing and Evaluation

Common Failures

Simply put

In digital accessibility, "common failures" generally refers to frequently recurring mistakes that prevent web content from meeting accessibility standards, such as those defined in the Web Content Accessibility Guidelines (WCAG). Identifying these recurring problems helps teams find and fix barriers that commonly affect people with disabilities. The evidence provided does not include material specific to accessibility, so this entry describes the term as it is generally used rather than citing a recognized accessibility authority.

Formal definition

The provided evidence packet does not contain sources addressing "common failures" in the context of digital accessibility; the available sources relate to reliability engineering concepts (such as common mode failures and common cause failures) and general mechanical failure, which are outside the scope of an accessibility glossary. In accessibility practice, the W3C's WCAG documentation uses the specific term "Common Failures" to describe documented, known ways that content fails to satisfy one or more WCAG success criteria; these are published as informative "Failure" techniques distinct from normative success criteria and sufficient/advisory techniques. Because no accessibility-authority evidence was supplied here, practitioners should consult the current W3C "Understanding WCAG" and "Techniques for WCAG" materials for authoritative definitions and the current list of documented failures, and note that detecting such failures typically requires a combination of automated, manual, and assistive-technology testing. This entry is informational and not legal advice.

Why it matters

In digital accessibility, recurring mistakes are often the difference between content that people with disabilities can use and content that excludes them. When teams can recognize the patterns that commonly cause pages to fall short of standards such as the Web Content Accessibility Guidelines (WCAG), they can prioritize fixes that remove barriers affecting the most users. The W3C's WCAG materials formalize this idea through documented "Failure" techniques, which describe known ways that content fails to satisfy one or more success criteria.

Understanding common failures also helps set realistic expectations about testing. Detecting these problems generally requires a combination of automated, manual, and assistive-technology testing, because automated tools catch only a portion of accessibility issues. Treating a documented failure as fixed based on an automated scan alone can leave real barriers in place for users who rely on screen readers, keyboard navigation, or other assistive technologies.

It is worth noting that meeting WCAG success criteria and avoiding documented failures supports accessibility but does not by itself guarantee an accessible experience for every user, nor does it guarantee immunity from legal claims. This entry is informational and describes the term as it is generally used; it is not legal advice, and requirements evolve through regulation and case law. Readers with specific compliance questions should consult qualified legal counsel and current agency guidance.

Who it's relevant to

Accessibility Engineers and QA Testers

Those responsible for testing web content use documented failures as concrete patterns to check for during remediation. Because automated tools catch only a portion of issues, engineers generally pair scans with manual review and assistive-technology testing to confirm whether a documented failure is present.

UX Designers and Developers

Designers and developers benefit from knowing which recurring mistakes commonly cause content to fall short of WCAG success criteria, so they can avoid introducing those patterns early rather than fixing them later. Consulting the W3C's "Techniques for WCAG" materials helps translate known failures into design and coding practices.

Compliance Officers and Business Leaders

Leaders overseeing accessibility programs can use the concept of common failures to prioritize remediation and allocate testing resources. They should keep in mind that avoiding documented failures supports conformance but does not by itself guarantee an accessible experience or legal immunity, and that requirements evolve through regulation and case law.

Legal Counsel

Counsel evaluating accessibility posture may find documented failure techniques useful as a reference for common barriers, while recognizing that these are informative W3C materials rather than binding law. This entry is not legal advice, and specific obligations depend on jurisdiction and current agency guidance.

Inside Common Failures

WCAG Failure Techniques (F-numbered)

The W3C publishes documented failure examples, identified with 'F' codes (for example, F65), that describe specific authoring practices known to cause a violation of one or more WCAG success criteria. These are informative examples, not an exhaustive or normative list.

Missing Text Alternatives

A common failure in which non-text content such as images, icons, or controls lacks an appropriate text alternative, affecting users who rely on screen readers. This relates to WCAG success criterion 1.1.1 (Non-text Content), a Level A criterion present since WCAG 2.0.

Insufficient Color Contrast

Text or interface components presented with contrast below the thresholds defined by relevant success criteria, which can make content difficult to perceive. Contrast requirements for text are commonly associated with WCAG 1.4.3 (Contrast Minimum) at Level AA.

Keyboard Inaccessibility

Interactive elements that cannot be reached or operated using a keyboard alone, or that trap keyboard focus. These issues relate to criteria such as 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap), both Level A.

Improper Structure and Semantics

Content that lacks programmatically determinable headings, labels, roles, or relationships, which can undermine navigation and understanding by assistive technologies. Related criteria include 1.3.1 (Info and Relationships) at Level A.

Missing Form Labels and Instructions

Form fields without associated labels or clear instructions, which can prevent users from completing tasks. This relates to criteria such as 3.3.2 (Labels or Instructions) at Level A and 4.1.2 (Name, Role, Value) at Level A.

Common questions

Answers to the questions practitioners most commonly ask about Common Failures.

If our site passes automated accessibility scans, have we eliminated common failures?

No. Automated testing detects only a portion of accessibility issues, commonly cited as a minority of WCAG success criteria that can be reliably checked by software. Many common failures, such as inaccurate alternative text, illogical reading or focus order, ambiguous link purpose, and keyboard traps, require manual review and testing with assistive technologies to detect. Passing an automated scan should be treated as a starting point rather than confirmation that common failures have been eliminated.

Does avoiding common failures and meeting WCAG success criteria guarantee legal compliance?

Not necessarily. Addressing common failures and meeting WCAG success criteria (with AA often cited as the target) can substantially improve accessibility, but conformance is distinct from legal compliance and from real-world usability. In the US, obligations may arise under Title II or Title III of the ADA, Section 508, or Section 504 depending on the entity, and requirements continue to evolve through regulation and case law. Meeting a technical benchmark does not guarantee immunity from legal claims, and this guidance is not legal advice, consult qualified legal counsel for your specific situation.

How should a team prioritize which common failures to fix first?

Teams commonly prioritize by the severity of user impact and how frequently the failure occurs across the site. Failures that block core tasks, such as keyboard traps, inaccessible forms, or missing labels on interactive controls, generally warrant attention before less critical issues. Prioritization should account for high-traffic pages and essential user journeys, and combine automated findings with manual and assistive technology testing to capture failures that scans miss.

What testing methods help catch common failures that automated tools miss?

Manual testing and testing with assistive technologies are generally needed to catch failures automated tools cannot reliably detect. This commonly includes keyboard-only navigation testing, screen reader testing, checking that focus order and reading order are logical, verifying that alternative text is meaningful, and confirming that error messages and instructions are conveyed to assistive technology. Involving people with disabilities in usability testing can further surface issues that pass technical checks but hinder real use.

How can teams prevent common failures from being reintroduced over time?

Common failures often recur as content and features change. Teams may reduce recurrence by building accessibility into design and development workflows, using accessible component libraries and patterns, providing training, and incorporating both automated and manual checks into their process. Documenting known failure patterns and reviewing new content before publication can help, though ongoing monitoring is generally needed because new failures can be introduced with each update.

Where do common failures typically appear in real-world interfaces?

Common failures frequently appear in images lacking meaningful alternative text, form fields without programmatic labels, low color contrast, links whose purpose is unclear out of context, content that is not operable by keyboard, and custom interactive components that do not expose their role, state, or name to assistive technology. Because these patterns recur across many sites, they are useful areas to examine first when evaluating an interface.

Common misconceptions

If an automated scan reports no failures, the content is accessible and compliant.

Automated testing detects only a portion of potential issues. Many failures, including those involving meaningful text alternatives, logical reading order, and usability with assistive technology, generally require manual and assistive technology testing to identify. Passing automated checks does not guarantee an accessible experience or immunity from legal claims.

The WCAG failure techniques are a complete, mandatory checklist of everything that can go wrong.

The W3C's documented failures are informative examples that illustrate known problems; they are not normative and are not exhaustive. Conformance is measured against the success criteria themselves, and content can fail a criterion in ways not captured by a specific documented failure technique.

Fixing all identified common failures ensures full legal compliance under the ADA.

Conformance with technical success criteria is distinct from legal compliance. In the US, courts and settlements have often referenced WCAG as a benchmark rather than a codified rule, and requirements evolve through regulation and case law. Addressing common failures reduces barriers but does not by itself guarantee legal safety; consult qualified legal counsel and current agency guidance.

Best practices

Combine automated scanning with manual review and testing using assistive technologies such as screen readers and keyboard-only navigation, since automated tools catch only a portion of issues.

Map each identified failure to the specific WCAG success criterion and conformance level it affects, and note which WCAG version introduced that criterion to avoid conflating requirements across versions.

Prioritize failures that block core tasks, such as missing form labels, keyboard traps, and missing text alternatives, before addressing lower-impact issues.

Verify text alternatives for meaning and context rather than mere presence, since an image with an unhelpful or empty alternative can still fail 1.1.1.

Document remediation decisions and retest after fixes to confirm that changes resolve the failure without introducing new barriers.

Treat this guidance as informational rather than legal advice, and consult qualified legal counsel and current agency rulemaking when compliance obligations are at stake.