The Most Challenging WCAG Success Criteria to Meet

Achieving full WCAG compliance is a fundamental requirement for creating accessible digital experiences. However, while some success criteria can be addressed with relatively simple fixes, others consistently prove more challenging across design, development, and content workflows. These difficult criteria often require deeper technical understanding and sustained attention throughout the product lifecycle. Understanding why they are difficult and how to address them can significantly improve accessibility outcomes.

This article briefly presents some of the most commonly challenging WCAG success criteria and the reasons they require extra care and expertise.

1.3.1: Info and Relationships

One of the most conceptually difficult requirements is WCAG 1.3.1: Info and Relationships. This success criterion requires that information, structure, and relationships conveyed through presentation must also be programmatically determinable or available in text.

In practice, this means that visual structure alone is not sufficient. Developers must ensure that relationships between elements, such as headings, lists, form labels, table headers, and grouped controls, are correctly represented in the HTML markup. For example, a visually styled section title must also be marked up as a proper heading level, and form inputs must be programmatically associated with their labels. Similarly, complex data tables require proper header associations so assistive technologies can interpret relationships between rows and columns.

This becomes especially challenging when teams rely heavily on visual design systems or component libraries that prioritize appearance over semantic structure. It requires a strong understanding of HTML semantics and how assistive technologies interpret page structure. Ensuring these relationships are preserved consistently across a digital product requires architectural decisions rather than isolated fixes.

1.2.2 Captions and 1.2.3 Audio Description

Time-based media accessibility is another major challenge, particularly WCAG 1.2.2 Captions and 1.2.3 Audio Description. These requirements ensure that users who are deaf, hard of hearing, blind, or visually impaired can access multimedia content.

Captions must accurately represent spoken dialogue, relevant sound effects, and meaningful audio cues, while audio descriptions must provide narration of essential visual information in videos. The difficulty here is not just technical; it is also logistical and financial. High-quality captions and audio descriptions often require human transcription, editing, and timing adjustments to ensure accuracy and synchronization. While automated tools for caption generation have improved significantly, they still frequently fall short of WCAG quality standards without manual correction.

Many organizations struggle with these criteria because they require dedicated production workflows, specialized skills, and additional budget. Unlike purely code-based accessibility fixes, media accessibility must be built into content creation pipelines from the start. 

2.1.1: Keyboard

WCAG 2.1.1 Keyboard requires that all functionality on a website or application must be operable using only a keyboard, without requiring a mouse or other pointer device.

While this may sound straightforward, it becomes increasingly complex in modern web applications. Many interfaces rely on advanced interactions such as drag-and-drop, custom dropdowns, modal dialogs, carousels, and hover-based menus. These patterns are often designed with pointer devices in mind and require significant reworking to support keyboard input effectively.

Keyboard accessibility requires continuous manual testing, not automated scanning. Developers must regularly test with keyboard-only navigation to ensure a consistent and accessible experience.

3.3.2: Labels or Instructions

WCAG 3.3.2 Labels or Instructions is another success criterion that is often underestimated in complexity. It requires that users be provided with labels or instructions when content requires user input.

At first glance, this seems simple, but in practice, it involves both technical implementation and thoughtful content design. Forms often suffer from unclear labels, missing instructions, or reliance on placeholder text instead of proper labeling. These issues can create significant barriers for users of assistive technologies as well as users with cognitive disabilities. The challenge increases when forms include real-time validation or dynamic error messaging. Error messages must not only be clearly written but also programmatically associated with the relevant form fields so screen readers can announce them. This typically requires careful use of ARIA attributes such as aria-describedby and aria-invalid.

Ensuring consistency across all forms is particularly difficult. It requires coordination between designers, developers, and content authors to ensure that labeling patterns are consistent, meaningful, and accessible throughout the entire digital product.

4.1.2: Name, Role, Value

Finally, WCAG 4.1.2 Name, Role, Value is especially challenging because it relates directly to custom interface components, which are widely used in modern JavaScript frameworks and design systems.

This success criterion ensures that all user interface components expose their name, role, and current value to assistive technologies. Native HTML elements such as buttons, inputs, and selects inherently provide this information, but custom-built components often do not.

Developers frequently create custom dropdowns, modals, tabs, and sliders using non-semantic elements like <div> or <span>. Without proper ARIA roles, states, and properties, these components become inaccessible or confusing for assistive technology users. Missing labels, incorrect ARIA roles, or failure to update state changes can render a component unusable. For example, a toggle switch that visually changes state must also correctly communicate its state programmatically.

Meeting this criterion requires deep knowledge of the ARIA framework, a good understanding of how different assistive technologies interpret and announce interface elements, and strong familiarity with accessible component patterns used to build complex user interface controls.
 

Conclusion

The most challenging WCAG success criteria tend to be those that require structural thinking, cross-team collaboration, or significant production effort. 

True accessibility compliance requires more than technical fixes; it demands intentional design decisions, consistent development practices, and a shared understanding of accessibility principles across teams.

By focusing on semantic HTML, robust keyboard interaction, meaningful labeling, accessible media practices, and well-designed component systems, organizations can make substantial progress toward meeting even the most difficult WCAG requirements. In the long term, this leads not only to compliance but to more accessible and usable digital products for all users.

Let's make the digital world more accessible!