WCAG delivery isn’t about finding issues; it’s about reporting them clearly, consistently, and defensibly.
Digital agencies are increasingly expected to deliver accessibility as part of standard website delivery. But many teams still struggle with how accessibility issues should be identified, prioritised, and most importantly, reported in a way clients and developers can actually act on.
Agencies often struggle not because issues are hard to find, but because they don’t have a clear framework for documenting and resolving them. Before you dive into issue lists, it helps to understand design-stage accessibility guidance that shapes expectations early and prevents unnecessary rework.
This article outlines the 10 accessibility issues agencies must consistently report on when delivering WCAG 2.2 Level AA conformance, and explains what good reporting looks like in a real delivery context.
Why reporting matters more than scanning
Automated accessibility scans can surface hundreds of potential issues, but raw scan results are rarely useful on their own.
Clients don’t want lists.
Developers don’t want vague guidance.
Agencies need clear, prioritised, defensible reporting that supports delivery decisions.
Strong WCAG delivery reporting should:
- explain what the issue is
- clarify why it matters
- show who it impacts
- guide how to fix it
The following issues are the ones agencies should always expect to identify, document, and explain during WCAG delivery.
1. Missing or incorrect text alternatives
What it is
Images, icons, and non-text elements without appropriate alternative text (alt attributes), or with text alternatives that don’t convey meaning.
Why it matters
Screen reader users rely on text alternatives to understand content and functionality. Decorative images, functional icons, and informative graphics all require different handling under WCAG.
How it shows up in agency projects
- Icons implemented as background images
- Decorative images incorrectly announced
- Complex graphics without contextual alternatives
What good reporting looks like
- Identify the element
- Classify it as decorative, functional, or informative
- Provide a recommended text alternative (or mark as decorative)
Common agency mistake
Reporting “missing alt text” without context or recommendations.
2. Insufficient colour contrast
What it is
Text or interface elements that don’t meet WCAG contrast ratios (4.5:1 for body text, 3:1 for large text and UI components).
Why it matters
Low contrast affects users with low vision, colour vision deficiencies, and users viewing content in poor lighting conditions.
How it shows up
- Brand colour palettes overriding accessibility
- Placeholder text with low contrast
- Disabled states that disappear visually
What good reporting looks like
- Specific contrast ratios
- Affected elements
- Suggested colour adjustments that preserve brand intent
Common agency mistake
Flagging contrast failures without design-aware solutions.
3. Keyboard navigation failures
What it is
Interactive elements that cannot be reached, operated, or exited using a keyboard alone.
Why it matters
Many users rely on keyboards or switch devices rather than a mouse or touch input.
How it shows up
- Custom components without focus handling
- Modals that trap focus
- Hidden focus states
What good reporting looks like
- Clear reproduction steps
- Description of expected vs actual behaviour
- Identification of the affected component
Common agency mistake
Reporting “keyboard inaccessible” without describing the user impact.
4. Missing or unclear focus indicators
What it is
Focus states that are missing, hidden, or visually indistinguishable from surrounding content.
Why it matters
Keyboard users need to understand where they are on the page at all times.
How it shows up
- Focus styles removed for aesthetic reasons
- Low-contrast focus outlines
- Focus lost during dynamic updates
What good reporting looks like
- Screenshots or video evidence
- Contrast values of focus indicators
- CSS-level guidance
5. Improper heading structure
What it is
Headings that don’t follow a logical hierarchy (e.g. skipping from H1 to H4).
Why it matters
Screen reader users rely on headings for page navigation and content understanding.
How it shows up
- Headings used for styling only
- Multiple H1s without structure
- Component-based pages without hierarchy rules
What good reporting looks like
- Structural explanation of the issue
- Suggested hierarchy corrections
- Reference to page templates or components
6. Form input errors and validation issues
What it is
Forms that don’t clearly identify errors, provide instructions, or associate labels correctly.
Why it matters
Forms are one of the highest-friction areas for users with disabilities.
How it shows up
- Placeholder-only labels
- Error messages without programmatic association
- Required fields not communicated
What good reporting looks like
- Identification of affected inputs
- Explanation of error handling failures
- Clear remediation steps
7. Non-descriptive link text
What it is
Links that use vague text like “click here” or “read more”.
Why it matters
Screen reader users often navigate by links alone, without surrounding context.
How it shows up
- CMS-generated “read more” links
- Repeated identical link labels
- Icon-only links
What good reporting looks like
- List of non-descriptive links
- Context-aware replacement suggestions
8. Missing accessible names for controls
What it is
Buttons, inputs, or interactive components without accessible labels.
Why it matters
Assistive technologies need a programmatic name to announce purpose.
How it shows up
- Icon-only buttons
- Custom components without ARIA labels
- SVG-based controls
What good reporting looks like
- Element identification
- Current accessible name (or lack thereof)
- Recommended fix
9. Dynamic content not announced
What it is
Content updates that occur without notifying assistive technologies.
Why it matters
Users may miss critical feedback or changes in state.
How it shows up
- Success messages
- Loading indicators
- Live validation feedback
What good reporting looks like
- Explanation of user impact
- Suggested ARIA live region usage
- Scope of affected flows
10. Inaccessible PDFs and downloadable content
What it is
Documents that don’t meet accessibility requirements.
Why it matters
WCAG applies to content, not just web pages.
How it shows up
- Unstructured PDFs
- Image-based documents
- Missing document language
What good reporting looks like
- Clear identification of document issues
- Guidance on remediation or alternatives
- Scope clarification (what’s in vs out)
What agencies should take away
Strong WCAG delivery isn’t about chasing every possible issue — it’s about reporting the right issues well.
Agencies that succeed in accessibility:
- prioritise clarity over volume
- explain impact, not just failures
- give developers something actionable
- provide clients with defensible evidence
This is exactly where structured WCAG verification and reporting tools make a difference.
Where IncluD fits
IncluD supports agencies by:
- tracking accessibility issues across templates and components
- providing clear, client-ready reporting
- aligning findings to WCAG 2.2 Level AA
- supporting remediation and re-verification
Our platform and services are designed to help agencies deliver accessibility with confidence — not guesswork.
IncluD supports agencies throughout the accessibility lifecycle — from design-stage accessibility guidance that informs early decisions, through WCAG conformance audits that provide clear, defensible evidence post-build, to ongoing WCAG monitoring that maintains confidence as sites evolve.
All of this is delivered through a purpose-built agency accessibility platform designed to fit real-world delivery workflows.
