At Liberogic, we are continually working to improve web accessibility. We have now published a series of articles on Zenn, a technical knowledge-sharing platform, covering the WCAG (Web Content Accessibility Guidelines), the web accessibility guidelines.
In this post, we share the background behind writing these articles, along with the thinking behind them, and provide an overview of each article.
Clearing up the "why" behind WCAG
In our daily work implementing and checking websites, we have repeatedly faced points that puzzle us, such as "How should this WCAG criterion actually be interpreted?" and "Can we say this implementation conforms?"
This effort is partly part of the output needed to maintain and renew my international accessibility credential, the IAAP WAS (Web Accessibility Specialist). More importantly, I wanted to organize the points that everyone in practice struggles with and share them as field knowledge, so I also used this as a chance to sort out my own thinking.
Meeting WCAG is a "starting point," not the "goal"
The main message I wanted to convey through these articles is that meeting every WCAG criterion does not automatically make a site 100% accessible.
WCAG is the "minimum baseline" needed for people with diverse needs to use content, and it is merely a starting point for accessibility.
If we mechanically fill in checklists with the sole goal of "meeting the success criteria," the perspective of whether something is truly easy for users to use can easily get lost.
That is why we went beyond surface-level know-how like "implement it this way to comply" and explored the background and intent behind why each criterion exists. We believe that understanding the intent behind the criteria leads to a deeper understanding of accessibility.
Published Articles on Zenn
We have organized the points that are most likely to cause confusion in practical implementation and auditing into five articles, each focused on a specific theme. Feel free to start with whichever topic interests you.
WCAG Pitfalls #1: Is it okay to specify font sizes in px?
We examine how px-based font sizes align with WCAG in modern browser environments, and explore the essence of "more accessible implementation" that respects users' text size settings. Read the article on Zenn
WCAG Pitfalls #2: Does having multiple "View details" links violate 2.4.4 (Link Purpose)?
We explain the boundary within which criteria are met when there is "sufficient context." We also propose a step further, UX-focused implementation to improve efficiency for screen reader users. Read the article on Zenn
WCAG Pitfalls #3: If an image link lacks alternative text, which criteria does it violate?
This article focuses on untangling complex situations where a single issue spans multiple success criteria (such as 1.1.1, 2.4.4, and 4.1.2). It explains the relationships between multiple criteria and how to make judgments, topics that often cause confusion during practical audits. Read the article on Zenn
WCAG Pitfall #4: The same look, but select is NG while custom dropdowns are OK? Judging criterion 3.2.2 (On Input)
An in-depth look at the difference between "changing settings" and "activating" as defined by W3C. Summarizes how to make the right judgment based on element semantics and operation classification, rather than being misled by visual behavior. Read the article on Zenn
WCAG Pitfall #5: Where did 4.1.1 go? Which criterion should handle HTML syntax errors?
Looks at the background behind the removal of 4.1.1 in WCAG 2.2, and explains how syntax errors previously covered by it should be reassigned to other criteria (1.3.1 or 4.1.2) based on real-world impact, including site quality considerations. Read the article on Zenn
Note: The WCAG guidelines contain many complex and hard-to-follow phrasings. As a result, the explanations and judgment criteria in each article may include our own interpretations based on practical experience. We recommend referring to them alongside the official WCAG guidelines.
Closing Thoughts
Web accessibility is not something you address once and then forget; it is something you continue to nurture over time.
We hope this content offers useful hints to the engineers, designers, and directors who work daily on implementing and testing accessibility in the field.
At Liberogic, we will continue to share our technical insights and hands-on practice, working toward the goal of creating websites and services that everyone can use with ease. If you have any questions about accessibility or thoughts on our articles, please feel free to contact us!
Starting out in DTP and moving into the web, he now handles markup, frontend, direction, and accessibility alike. A "master of all trades" who has been versatile since Liberogic's early days and is now a walking encyclopedia of the company. Lately he has been hooked on exploring efficiency through prompts, asking, "Can't we rely more on AI for accessibility work?" Both his skills and his thinking are still evolving.
Ayumu Futamata
IAAP Certified Web Accessibility Specialist (WAS) / Markup Engineer / Frontend Engineer / Web Director