> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gradial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Accessibility Reports

> Identify, prioritize, and resolve WCAG 2.2 AA accessibility violations across your digital content with Gradial's automated accessibility reports.

## Overview

Accessibility isn't just a compliance requirement—it's about ensuring your content reaches and serves all users, including those who rely on assistive technologies. Gradial makes accessibility actionable by:

* Automatically detecting accessibility violations in your content
* Distinguishing between issues you can fix directly in AEM and those requiring design or development changes
* Providing clear remediation guidance for each issue
* Tracking accessibility status across pages and over time

## WCAG 2.2 AA Compliance

Gradial's accessibility checks are based on the [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) Level AA standard. This is the globally recognized benchmark for digital accessibility and the standard referenced by most accessibility regulations and policies.

### The Four Principles

WCAG organizes requirements around four principles. Your content must be:

**Perceivable** Users must be able to perceive the content through at least one of their senses. This includes providing text alternatives for images, captions for video, and sufficient color contrast.

**Operable** Users must be able to navigate and interact with your content. This includes keyboard accessibility, clear link text, and avoiding content that could cause seizures.

**Understandable** Users must be able to understand both the content and how to use the interface. This includes readable text, predictable navigation, and helpful error messages.

**Robust** Content must be compatible with current and future tools, including assistive technologies. This includes valid HTML, proper ARIA usage, and semantic markup.

### What Gradial Checks

Accessibility reports validate against key WCAG 2.2 AA success criteria, including:

| Category            | Checks Include                                                    |
| :------------------ | :---------------------------------------------------------------- |
| **Images**          | Alt-text presence, decorative image handling, image-of-text usage |
| **Structure**       | Heading hierarchy, landmark regions, list markup                  |
| **Links & Buttons** | Discernible text, descriptive labels, keyboard focus              |
| **Forms**           | Input labels, error identification, required field indication     |
| **Color**           | Contrast ratios, color-only information                           |
| **ARIA**            | Valid attributes, permitted roles, proper usage patterns          |
| **Media**           | Captions, audio descriptions, autoplay controls                   |

## Using Accessibility Reports

Gradial supports two primary workflows: auditing existing content and validating new content before publication.

### Auditing Existing Pages

Use accessibility reports to audit pages already in production and identify remediation priorities.

**Running an Audit**

1. Enter the URL of the page you want to audit
2. Run the QA review to generate a report
3. Filter to the **Accessibility** tab to focus on accessibility results

**Prioritizing Remediation**

Not all accessibility issues require the same level of effort to fix. The report helps you prioritize by showing:

* **Severity** — How significantly the issue impacts users
* **Scope** — How many elements or pages are affected
* **Actionability** — Whether the issue can be fixed in AEM or requires other teams

Start with high-severity issues that affect the most users, then work through lower-priority items systematically.

### Validating New Content

Integrate accessibility checks into your content workflow to catch issues before they go live.

**Pre-Publication Checks**

After authoring new content or making updates:

1. Run QA before submitting for review
2. Review the accessibility section of the report
3. Resolve any issues flagged
4. Re-run QA to confirm fixes
5. Proceed with publication

By checking accessibility before publication, you avoid introducing new issues into production and reduce the backlog of remediation work.

## Remediation Workflows

Accessibility issues fall into two categories: those you can fix directly in AEM and those requiring coordination with design or development teams.

### Issues You Can Fix in AEM

Many common accessibility issues can be resolved by content authors directly within AEM. Gradial can automatically suggest or apply fixes for these issues.

**Missing Alt-Text**

When an image component lacks alt-text, Gradial flags the issue and can:

* Prompt you to add descriptive alt-text
* Pull alt-text from DAM metadata if available
* Suggest marking the image as decorative if appropriate

*How to fix:* Edit the image component and add alt-text that describes the image's purpose or content. If the image is purely decorative, set the alt attribute to empty.

**Missing Form Labels**

Form inputs without associated labels are inaccessible to screen reader users.

*How to fix:* Ensure every form field has a visible label connected via the `for` attribute or wrapped around the input.

**Empty Links and Buttons**

Links or buttons without discernible text can't be understood by assistive technology users.

*How to fix:* Add visible text, or for icon-only buttons, add an aria-label that describes the action.

**Heading Hierarchy Issues**

Skipped heading levels (e.g., jumping from H1 to H3) create navigation problems for screen reader users.

*How to fix:* Restructure headings to follow a logical hierarchy without skipping levels.

### Issues Requiring Other Teams

Some accessibility issues stem from design decisions or code implementation that content authors cannot change directly. Gradial helps you identify and route these appropriately.

**Color Contrast**

When text doesn't have sufficient contrast against its background, it's difficult for users with low vision to read.

*Why authors can't fix it:* Contrast issues typically involve brand colors, component styles, or background images controlled by design systems or CSS.

*Remediation path:* Flag the issue to your design team with the specific contrast ratio and WCAG requirement. They can update the design system or provide alternative color options.

**Focus Indicators**

Interactive elements must have visible focus states for keyboard users.

*Why authors can't fix it:* Focus styles are defined in CSS and component code.

*Remediation path:* Report to your development team. Include which components lack visible focus and the relevant WCAG criteria (2.4.7 Focus Visible).

**Keyboard Traps**

Users must be able to navigate into and out of all components using only a keyboard.

*Why authors can't fix it:* Keyboard behavior is controlled by JavaScript and component implementation.

*Remediation path:* Document which component creates the trap and the steps to reproduce. Route to development for investigation.

**Complex Widget Accessibility**

Carousels, modals, accordions, and other interactive components require specific ARIA patterns and keyboard handling.

*Why authors can't fix it:* These behaviors are built into component code.

*Remediation path:* Note the component and specific issue (e.g., "carousel lacks pause button" or "modal doesn't trap focus"). Development can update the component to follow [ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/).

### Routing Issues to the Right Team

When Gradial identifies an issue that requires design or development work:

1. **Document the issue** — Note the page URL, component, and specific failure
2. **Reference the WCAG criterion** — Include the success criterion number and level (e.g., "1.4.3 Contrast Minimum, Level AA")
3. **Explain the user impact** — Help the team understand who is affected and how
4. **Track in your issue system** — Create tickets in your project management tool so issues aren't lost
5. **Verify the fix** — Re-run the accessibility report after changes are deployed

## Understanding Results

### Status Definitions

| Status         | Meaning                                                             |
| :------------- | :------------------------------------------------------------------ |
| **Passed**     | The content meets the accessibility requirement                     |
| **Failed**     | A violation was detected that must be corrected                     |
| **Incomplete** | Automated testing found something that requires manual verification |

### Incomplete Results

Some accessibility requirements can't be fully validated through automation. When you see "Incomplete," manual review is needed to determine pass or fail.

Common incomplete checks include:

* **Alt-text quality** — Automation can detect if alt-text exists, but only a human can verify it accurately describes the image
* **ARIA accuracy** — Automation can check if ARIA is valid, but only testing confirms it creates the intended experience
* **Reading order** — Automation can identify potential issues, but manual testing confirms logical flow

For incomplete results, test the specific element with assistive technology or keyboard navigation to make a final determination.

## Best Practices

### Building Accessibility into Your Workflow

**Check early and often.** Run accessibility reports during authoring, not just before publication. It's easier to fix issues when the content is fresh.

**Train authors on common issues.** When authors understand accessibility basics, they create better content from the start.

**Establish clear handoff processes.** Define how content-fixable issues are resolved vs. how design/dev issues are routed and tracked.

### Maintaining Accessible Content

**Audit regularly.** Even pages that passed initially can develop issues through updates. Schedule periodic audits of high-traffic pages.

**Monitor for regressions.** When components or templates change, re-check pages using those elements.

**Learn from patterns.** If the same issues appear repeatedly, address the root cause—update templates, improve author training, or refine component defaults.

## Additional Resources

* [WCAG 2.2 Specification](https://www.w3.org/TR/WCAG22/) — The complete technical standard
* [Understanding WCAG 2.2](https://www.w3.org/WAI/WCAG22/Understanding/) — Explanations and examples for each success criterion
* [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) — Patterns for building accessible interactive components
* [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/) — Tool for testing color contrast ratios