디지털 지갑을 쓰지 못하는 사람의 인증 경로
디지털 지갑과 웹이 연결돼도 이용자가 인증을 마칠 수 있는지는 별개다. 동의·취소·복구 과정을 살피고, 대체 경로의 접근성과 필요한 신원 확인·개인정보 보호를 함께 검토하는 표를 제안한다. 실제 구현을 시험한 결과는 아니다.
태그
12개 글
디지털 지갑과 웹이 연결돼도 이용자가 인증을 마칠 수 있는지는 별개다. 동의·취소·복구 과정을 살피고, 대체 경로의 접근성과 필요한 신원 확인·개인정보 보호를 함께 검토하는 표를 제안한다. 실제 구현을 시험한 결과는 아니다.
WCAG 리플로우의 가로 기준(320픽셀에서 가로 스크롤 없음)을 통과해도 세로 읽기는 보장되지 않는다. 화면 높이와 무관하게 고정 요소가 항상 82픽셀의 세로 공간을 가져가므로, 400% 확대 화면에서는 통과 판정 옆에 세로 측정을 따로 해야 한다.
320px 리플로우 판정을 통과한 페이지에서도 짧은 뷰포트에서는 본문에 남는 세로 공간이 118px까지 줄었다. 손실은 비율이 아니라 82px짜리 고정 픽셀 통행료였고, 대부분 우리 CSS 밖의 제3자 고정 컨테이너에서 나왔다. 측정 방법과 배포 회귀 게이트 설계까지 정리했다.
툴팁에 :focus-visible만 붙이면 접근성은 끝난 줄 알았다. 구현 일곱 개를 만들어 Dismissible·Hoverable·Persistent 세 항목을 각각 재보니 CSS만으로 통과한 것은 하나도 없었고, popover="hint"조차 절반만 대신해 주었다.
Google Chrome 팀의 Modern Web Guidance 0.0.180을 설치해 가이드 138개를 세고, 22개 질의로 검색을 찔러봤다. 상위 유사도는 UI 0.643, 접근성 0.508, 구조화 데이터 0.267. 빈자리를 프로젝트 규칙으로 메우는 방법까지 정리했다.
WCAG 1.4.10 리플로우를 320x844, 320x256, 320x200 세 조건으로 같이 재봤다. 가로 판정은 세 조건이 한 픽셀도 다르지 않았고, 400% 확대에서 실제로 달라지는 것은 높이였다. 82px짜리 sticky 헤더가 뷰포트의 41%를 먹고 있었다.
axe-core는 WCAG 1.4.12 텍스트 간격 기준에 위반 0건을 줬다. 그런데 그 기준이 요구하는 네 줄을 실제로 적용하자 570개 요소에서 글자가 잘렸다. 네 줄을 하나씩 따로 걸어 -webkit-line-clamp가 어디서 콘텐츠를 잃게 하는지를 분해해봤다.
W3C ACT가 공개한 정답 붙은 테스트 케이스 1,213장에 axe-core를 전수로 돌렸다. 실패해야 하는 예제 387장 중 해당 성공기준으로 위반이 잡힌 것은 145장(37.5%)이었고, 36개 기준 중 22개는 0건이었다. 침묵의 일부는 규칙이 그냥 꺼져 있어서였다.
같은 6개 페이지를 Tab으로 내려가며 재면 WCAG 2.4.11 위반이 0건, Shift+Tab으로 올라가며 재면 16건이었다. 브라우저가 포커스 대상을 화면에 넣는 정렬이 진행 방향에 따라 달라지기 때문이다. CSS 한 줄로 16건을 0건으로 줄인 바로 그 실측이다.
W3C가 7월 23일 WCAG-EM 2.0을 Group Note로 발행했다. 문서의 표본 추출 절차대로 26장을 뽑고, 같은 빌드의 1,342장 전체를 axe-core로 훑어 대조했다. 표본은 위반 4종 중 1종만 잡았고, 무작위 표본의 새 발견 확률은 0.29%였다.
한 페이지의 제목은 title·h1·og:title·headline·RSS 등 여섯 곳에서 선언된다. 1,296편 전부 일치했다. 문제는 일곱 번째 채널이었다. 내부 링크 18,296개 중 목표 글 제목과 일치하는 앵커 텍스트는 0.7%뿐이었고, 원인은 카드를 감싼 링크 하나였다.
로딩 중 레이아웃이 밀리는 건 취향 문제가 아니라 측정 가능한 지표다. 같은 페이지를 두 가지로 만들어 layout-shift PerformanceObserver로 CLS를 재고, 이미지 크기 예약과 슬롯 확보만으로 0.559(POOR)를 0.014(GOOD)까지 내린 기록이다.