Case Study: Making a WordPress Template Accessible

Web App

Overview

Many small businesses and nonprofits rely on WordPress themes for their websites. While these templates offer quick setup, they often overlook accessibility best practices, unintentionally creating barriers for users with disabilities.

For this case study, I selected the ColorMag WordPress Demo Site (a publicly available theme demo) to simulate the type of accessibility issues I’ve frequently observed in real-world websites.

Goal:

Identify barriers to accessibility using WCAG 2.1 AA guidelines
Show how they affect real users (e.g., screen reader, low vision, keyboard-only users)
Propose redesign and remediation strategies in both Figma and code

Audit Process

I conducted an accessibility audit using both automated tools and manual testing:

🔍 Automated tools: Axe DevTools, WAVE, Lighthouse
⌨️ Manual checks: Keyboard-only navigation, zoomed text at 200%, NVDA Screen Reader

Why?

Key Findings and FIxes

1. Color Contrast Issues

Sidebar widget text and button labels failed contrast ratio (≈ 2.8:1, below the 4.5:1 WCAG minimum).
Low-contrast hover/focus states on navigation links made them invisible to low-vision users.

📷 [Screenshot: Original sidebar with low-contrast grey text on white background]

2. Heading Structure

Heading levels skipped from <h1> → <h3> without <h2>.
This confused screen reader users and broke logical page flow.

📷 [Screenshot: Heading structure audit showing skipped levels]

3. Missing Alt Text

Several images had no alt attribute or generic text like “image123.jpg.”
Users relying on screen readers received no meaningful context.

📷 [Screenshot: Image missing alt text from WAVE results]

4. Keyboard Navigation Gaps

Dropdown menus could not be accessed with Tab/Enter keys.
No visible focus indicators for links or buttons.

📷 [Screenshot: Keyboard focus disappearing on navigation menu]

5. Form Accessibility

Search bar had no associated <label>.
Screen reader users heard only “edit text” with no context.

📷 [Screenshot: Form input without label]

6. ARIA Landmarks Missing

No semantic roles (<nav>, <main>, <footer>), making navigation harder in assistive technologies.

Redesign & Fixes

Visual Fixes (Figma Mockups)

Increased sidebar text contrast (2.8:1 → 4.9:1).
Added bold, visible focus indicators on navigation links.
Structured content blocks with logical heading hierarchy.

📷 [Before vs After mockup: sidebar contrast improvement]
📷 [Before vs After mockup: focus states on navigation]

Code Fixes (HTML/CSS/ARIA)

Contrast Fix:

.widget-title {
  color: #1a1a1a; /* Darkened for AA compliance */
}

Focus States:

a:focus, button:focus {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Accessible Form Label:

<label for="site-search">Search the site:</label>
<input type="search" id="site-search" name="search"

ARIA Landmark for Navigation:

<nav role="navigation" aria-label="Main menu">
  <ul>
    <li><a href="#">Home</a></li>
    ...
  </ul>
</nav>

Outcomes

✅ Improved contrast ratio from 2.8:1 → 4.9:1
✅ Keyboard-only navigation enabled with visible focus states
✅ Alt text provided for meaningful images, ignored for decorative ones
✅ Semantic HTML + ARIA roles improved screen reader navigation
✅ WCAG 2.1 compliance improved from ~Level A → solid Level AA

This project reinforced that accessibility is usability. Issues like missing labels, weak contrast, and broken keyboard navigation don’t just affect users with disabilities — they also impact users on mobile, in bright sunlight, or navigating with one hand.

Key takeaway: Accessibility should be built in from the start of design and development, not treated as an afterthought.

ColorMag WordPress Demo Site