Home > Case Study > Website Development Case Studies > HDFC Pension Website Accessibility Case Study

Improving accessibility across a WordPress website through structured WCAG 2.2 Level AA remediation

The Client

The HDFC Pension website is a key digital touchpoint for individuals, corporate users, government employees and customers seeking information about the National Pension System (NPS), investment options, calculators, account-related guidance and educational resources.

Because the website serves a broad audience and includes content-heavy pages, interactive tools, forms, videos, navigation menus and third-party components, accessibility had to be addressed across both content and technology layers.

The Objective

The objective was to improve the accessibility of the HDFC Pension WordPress website and align the audited scope more closely with WCAG 2.2 Level AA requirements.

  • Make website content easier to understand and navigate with screen readers.
  • Improve keyboard access, focus behaviour and interactive controls.
  • Strengthen colour contrast, text readability and responsive reflow.
  • Provide meaningful labels, alternative text, link purpose and semantic structure.
  • Create a documented, repeatable audit and verification process for future accessibility improvements.

The Challenge

The website combined WordPress content, Elementor components, reusable templates and third-party integrations. This created accessibility issues at multiple levels, ranging from content markup to generated HTML and dynamic widget behaviour.

A Large and Varied Website Scope

The audit covered 37 page areas and templates, including the global header and footer, homepage, NPS category pages, calculator, customer-service pages, disclosure pages, podcasts, videos and multiple blog templates.

Repeated Issues Across Shared Components

Issues present in common templates or shared widgets could appear across several pages. Fixes therefore had to be evaluated at component level rather than treated only as isolated page-level changes.

WordPress, Elementor and Third-Party Constraints

Some components generated markup, focus order, ARIA attributes or interaction behaviour that could not be safely changed through the available WordPress or Elementor controls. In other cases, a fix depended on code maintained by an external plugin or service provider.

Balancing Accessibility with Design and Functionality

Accessibility fixes had to preserve the website’s brand experience, responsive layouts, calculator functionality, menus, forms and ongoing content-management workflows.

Most Frequently Identified Issue Areas

WCAG SC

Issue area

Observations

1.4.3

Contrast (Minimum)

170

1.3.1

Info and Relationships

167

4.1.2

Name, Role, Value

149

2.4.4

Link Purpose (In Context)

82

1.1.1

Non-text Content

49

The Solution

1. Structured WCAG 2.2 AA Audit

Each audited page was assessed against applicable WCAG 2.2 Level A and Level AA success criteria. Findings were documented with severity, evidence, error descriptions, expected outcomes and implementation guidance.

Testing included NVDA screen-reader checks, keyboard testing, visual review and automated or assisted checks using aXe DevTools, Colour Contrast Analyser, Windows Magnifier, target-size checks and text-spacing checks across Chrome and Firefox on Windows 11.

2. Prioritised Remediation

The development team addressed issues based on severity, user impact, recurrence and technical feasibility. Reusable template fixes were prioritised where they could improve multiple pages at once.

3. Accessibility Improvements Implemented

  • Added or corrected alternative text for informative images and suppressed unnecessary announcements for decorative images.
  • Improved heading hierarchy, semantic structure and landmark usage so screen-reader users could understand page relationships more clearly.
  • Enhanced text and non-text colour contrast to improve readability for users with low vision or colour-vision differences.
  • Improved keyboard operability, focus order and visible focus treatment for interactive elements.
  • Added clearer accessible names, roles, states and values for buttons, menus, dialogs and controls.
  • Improved link purpose and discernible text so links could be understood outside purely visual context.
  • Strengthened labels, instructions and error communication for applicable form fields.
  • Reviewed responsive reflow, text resizing, target sizing and spacing behaviour across device widths.

4. Iterative Verification

The remediation work was tested through four verification rounds. Issues were rechecked, reopened when a fix was incomplete, and closed only after the expected accessibility behaviour was confirmed within the audited environment.

Managing WordPress and Third-Party Limitations

Not every issue could be resolved safely within the project’s implementation boundary. Some behaviours were controlled by WordPress core, Elementor native widgets, third-party plugins or externally maintained components.

Where a direct fix was unavailable, would risk breaking functionality, or could be overwritten by future plugin updates, the issue was documented as a technical exception with the relevant development rationale. Common constraints included:

  • Generated heading or landmark markup that was not exposed through editable widget settings.
  • Focus order and hidden-menu behaviour controlled by native navigation or popup components.
  • ARIA states, roles or attributes generated by third-party widgets.
  • Dynamic calculator, chart, media or embedded-service behaviour outside direct code ownership.
  • Touch-target or interaction patterns that required vendor-level component changes.

This approach ensured transparency: unresolved items were not presented as completed, and platform-dependent exceptions were retained in the audit trail for future review when plugin or platform capabilities change.

The Result

Status

Count

Share of total

Remediated and closed

578

71.7%

Documented platform/third-party exceptions

228

28.3%

Total observations

806

100%

Key Outcomes

  • 578 accessibility observations were remediated and closed within the audited scope.
  • All 806 observations were tracked with status, evidence and implementation or exception notes.
  • Screen-reader interpretation improved through stronger alternative text, headings, landmarks and accessible control names.
  • Keyboard and low-vision usability improved through focus, contrast, resizing, reflow and target-size reviews.
  • Shared WordPress components were improved wherever the platform allowed safe and maintainable changes.
  • The final audit created a clear accessibility backlog for future platform, plugin and vendor updates.

Business and User Value

The project made key areas of the HDFC Pension website more inclusive and easier to use for people who rely on screen readers, keyboard navigation, magnification or clearer visual presentation. It also established a more disciplined accessibility process for future website updates.

The Conclusion

Through a combination of detailed auditing, prioritised WordPress remediation and repeated verification, HDFC Pension significantly improved accessibility across its website. The engagement closed approximately 71.7% of identified observations and documented the remaining platform-dependent constraints instead of masking them.

The result is a more accessible digital experience, a stronger technical foundation and a transparent roadmap for continued improvement as WordPress, Elementor and third-party technologies evolve.

60+

Client Testimonial

200+

Global Brands

70+

Awards & Recognition

130+

Success Stories

How useful was this post?

0 / 5. 0

Share this article

Improving Accessibility Across a WordPress Website Through Structured WCAG 2.2 Level AA Remediation