At Liberogic, we are constantly working to improve web accessibility, and we have now published a series of articles on WCAG (Web Content Accessibility Guidelines), a web accessibility guideline, on the technical information sharing service "Zenn".
This time, I will introduce an overview of each article, along with the background and thoughts behind why I wrote them.
We want to resolve the "why?" behind WCAG.
In my daily work of implementing and checking websites, I've encountered numerous points that have left me scratching my head, such as, "How should I actually interpret this WCAG standard?" and "Can I say that this implementation conforms?"
This time, it's partly an output for maintaining and renewing my own international accessibility certification, "IAAP WAS (Web Accessibility Specialist)," but more than that, I decided to put it together with the desire to "organize the points that everyone gets confused about in practice and share them as practical knowledge," while also organizing my own thoughts.
Achieving WCAG is not the "goal," but the "starting point."
The main point I wanted to convey through these articles is that "just because something meets all of WCAG's standards doesn't mean it's 100% accessible."
WCAG is merely a "minimum requirement" to ensure that diverse users can access content, and it is only the starting point for accessibility.
If you mechanically fill out a checklist and focus solely on "meeting the achievement criteria," you might overlook the perspective of whether it's truly user-friendly.
That's why we didn't just offer superficial know-how like "this is how you implement it to meet the standards," but instead delved into the background and intentions behind the creation of those standards. We believe that understanding the intentions behind the standards will deepen your understanding of accessibility in a more fundamental way.
List of published articles on Zenn
This article, divided into five sections, addresses common points of confusion during implementation and testing in practical applications. Please feel free to browse the sections that interest you.
WCAG point of confusion #1: Is it okay to specify font size in pixels?
This article examines the suitability of px specifications in modern browser environments and explores the essence of a "more accessible implementation" that respects the user's font size settings.Read Zenn's article
WCAG point of confusion #2: Does having multiple "View Details" links violate section 2.4.4 (Purpose of Links)?
This document explains the boundary lines of criteria that determine compliance when there is "appropriate context." Furthermore, it proposes the implementation of a more advanced UX perspective to improve the operational efficiency of screen reader users.Read Zenn's article
WCAG Confusing Point #3: If an image link does not have alt text, which criterion does it fall under?
This document focuses on organizing complex situations where a single problem intertwines with 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, which can often be confusing in practical inspections.Read Zenn's article
WCAG Confusing Point ④: Why is a select field NG while a custom dropdown is OK, even though they look the same? 3.2.2 (During Input)
This article provides a deep explanation of the difference between "changing settings" and "activating" as defined by the W3C. It summarizes how to correctly judge these concepts based on element semantics and operation classifications, but a being misled by their apparent behavior.Read Zenn's article
WCAG point of confusion #5: Where did 4.1.1 go? What criteria should be used to handle HTML syntax errors?
This article explores the reasons behind the deprecation of 4.1.1 in WCAG 2.2 and explains how to reclassify existing syntax errors to alternative criteria (1.3.1 or 4.1.2) based on actual impact, including from a site quality perspective.Read Zenn's article
*The WCAG guidelines are very complex and contain many difficult-to-understand expressions. Therefore, the explanations and criteria in each article may include our own interpretations based on our past practical experience. We would appreciate it if you would refer to them in conjunction with the WCAG guidelines.
In conclusion
Web accessibility isn't something you address once and then forget about; it's something that needs to be continuously nurtured.
We hope that this output will be helpful to engineers, designers, and directors who deal with accessibility implementation and testing on a daily basis.
At Liberogic, we will continue to share our technologies and put them into practice to realize "websites and services that are easy for everyone to use." If you have any questions about accessibility or comments on our articles, please feel free to contact us!
He jumped from DTP to the web world and quickly became a "master of craftsmanship" with a mastery of markup, front-end design, direction, and accessibility. He's been active in a variety of fields since Liberogic's founding and is now a living dictionary within the company. Recently, he's been obsessed with exploring efficiency improvements using prompts, wondering, "Can we rely more on AI for accessibility?" His technology and thinking are still evolving.
Futa
IAAP Certified Web Accessibility Specialist (WAS) / Markup Engineer / Front-end Engineer / Web Director