Building for Accessibility: Why WCAG Isn't a Box-Ticking Exercise
Accessibility compliance treated as a checklist produces accessible products that nobody actually wants to use. Here's a better approach.
WCAG 2.1 AA compliance is increasingly a requirement — in public sector digital products in Ireland, in regulated financial services, and in higher education institutions. The problem is that 'compliant' and 'accessible' are not the same thing.
On the Trinity College Dublin student app project — serving approximately 18,000 students across all faculties — accessibility was established as a baseline requirement from the first day of the engagement. Not a feature to be added at the end. Not a checklist to be run through before launch. A design constraint that shaped every decision from information architecture to colour contrast ratios to interaction patterns.
The Compliance Trap
The accessibility compliance trap looks like this: a product is designed and built to meet the needs of the assumed typical user. Late in the process, an accessibility audit is run. Issues are identified and fixed — usually by adding ARIA labels, adjusting contrast ratios, and adding keyboard navigation. The product passes compliance checks. It is not, however, actually accessible in any meaningful sense, because the underlying journey architecture was never designed with diverse needs in mind.
The accessible product that emerges from this process is technically compliant and practically unusable for the people it's supposed to serve.
Designing for the Full Range
On the TCD project, we ran usability research with students with visual impairments, students with dyslexia, and students with motor difficulties from the start of the project — not as a separate 'accessibility track' but as part of the core research programme. Their needs shaped the information architecture, the reading hierarchy, the touch target sizes, and the notification design.
What we consistently found was that designing for the full range of needs produced better designs for everyone. Larger touch targets are better for everyone. Clearer reading hierarchies benefit all users. Offline functionality — prioritised because of students with unreliable network access — improved the experience for every student on campus.
The An Post Money Parallel
The same principle applied on An Post Money, where the user base spanned from tech-savvy urban professionals to older, less digitally confident customers in rural communities. Designing for the least digitally confident user in that spectrum — simpler language, clearer feedback, more forgiving error handling — produced a better app for every user.
Where to Start
- Include diverse user needs in your research programme from the start — not as a separate exercise.
- Set WCAG AA as a design constraint, not a post-launch audit.
- Test with assistive technology users before launch — screen reader testing in particular surfaces issues that automated tools miss.
- Treat every accessibility improvement as a universal improvement.
