Accessibility is no longer a niche topic. Around 1.3 billion people worldwide depend on accessible digital services. At the same time, more than 90% of all websites fail basic WCAG checks. This is not a fringe problem but the normal state of affairs. Accordingly, many users give up when a system is not usable – with a direct impact on usage and conversion.
For Liferay projects, the starting position is fundamentally good. The platform delivers clean HTML, supports semantic structures and comes with many components that are accessible in principle. In reality, however, the problems do not arise in the core but in the project itself. Typical issues are faulty templates, messy heading structures, missing ARIA attributes or navigation that cannot be operated by keyboard. Content also plays a major role, for example when editors do not maintain alternative texts or break structures.
This is exactly where tools such as Eye-Able, axe DevTools or Siteimprove come in. They help make WCAG violations visible and improve scores by identifying typical problems such as contrast errors, missing labels or structural weaknesses. In Liferay projects in particular, such tools can be integrated well to continuously check whether templates, fragments or content regress.
The important point, however, is that these tools do not solve the problem. They show symptoms, not the cause. If templates are structurally built incorrectly or components were not developed cleanly, even a perfect score will not produce good usability.
The decisive lever therefore lies in the implementation within Liferay. Clean templates, consistent components and clear content rules make the difference. If you have this under control, you can achieve WCAG conformance comparatively efficiently. If you rely only on tools, you optimize numbers, but not the system.
