디지털 지갑을 쓰지 못하는 사람의 인증 경로
디지털 지갑과 웹이 연결돼도 이용자가 인증을 마칠 수 있는지는 별개다. 동의·취소·복구 과정을 살피고, 대체 경로의 접근성과 필요한 신원 확인·개인정보 보호를 함께 검토하는 표를 제안한다. 실제 구현을 시험한 결과는 아니다.
태그
웹개발
24개 글
400% 확대에서 남는 화면을 실측했더니, 뷰포트 높이와 무관한 고정 px 통행료가 나왔다
320px 리플로우 판정을 통과한 페이지에서도 짧은 뷰포트에서는 본문에 남는 세로 공간이 118px까지 줄었다. 손실은 비율이 아니라 82px짜리 고정 픽셀 통행료였고, 대부분 우리 CSS 밖의 제3자 고정 컨테이너에서 나왔다. 측정 방법과 배포 회귀 게이트 설계까지 정리했다.
CSS로는 Escape를 받을 수 없다: 툴팁 일곱 개로 잰 SC 1.4.13
툴팁에 :focus-visible만 붙이면 접근성은 끝난 줄 알았다. 구현 일곱 개를 만들어 Dismissible·Hoverable·Persistent 세 항목을 각각 재보니 CSS만으로 통과한 것은 하나도 없었고, popover="hint"조차 절반만 대신해 주었다.
Chrome의 에이전트 스킬을 세어봤다: 가이드 138개, 접근성 2개, 검색 0개
Google Chrome 팀의 Modern Web Guidance 0.0.180을 설치해 가이드 138개를 세고, 22개 질의로 검색을 찔러봤다. 상위 유사도는 UI 0.643, 접근성 0.508, 구조화 데이터 0.267. 빈자리를 프로젝트 규칙으로 메우는 방법까지 정리했다.
320px로 재면 리플로우는 절반만 잰 것이다: 400% 확대의 높이 200px
WCAG 1.4.10 리플로우를 320x844, 320x256, 320x200 세 조건으로 같이 재봤다. 가로 판정은 세 조건이 한 픽셀도 다르지 않았고, 400% 확대에서 실제로 달라지는 것은 높이였다. 82px짜리 sticky 헤더가 뷰포트의 41%를 먹고 있었다.
인용된 문장으로 되돌아오는 링크: 코드 블록에서만 15개 중 14개가 끊겼다
AI 답변이 내 글의 한 문장을 인용하고 그 문장으로 가는 링크를 걸었을 때, 그 링크가 실제로 동작하는지 크로미움에서 69개 확인했다. 산문 48개는 전부 도착했고 코드 블록 15개 중 14개가 끊겼다. 텍스트 프래그먼트의 블록 경계·단어 경계 규칙을 실측으로 정리한다.
자간을 0.12em 넓혔더니 570곳이 잘렸다: 검사기가 통과시킨 AA 기준
axe-core는 WCAG 1.4.12 텍스트 간격 기준에 위반 0건을 줬다. 그런데 그 기준이 요구하는 네 줄을 실제로 적용하자 570개 요소에서 글자가 잘렸다. 네 줄을 하나씩 따로 걸어 -webkit-line-clamp가 어디서 콘텐츠를 잃게 하는지를 분해해봤다.
W3C 정답지 1,213장에 검사기를 걸었다: 자동 접근성 게이트가 결정하는 것
W3C ACT가 공개한 정답 붙은 테스트 케이스 1,213장에 axe-core를 전수로 돌렸다. 실패해야 하는 예제 387장 중 해당 성공기준으로 위반이 잡힌 것은 145장(37.5%)이었고, 36개 기준 중 22개는 0건이었다. 침묵의 일부는 규칙이 그냥 꺼져 있어서였다.
Tab으로 0건, Shift+Tab으로 16건: 스티키 헤더가 삼킨 키보드 포커스
같은 6개 페이지를 Tab으로 내려가며 재면 WCAG 2.4.11 위반이 0건, Shift+Tab으로 올라가며 재면 16건이었다. 브라우저가 포커스 대상을 화면에 넣는 정렬이 진행 방향에 따라 달라지기 때문이다. CSS 한 줄로 16건을 0건으로 줄인 바로 그 실측이다.
1년 전 글의 Last-Modified가 어제였다: 배포가 지우는 캐시 검증자
작년에 쓴 글을 curl로 찔러보니 Last-Modified가 어제 배포 시각이었다. ETag는 파일 수정 시각과 크기를 16진수로 이어붙인 값이다. 같은 소스로 다시 빌드한 HTML 1,346장이 100% 바이트 동일한데도, 배포 한 번이 사이트 전체의 조건부 요청을 무효로 만든다.
표본 26장이 놓친 위반 3종: WCAG-EM 2.0을 1,342장에 적용한 기록
W3C가 7월 23일 WCAG-EM 2.0을 Group Note로 발행했다. 문서의 표본 추출 절차대로 26장을 뽑고, 같은 빌드의 1,342장 전체를 axe-core로 훑어 대조했다. 표본은 위반 4종 중 1종만 잡았고, 무작위 표본의 새 발견 확률은 0.29%였다.
제목을 선언하는 일곱 곳 중 여섯 곳만 내가 썼다: 앵커 텍스트 18,296개 실측
한 페이지의 제목은 title·h1·og:title·headline·RSS 등 여섯 곳에서 선언된다. 1,296편 전부 일치했다. 문제는 일곱 번째 채널이었다. 내부 링크 18,296개 중 목표 글 제목과 일치하는 앵커 텍스트는 0.7%뿐이었고, 원인은 카드를 감싼 링크 하나였다.
내부 링크 46,382개 중 24,948개가 301로 튕기고 있었다
접근성 지표를 재려고 만든 스크립트가 URL 버그를 잡아냈다. 빌드된 HTML 1,334장의 내부 링크를 전수 조사하니 절반이 넘는 24,948개가 트레일링 슬래시 없는 주소, 즉 301 리다이렉트를 거치는 주소를 가리키고 있었다. 원인과 네 단계의 수정, 그리고 0으로 만든 기록.
언어별 아카이브 네 장을 지웠더니 296편이 도달 불가가 됐다: 크롤 깊이 실측
관련 글이 평균 8개씩 걸린 사이트의 내부 링크를 도달성 기준으로 다시 세어 봤다. 빌드된 HTML 1,330장을 너비 우선 탐색하니 글 1,288편 중 1,276편이 깊이 2였다. 그런데 언어별 목록 페이지 네 장을 링크 그래프에서 빼자 296편이 홈에서 닿지 않았다.
div 그리드로 만든 표가 조용히 잃는 것: 접근성 트리와 텍스트 추출 동시 실측
같은 영업시간 표를 네 가지 마크업으로 만들어 axe-core와 추출기 다섯 벌에 통과시켰다. axe는 네 개 모두 위반 0건을 줬지만, HTML을 텍스트로 바꾸는 순간 7행이 통째로 사라지는 마크업이 셋이었다. role="table"이 못 구하는 층을 실측 로그로 정리했다.
JSON-LD vs Microdata vs RDFa — 구조화 데이터 문법, 무엇을 언제 쓸까 (실측 비교)
같은 Product 엔티티를 세 문법으로 각각 짜서 파서에 넣고 바이트 수와 취약성을 실측했다. Google은 셋 다 동등하게 취급한다. 그렇다면 JSON-LD를 권하는 진짜 이유는 순위가 아니라 재설계에서 살아남는 결합도였다. 공식 문서와 재현 로그로 정리한 실전 선택 기준.
sitemap.xml에서 구글이 실제로 읽는 건 lastmod 하나다
priority 1.0에 changefreq always를 붙여도 구글은 다 버린다. 공식 문서가 쓰는 필드는 lastmod 하나뿐이고, 그마저 검증 가능하게 정확할 때만 쓴다. 세 종류의 sitemap을 공식 XSD로 직접 돌려 무엇이 통과하고 무엇이 조용히 무시되는지 실측했다.
axe-core를 CI에 넣으면 color-contrast만 조용히 사라지는 이유
AI가 만든 예약 위젯을 jsdom과 실제 브라우저에서 axe-core로 돌려봤다. 구조적 위반 4개는 브라우저 없이 잡혔지만 color-contrast만 jsdom에서 incomplete로 빠졌다. CI를 2단으로 짜야 커버리지 구멍이 안 생기는지 실측 로그와 함께 정리했다.
기술 SEO 감사를 닷새간 돌려봤다 — 고친 다섯 항목보다 중요했던 건 게이트였다
4개 언어 블로그를 닷새간 실측 감사했다. relatedPosts 404 12개, hreflang 파손 4쌍, 렌더 블로킹 405KB, 번역 드리프트 21건, JSON-LD 조각 7개를 다 고쳤다. 진짜 성과는 이 수정들이 다시 되돌아오지 못하게 막은 빌드 게이트였다.
JSON-LD를 @graph 하나로 묶기 — 흩어진 구조화 데이터를 검색·AI가 읽는 엔티티 모델로
내 페이지의 JSON-LD를 검증기에 넣었더니 세 조각으로 흩어져 있었다. @id 참조로 Organization·WebSite·Article을 하나의 @graph로 잇고 jsonld로 연결성을 실측했다. 3개 컴포넌트가 1개로 합쳐지는 과정과 Google이 보장하지 않는 지점까지.
hreflang은 양방향이어야 한다 — 내 4개 언어 블로그를 직접 감사해 찾은 홈페이지 버그
30줄짜리 검사기를 내 사이트의 빌드 결과물에 직접 돌렸다. 블로그 글 248개의 hreflang 클러스터는 전부 통과했는데 홈페이지 하나가 걸렸다. Google 공식 리시프로시티 규칙, 실측 로그, 세 가지 구현 방법 비교, 그리고 개발자가 바로 적용할 수정 코드까지 정리했다.
AI 크롤러를 robots.txt로 제대로 제어하기 — 학습은 막고 인용은 허용하는 2026 전략
GPTBot 한 줄 막고 "AI 차단 끝"이라 믿는 사이트가 많다. 학습·검색·사용자요청 크롤러를 분리 제어하는 robots.txt를 직접 만들고 표준 파서로 검증했다. Google-Extended가 AI Overviews를 못 막는 함정과 llms.txt의 정직한 현황까지.
접근성 점수 55에서 100까지 — Lighthouse로 WCAG 위반 직접 잡아 고치기
가상의 베이커리 랜딩 페이지를 Lighthouse 접근성 감사에 돌려 55점을 받았다. 색상 대비부터 폼 레이블과 ARIA 속성까지 6개 WCAG 위반을 하나씩 직접 고쳐 100점으로 만든 실측 로그와, 자동 감사 도구가 놓친 키보드 내비게이션 함정까지 단계별로 정리했다.
LocalBusiness 구조화 데이터, JS로 넣어도 되지만 서버사이드가 더 확실한 이유
매장 검색 페이지의 LocalBusiness JSON-LD를 JavaScript로 주입하면 원시 HTML엔 구조화 데이터 블록이 0개로 잡힌다. 서버사이드 렌더링 출력과 직접 비교하고, Google 공식 견해와 리치 결과·검색 순위에 미치는 한계까지 실측으로 정리했다.