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 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:

​

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.

​

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

​

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 — The complete technical standard
• Understanding WCAG 2.2 — Explanations and examples for each success criterion
• ARIA Authoring Practices Guide — Patterns for building accessible interactive components
• WebAIM Contrast Checker — Tool for testing color contrast ratios