Web Accessibility Audit — WCAG 2.2.

Web accessibility is not a feature. It is a legal requirement and a moral imperative.

1 in 5 people have a disability. Of those, a significant portion use assistive technologies to access the web: screen readers (for blindness), voice control (for motor disabilities), keyboard navigation (for those who can't use a mouse), color contrast adjustments (for low vision).

If your website doesn't work with these technologies, you're excluding 20% of potential customers. You're also exposing yourself to legal risk under equality legislation.

More than that, accessibility improvements benefit everyone. Captions help people watching videos in loud environments. Keyboard navigation helps laptop users with touchpad issues. Clear visual hierarchy helps anyone using a small screen or poor eyesight.

At Victor Codes, accessibility is not an add-on. It's a core principle of every project.

Why Accessibility Matters

Legal requirement — Under the Equality Acts (in Ireland and the UK) and equivalent legislation elsewhere, websites must be accessible. Non-compliance exposes organizations to legal action.

Moral imperative — People with disabilities have the right to access information and services online. Excluding them is discrimination.

Business case — Accessible sites work better for everyone. Better keyboard navigation benefits power users. Better contrast helps people on bright screens or with poor eyesight. Captions help people in loud environments.

SEO benefit — Many accessibility improvements (clear heading structure, alt text on images, proper semantic markup) also improve SEO.

WCAG 2.2 Standards

WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility. WCAG 2.2 is the current version. It has three conformance levels:

• Level A — Basic accessibility. Minimum standard.
• Level AA — Enhanced accessibility. Recommended standard.
• Level AAA — Advanced accessibility. Exceeds requirements.

Most organizations aim for Level AA, which covers 95%+ of accessibility needs.

WCAG 2.2 Covers Four Principles

1. Perceivable — Content must be perceivable to all users.

• Images must have alt text (screen reader users can understand the image)
• Captions must be provided for video (deaf users can understand content)
• Color alone must not convey meaning (colorblind users understand information)
• Contrast must be sufficient (low vision users can read text)

2. Operable — Users must be able to navigate and interact with content.

• Keyboard navigation must work throughout the site (motor disability users)
• Users must have time to read content (some users need more time)
• Content must not cause seizures (photosensitive epilepsy users)
• Navigation must be clear and consistent

3. Understandable — Content must be understandable to all users.

• Language must be clear (cognitive disabilities, non-native speakers)
• Navigation must be predictable (users shouldn't be surprised)
• Instructions and error messages must be clear
• Content organization must be logical (proper heading hierarchy)

4. Robust — Content must work with assistive technologies.

• Semantic HTML (proper heading tags, button tags, form labels)
• ARIA attributes when needed (for dynamic content)
• Valid HTML (no broken code that breaks assistive technologies)

Common Accessibility Issues Found in Audits

• Missing alt text on images — Screen reader users have no idea what the image shows.
• Poor color contrast — Low vision users can't read text on background.
• Keyboard navigation broken — Users who can't use a mouse can't interact with the site.
• Missing form labels — Screen reader users don't know what form fields are for.
• Images of text instead of real text — Screen readers can't read text in images.
• Auto-playing videos or audio — Users can't control or mute unwanted content.
• Unmapped heading hierarchy — h1 → h2 → h4 (skipping h3) breaks document structure.
• Buttons that aren't semantic buttons — Screen readers don't recognize as interactive elements.
• No focus indicators on keyboard navigation — Keyboard users can't tell which element is focused.
• Infinite scroll without pagination — Screen reader users can't navigate to end of content.

Accessibility Audit Process

1. Automated testing (1 day) — Axe DevTools and WAVE identify issues that can be automatically detected (missing alt text, contrast issues, semantic problems).

2. Manual testing (2–3 days)

• Keyboard navigation testing (tab through every interactive element)
• Screen reader testing with NVDA/JAWS
• Mobile screen reader testing (VoiceOver on iPhone, TalkBack on Android)
• Color contrast verification
• Heading hierarchy review
• Form testing with keyboard

3. Report generation (1 day) — Comprehensive report detailing:

• WCAG 2.2 criteria met and not met
• Severity of each issue (critical, major, minor)
• Specific locations of issues
• Remediation steps required
• Estimated effort to fix

Accessibility Remediation

After audit, I can implement fixes:

Critical issues (must fix) — Site is unusable without these:

• Missing alt text on important images
• Color contrast below WCAG minimum
• Form fields missing labels
• Keyboard navigation completely broken

Major issues (should fix) — Significant barriers:

• Heading hierarchy broken
• Modal dialogs not trapping focus
• Links with no meaningful text
• List markup misused

Minor issues (nice to fix) — Improvements but not barriers:

• Redundant aria-labels
• Unused ARIA attributes
• Minor semantic issues

Common Remediation Tasks

• Adding alt text to hundreds of images (if image-heavy site)
• Improving color contrast on text and interactive elements
• Properly labeling form fields
• Implementing ARIA for dynamic content
• Fixing heading hierarchy
• Adding skip navigation links
• Implementing keyboard traps properly (modals, menus)
• Adding focus indicators
• Ensuring proper semantic HTML

Accessibility for New Projects

For new websites, I build accessibility in from the start. It adds roughly 5–10% to development time but prevents the need for expensive remediation later.