글로벌 UI·UX 브리핑 — 2026년 9월 14일

접근성 — WebAIM Million 2026, “개선 추세”가 처음으로 꺾였다

WebAIM Million은 2026년 2월 기준 상위 100만 개 홈페이지를 자동 검사해 8회째 발행한 연례 보고서입니다. 결과는 좋지 않았습니다 — 총 5,611만 4,377개의 서로 다른 접근성 오류가 검출돼 페이지당 평균 56.1개로, 2025년(51개)보다 10.1% 늘었습니다. WCAG 2 실패가 검출된 홈페이지 비율도 94.8%에서 95.9%로 올라, 그동안 조금씩이나마 개선되던 흐름이 처음으로 반전됐습니다.

원인으로 지목된 것은 페이지 복잡도입니다. 홈페이지당 평균 DOM 요소 수가 1년 새 22.5% 늘어 1,437개에 달했고, ARIA 속성도 페이지당 평균 133개로 27% 증가했습니다. 보고서는 “ARIA 속성이 많을수록 검출되는 접근성 오류도 더 많아지는 경향이 뚜렷했다”고 밝혀, 잘못 쓰인 ARIA가 스크린리더 사용자에게 오히려 해가 될 수 있다는 기존 지적을 다시 확인했습니다. 오류 유형은 여전히 여섯 가지가 전체의 96%를 차지합니다 — 낮은 명도대비 텍스트(83.9%), 이미지 대체 텍스트 누락(53.1%), 폼 입력 라벨 누락(51%), 빈 링크(46.3%), 빈 버튼(30.6%), 문서 언어 속성 누락(13.5%) 순입니다. 서드파티 프레임워크·라이브러리 의존과 AI 보조 코딩 확산이 복잡도 증가의 배경으로 꼽힌 만큼, 컴포넌트를 추가할 때마다 명도대비·대체 텍스트·폼 라벨 같은 기본기부터 자동 검사에 포함시키는 것이 여전히 가장 비용 대비 효과가 큰 대응입니다.

성능 — Core Web Vitals, INP만 계속 나빠지는데 이유를 모른다

Chrome UX Report 릴리스 노트에 따르면 2026년 9월 8일 공개된 8월 데이터 기준으로 전체 오리진(도메인) 중 Core Web Vitals 세 지표를 모두 통과한 비율이 55.6%로 전월 대비 0.2%p 하락했습니다. LCP 양호 비율은 68.1%(-0.2%p), CLS는 81.5%(변동 거의 없음)로 대체로 안정적인 반면, INP(Interaction to Next Paint) 양호 비율만 85.3%로 0.5%p 떨어져 유독 나쁜 흐름을 보였습니다. 4월(56.4%)부터 5개월 연속 완만한 하락세인데, Chrome 팀 스스로도 “INP의 지속적인 퇴보는 우려스럽지만 명확한 원인을 찾지 못했다”고 릴리스 노트에 적었습니다.

원인이 불특정하다는 점은 역설적으로 실무 팀에게 시사하는 바가 큽니다. 프레임워크·라이브러리 버전업이나 특정 캠페인성 스크립트 삽입처럼 팀 내부에서 최근 바뀐 것들부터 되짚어야 한다는 뜻이기 때문입니다. 클릭·탭 이후 다음 페인트까지 걸리는 시간이 200ms(양호 기준)를 넘기는 상호작용이 있다면, 이벤트 핸들러 안에서 실행되는 긴 자바스크립트 작업을 쪼개거나 메인 스레드를 막는 서드파티 스크립트부터 점검하는 것이 현재로선 가장 실질적인 대응입니다.

기술 표준 — WCAG 3.0, A/AA/AAA를 버리고 단일 레벨 + 리포팅 티어로

W3C WAI가 2026년 9월 10일 WCAG 3.0의 최신 Working Draft를 공개하고 합치성 모델(conformance model)에 대한 커뮤니티 검토 의견을 요청했습니다. WCAG 3 Introduction에 따르면 가장 큰 변화는 지금까지 익숙했던 A/AA/AAA 3단계 합치 레벨을 버리고, 단일 합치 레벨을 기준점으로 삼고 그 위아래를 태그 기반 리포팅 티어로 세분화해 보고하는 구조로 바뀐다는 점입니다. 웹사이트·웹페이지에 한정됐던 WCAG 2.x와 달리 앱·도구·퍼블리싱·신생 웹 기술까지 아우르는 더 넓은 범위를 목표로 하고 있습니다.

다만 시점은 아직 멉니다. W3C는 “WCAG 3.0이 향후 수년 내에 완성된 W3C 표준이 될 것으로 예상되지 않는다”고 못박고 있어, 지금 당장 조직의 준수 목표를 WCAG 3.0 기준으로 바꿀 필요는 없습니다. 다만 합치성 모델 자체가 근본적으로 바뀌는 초기 단계이니만큼, 대규모 조직이라면 GitHub 이슈나 wai@w3.org 메일링 리스트를 통해 지금 의견을 내는 것이 이후 실무 부담을 줄이는 방법입니다. 현재 준수 게이트는 계속 WCAG 2.1/2.2 AA를 기준으로 유지하는 것이 안전합니다.

UX 리서치 — AI 프로토타입으로 “완성돼 보이기 전”에 복잡한 인터랙션을 테스트한다

Nielsen Norman Group이 2026년 9월 11일 공개한 글은 필터, 대시보드, 대화형 AI처럼 “가능한 상태가 많은” 복잡한 인터페이스를 개발 완료 전에 실제와 가까운 상호작용 프로토타입으로 테스트하는 방법론을 제시합니다. 절차는 다섯 단계입니다 — ① 프로토타입이 지원할 상호작용 수준 결정, ② 레이아웃·계층 구조·엣지 케이스를 포함한 설계 결정 확정, ③ 개인정보를 제외한 실데이터 또는 합성 데이터 준비, ④ 설계 요구사항과 데이터를 담은 상세 프롬프트 작성, ⑤ Cursor·v0 같은 도구에 입력 후 반복 수정.

사례도 구체적입니다. Ramp는 비용 정책 편집 도구를 수동으로 프로토타이핑하기엔 너무 복잡했지만, 3주 만에 작동하는 프로토타입을 만들어 테스트한 끝에 “편집 추적 표시가 혼란을 준다”는, 정적 목업으로는 발견하지 못했을 문제를 잡아냈습니다. Purdue 대학 사례에서도 정적 와이어프레임을 본 사용자들은 “너무 예비적”이라며 막연한 피드백만 준 반면, AI로 만든 대화형 프로토타입을 본 사용자들은 구체적인 문제를 짚어냈습니다. 다만 NN/G는 한계도 분명히 합니다 — 완성도가 높아 보일수록 사용자가 “이미 출시 준비가 끝난 제품”으로 오인할 위험이 있고, AI가 채워 넣은 세부사항에는 잘못된 디자인 패턴이나 혼란스러운 계층 구조가 섞여 있을 수 있어 설계자의 상세한 판단은 여전히 필수적입니다.

“AI 프로토타입은 설계자의 판단을 대신하지 않는다 — 다만 그 판단을 사용자 앞에 훨씬 더 일찍 세울 수 있게 해줄 뿐이다.” — Nielsen Norman Group, 2026-09-11 요지

오늘 바로 적용할 것

1. 폼 라벨·대체 텍스트·명도대비 자동 검사를 CI 게이트에 넣으세요. WebAIM Million 2026이 보여주듯 오류의 96%가 여섯 가지 기본 유형에 몰려 있는데도 전체적으로 악화되고 있습니다 — 새 컴포넌트가 들어갈 때마다 이 여섯 항목만이라도 자동으로 걸러내면 규모 대비 효과가 가장 큽니다.
2. 최근 INP가 나빠졌다면 최근 배포·의존성 변경 이력부터 되짚으세요. Chrome조차 업계 전반의 원인을 특정하지 못했으니, 원인을 기다리기보다 자사 사이트의 최근 변경 로그와 필드 데이터를 직접 대조하는 편이 빠릅니다.
3. 필터·대시보드처럼 상태가 많은 복잡한 화면을 다음 분기에 만든다면, 개발 착수 전 AI 프로토타입으로 사용자 테스트를 한 번 끼워 넣으세요. 정적 와이어프레임보다 구체적인 피드백을 얻을 수 있지만, 완성도가 높아 보인다는 이유만으로 설계 검토를 건너뛰지 않도록 주의하세요.