글로벌 UI·UX 브리핑 — 2026년 8월 31일

접근성 — 숫자가 말하는 격차

수치	내용	조사 규모·시점
94.8%	홈페이지에서 탐지 가능한 WCAG 위반 발견	100만 사이트 모니터링, 2025년
78%	웹·앱 접근성 개선에 AI를 활용하는 조직	Applause 2026 리포트

두 숫자를 나란히 놓으면 그림이 선명해집니다. 도구는 널리 쓰이는데 결과는 개선되지 않았습니다.

원인은 자동 검사의 구조적 한계입니다. 자동 도구는 대비비, alt 누락, 폼 레이블처럼 정적으로 판정 가능한 것만 잡습니다. 반면 맥락·사용성 장벽·실제 보조기술 동작은 놓칩니다.

이 차이가 실무에서 어떻게 나타나는지 예를 들면 이렇습니다.

• 자동 도구가 통과시키는 것 — aria-label이 붙어 있음
• 자동 도구가 못 잡는 것 — 그 aria-label 값이 화면의 실제 상태와 다름

두 번째는 스크린리더 사용자에게 잘못된 정보를 주지만 정적 검사로는 보이지 않습니다. 서버에서 렌더된 고정 문자열이 클라이언트 상태와 어긋나는 경우가 전형적입니다.

또 하나 방향 전환이 있습니다. 접근성이 출시 직전 컴플라이언스 체크에서 설계 초기의 기본 고려사항 으로 옮겨가고 있습니다. 선택적 개선이나 체크박스가 아니라 제품 품질의 일부로 다뤄집니다.

성능 — LCP·INP가 Baseline에 들어왔다

2025년 12월 12일 Safari 26.2 출시로 LCP와 INP가 Baseline Newly available이 됐습니다. 이제 주요 브라우저 전부가 이 둘을 측정하는 API를 지원합니다.

측정 표준화가 왜 중요한지가 실무 포인트입니다. 그동안 Safari에서 INP를 못 재서 실사용자 측정(RUM) 데이터에 Safari 사용자가 통째로 빠지는 문제가 있었습니다. iOS 트래픽 비중이 큰 서비스라면 그동안 본 INP 수치는 모집단이 편향된 값이었습니다. 이제 그 공백이 메워집니다.

임계값 자체는 2026년에도 그대로입니다.

지표	좋음 기준	측정 방식
LCP	2.5초 미만	실사용자 75 백분위
INP	200ms 미만	실사용자 75 백분위
CLS	0.1 미만	실사용자 75 백분위

75 백분위라는 점을 놓치면 안 됩니다. 평균이 아닙니다. 넷 중 셋이 기준을 넘겨야 통과이므로, 평균만 보면 통과처럼 보여도 실제로는 미달인 경우가 흔합니다.

INP는 2024년 3월 FID를 대체하면서 성격이 바뀌었습니다. FID는 첫 입력 하나만 봤지만, INP는 페이지 생애 전체의 클릭·탭·키 입력을 모두 관측하고 그중 최악값을 75 백분위로 보고합니다. 첫 인터랙션만 최적화해서 점수를 만드는 방식이 통하지 않습니다.

리서치 — 전담에서 상시로

Nielsen Norman Group 기준 2025년 UX 디자이너의 70%가 직접 리서치를 수행했습니다.

2026년의 변화는 리서치가 프로젝트 단위 기능에서 상시·전략적 역량으로 옮겨가는 것입니다. 반복 작업은 AI 보조 분석이 가져가고, 기본적인 리서치 방법은 제품·디자인 팀 손으로 내려갑니다.

여기엔 명확한 트레이드오프가 있습니다. 리서치 접근성이 올라가는 대신 방법론 품질 관리가 분산됩니다. 표본 편향이나 유도 질문 같은 문제는 도구가 잡아주지 않습니다.

오늘 바로 적용할 것

1. RUM에서 Safari 세그먼트를 다시 보세요. Safari 26.2 이후 INP 데이터가 들어오기 시작했다면 전체 수치가 실제로 나빠진 게 아니라 그동안 빠져 있던 모집단이 합류한 것일 수 있습니다. 시계열 해석을 틀리기 쉬운 지점입니다.
2. aria-label이 정적 문자열인 곳을 훑으세요. 상태에 따라 바뀌어야 하는데 서버 렌더 고정값으로 남아 있는 경우, 자동 검사는 통과시키고 스크린리더에는 틀린 정보가 갑니다.
3. Core Web Vitals를 평균이 아니라 75 백분위로 보세요. 대시보드 기본값이 평균이면 바꾸세요.