Sound Familiar? 3 PM. Your phone rings, right on schedule. “I posted an announcement on the website, but the text looks weird. There are question marks everywhere.” The person on the other end insists they “just typed it normally, nothing special.” But if you’ve dealt with Korean systems long enough, you already know where this is going. A few more questions confirm it: they copied and pasted from an HWP document directly into the web editor. It looked fine in the preview. But after saving, this is what appeared on screen: ...

Introduction “How hard can a signup form be?” If that thought has ever crossed your mind… you’ve probably never tested it for accessibility. Forms are the most important interface for user input on the web. Login, checkout, search, surveys — virtually every core web function goes through a form. Yet for countless people, these forms are a complete barrier. Screen reader users can’t tell what an input field is asking for Keyboard-only users get stuck in front of a date picker People with cognitive disabilities see an error message but have no idea how to fix it A web form with multiple input fields — easy to get lost in, just like people navigating a maze. Photo: Susan Q Yin / Unsplash In this post, we’ll go through form accessibility from top to bottom, based on WCAG 2.2. No dry theory — just practical code you can use right away, paired with a demo page I built for this post. ...

I built a dashboard. I was proud of it. Three lines of code using Promise.all to fetch three APIs at once — and the code review feedback was “clean.” Multiple tasks running concurrently - with Promise.all, one failure affects the whole thing Photo: Unsplash javascript Read line numbers: OFF Line-number reading help Reading line numbers aloud This button is for screen reader users. ...

At some point while writing JavaScript, you’ll end up with code like this: javascript Read line numbers: OFF Line-number reading help Reading line numbers aloud This button is for screen reader users. ...

Imagine a webpage with five images. Four of them have no alt text. When a blind user visits this page using a screen reader, those images are announced simply as “image” — or worse, as a raw filename. No meaning. No context. This isn’t a hypothetical. It’s the reality measured by South Korea’s 2025 Web Information Accessibility Survey, published on March 27, 2026. A user sitting in front of a laptop — without alt text, all image information is completely blocked Photo: Ardalan Hamedani / Unsplash What Changed This Year South Korea’s 2025 survey adopted a new standard. The guidelines were updated from KWCAG 2.1 (24 criteria) to KWCAG 2.2 (32 criteria), with 9 new items added. ...

Analyzing accessibility issues on Google Antigravity's homepage — behind the flashy text animations Image: AI-generated Google takes accessibility seriously. Android’s TalkBack, Chrome’s accessibility developer tools, Lighthouse’s accessibility audits… Google-built tools are used by developers worldwide every day. The same goes for Microsoft — Accessibility Insights, Narrator, Windows high-contrast mode. When it comes to accessibility tooling, these two companies are in a league of their own. ...

Introduction “We used red and green to distinguish them, so it should be fine.” It’s a thought that comes up naturally during development. But more people than you’d expect have difficulty telling those two colors apart. Statistics based on Northern European ancestry suggest that roughly 1 in 12 men and 1 in 200 women have red-green color vision deficiency. The exact ratio varies by region and genetic background, but the fact remains: there are always users who struggle to distinguish red from green. ...

Introduction This is the sixth post in the WCAG 3.0 series. This time I want to unpack what “beyond the web” actually means in practice. The earlier posts looked at structure, testing, and Assertions — now it’s time to get clear on “how far does the scope actually reach?” Important: This post is based on the WCAG 3.0 Working Draft (2026-02-20). The Draft is subject to change, and this post may be updated accordingly. ...

This essay records what I have wrestled with on the ground about web accessibility, public web services, and the responsibilities of developers. Between law and technology, standards and reality, I try to answer the question: “Are we truly building for everyone?” Is today’s Seollal(Korean Lunar New Year) really providing equal information to everyone? Produced by: Nano Banana Ahead of the Seollal(Korean Lunar New Year) holiday, I browse the web to find helpful information. Seollal(Korean Lunar New Year) is a uniquely Korean holiday. As I visit site after site, the first thing I often encounter is an auto-rotating banner or card news. Around Seollal, these banners include important government notices like emergency information. ...

Since I started this blog, I have written in several directions. The areas I keep digging into are web accessibility and frontend. I want to write more, and new ideas keep coming, but the speed of writing is not as fast as I hope. Right now I still have eight unfinished drafts. Starting is easy, but wrapping up always feels surprisingly hard. AI has made research and organization much faster, but my time and energy are still limited, so it often feels frustrating. I work during the day, and after work I take care of family responsibilities, side projects, this blog, and certification prep. Honestly, I wish I had ten bodies. ^^;; Still, I want to keep going, so today I am writing a candid note about how I approach blog writing. ...