` 구조는 FED가, 다이나믹 콘텐츠의 ARIA live region은 FED·BED가 담당하는 식이다.웹 접근성 인증 마크 획득 실무 사례: pxd는 2021년 12월 자사 홈페이지에 웹 접근성 인증 마크를 획득했다. 준비 기간은 약 3개월(9월 시작)이었으며, XE 그룹(UX Engineer 그룹)이 프론트엔드 UX로서 할 수 있는 사용자 경험 개선의 일환으로 추진되었다. 접근성 컨설팅 내부 교육을 받은 직후 자사 홈페이지를 직접 적용 대상으로 삼은 것이 핵심이었다.
개선 전 AS-IS 문제점은 세 가지였다. 개발 환경이 일반 HTML과 Vue.js로 혼재해 운영이 불편했고, 포트폴리오 업데이트 시 담당자 부재로 매번 파악 작업이 필요했으며, SEO 미비로 링크 공유 시 페이지 고유 정보가 노출되지 않았다. TO-BE 개선은 개발 환경을 Nuxt.js(SSR 프레임워크)로 전환해 SEO 취약점을 보완하고, 전 페이지 컴포넌트화로 유지 보수 편의성을 높이며, 웹 접근성 작업으로 키보드·스크린 리더 이용자도 동등하게 이용 가능하도록 만드는 것이었다. Lighthouse 성능 지표도 크게 향상되었다.
컨설팅 과정에서 얻은 핵심 인사이트는 두 가지다. 첫째, 시맨틱 마크업의 중요성—작업자 관점에서는 막연히 준수했다고 여겼던 부분들이 검수 항목과 연결해 살펴보면 개선 여지가 드러났다. 둘째, 과잉 친절의 역효과—스크린 리더 사용자에게 중복되거나 불필요한 정보를 계속 읽어주는 사례가 많아, 모든 항목을 기계적으로 추가하는 것이 아니라 정보의 취사선택이 중요하다는 점을 체득했다. 결론적으로, 웹 접근성 준수는 일부 장애인을 위한 부가 작업이 아니라 가장 확실하고 명확하게 실현할 수 있는 UX 개선이라는 인식 전환이 이 프로젝트의 핵심 메시지다.
초기 사례(2010년): 이 블로그에서 확인되는 가장 이른 접근성 관련 글은 기술 표준이 아니라 개인 경험에서 출발한다. 작성자는 복막염 수술 후 며칠간 휠체어를 타면서 '계단으로만 이루어진 구조'가 이동을 원천 차단하는 경험을 했고, 이를 웹 접근성에 빗대어 설명한다. 시각장애인이 화면을 보지 않고 소리로만 웹사이트를 이용하는 국내 스크린 리더 센스리더를 직접 체험해본 뒤, "잘 보이지 않는 이에게 UI 디자인이란 철저히 정보 구조(정보 구조 설계 IA)"라는 결론을 내린다 — 메뉴 순서대로 순차적으로 듣고 전체 구조를 이해해 원하는 페이지까지 건너뛰어 이동하는 방식이기 때문에, 구조가 중첩되거나 복잡할수록, 문구가 모호할수록 '휠체어와 계단'처럼 무용지물이 된다는 것이다. 건너뛰기 링크 등 웹 표준화 원칙을 지키는 것을 '넓은 엘리베이터를 설치하는 일'에 비유하며, 2013년부터 접근성 미준수에 대한 고발이 가능해진다는 점(장애인차별금지법의 단계적 의무화)까지 언급한다. 화면을 만드는 사람이 직접 접근성을 체감하기 어렵다는 한계를 스스로 인정하면서도, 규모가 큰 서비스일수록 공익적으로 이를 챙겨야 한다는 문제의식을 남긴 초기 기록이다.
KWCAG 2.2 신규 항목의 구체적 준수·오류 사례
KWCAG 2.2 개정에서 새로 추가된 9개 항목 중 일부는 실무 적용 사례로 뜯어보면 이해가 쉬워진다.
7.2.2 찾기 쉬운 도움 정보: 최소한 하나의 도움 정보(고객센터 연락처, FAQ 링크 등)를 여러 페이지에서 동일한 상대적 순서로 배치해야 준수로 인정된다. 즉 페이지마다 위치가 들쑥날쑥하면 안 되고, 사용자가 학습한 위치 감각을 유지할 수 있어야 한다.
7.3.3 접근 가능한 인증: 인증 과정이 인지 기능 테스트에만 의존하면 오류다. 예를 들어 특정 버스 노선을 알아야 하거나 무언가를 외워야만 인증이 가능한 방식은 기억력·지식에 의존하는 장벽을 만든다. 준수하려면 인지 기능 테스트에만 의존하지 않아야 하며, 구체적으로는 브라우저의 아이디/비밀번호 자동 저장이 가능하도록 마크업된 서식, 공개 인증을 통한 서드파티 로그인, 생체 인증(얼굴·지문)이나 소지품 기반 인증(휴대폰·USB)을 제공하는 방식이 있다. 다만 이름·이메일·전화번호처럼 인지적 노력이 필요 없는 정보 입력은 예외로 허용된다.
7.3.4 반복 입력 정보: 이미 입력한 정보를 다시 입력하지 않도록 지원해야 한다. 로그인 정보 저장 기능 제공, 배송지 정보를 주문자 정보와 동일하게 자동 입력할 수 있는 옵션 제공이 대표적인 준수 사례다.
이 세 항목은 앞서 게재된 6개 항목(찾기 쉬운 링크 목적, 명료한 목적/입력 방식 등)과 함께 KWCAG 2.2의 인식의 용이성·운용의 용이성 원칙을 실무 체크리스트 수준으로 구체화한 사례로 볼 수 있다. 접근성 마크 획득 경험이 쌓여도 매 개정마다 새 항목을 실제 사례에 대입해 재점검하는 과정이 필요하다.
인증마크 갱신 심사에서 자주 발견되는 실무 오류 유형
오래되고 규모가 큰 사이트라도 매년 접근성 인증마크를 갱신하는 과정에서 반복적으로 발견되는 오류 유형이 있다. 2025년도 갱신 심사를 이끈 경험을 정리하면 다음과 같다.
`role="tab"`의 키보드 탐색 누락: 탭 메뉴에 `role="tab"`을 적용할 때는 클릭 이벤트 구현만으로 끝나지 않는다. 방향키(←/→)로 탭 간 이동, Home/End 키로 처음/끝 탭 이동이 가능해야 하며, `Tab` 키는 탭 메뉴가 아니라 선택된 탭의 콘텐츠 영역으로 초점을 이동시켜야 한다(비선택 탭은 `tabindex="-1"`, 선택 탭만 `tabindex="0"`). WAI-ARIA 구조(`role`, `aria-selected`, `aria-controls`)가 잘 갖춰진 영역에서도 이 방향키 탐색 기능만 누락되는 경우가 실무에서 흔하다.
활성/비활성 상태의 보조 텍스트 누락: 버튼·링크의 활성/비활성 상태를 시각적으로만 표현하고 스크린 리더용 `title` 등 보조 텍스트를 갱신하지 않는 경우가 많다. 상태 변경 시 시각적 스타일뿐 아니라 텍스트도 함께 갱신해야 한다.
`` 내용 불일치: 기존 테이블을 복사해 새 테이블을 만들 때 `
`(테이블 제목)을 수정하지 않아 실제 데이터와 캡션이 어긋나는 오류다. 캡션은 화면에 보이지 않는 경우가 많아 시각적 QA로는 걸러지지 않으므로 별도로 점검해야 한다.논리적 구조와 시각적 구조의 불일치: 자동완성 콘텐츠가 입력창 위에 시각적으로 노출되는 UI에서, 실제 HTML 순서도 자동완성 콘텐츠 → 입력창 순으로 되어 있으면 `Tab` 키만으로는 자동완성 영역에 도달할 수 없고 `Shift+Tab`을 눌러야 하는 역전 현상이 생긴다. 시각적으로 자연스러워 보여도 키보드 사용자를 기준으로는 입력창 다음에 자동완성 콘텐츠가 오도록 HTML 순서를 배치해야 `Tab` 키만으로 접근 가능하다.
URL 파라미터·앵커(#) 예외 처리 누락: SPA나 파라미터 기반으로 화면이 동적으로 구성되는 페이지에서 `#container` 같은 앵커나 예상치 못한 URL 파라미터가 붙었을 때 예외 처리가 없으면 콘텐츠가 아예 사라지거나 화면이 초기화되는 심각한 오류로 이어질 수 있다. 특히 스텝형 페이지를 탐색하는 키보드 사용자에게 치명적이다.
초점 이동 및 회귀 누락: 모달·팝업을 열 때 초점을 콘텐츠로 이동시키고, 닫을 때 원래 초점 위치로 정확히 회귀시키는 처리가 실무에서 가장 많이 누락된다. 실제로 한 인증마크 갱신 심사에서 발견된 오류의 70~80%가 초점 이동 관련 오류였다. 이는 UI 구현(퍼블리싱)과 기능 구현(개발)이 분리된 전통적 협업 방식에서 흔히 발생하며, 초점 이동 로직이 대개 개발 쪽에서 관리되기 때문에 수정 시 개발팀·서드파티 업체와의 커뮤니케이션 비용이 크다는 것이 실무의 어려움이다.
HTML·CSS·JS 계층별 접근성 체크포인트 (Web Tech Concert 2019)
웹 접근성은 세 가지 웹 표준 기술 계층에 걸쳐 실무 체크리스트로 구체화할 수 있다. HTML은 콘텐츠의 구조와 의미를 설계하는 계층으로, `` 선언과 ``을 통한 주 언어 명시, 브라우저가 가장 먼저 만나는 `
` 작성이 기본이며, `header`·`nav`·`main` 같은 시맨틱 태그를 의미에 맞게 사용해야 한다. <strong>CSS</strong>는 레이아웃과 스타일을 담당하되 정보 전달 기능이 섞여 있을 때는 주의가 필요하다. 텍스트를 시각적으로만 숨길 때 `display:none`을 쓰면 스크린 리더가 콘텐츠 자체를 인식하지 못하므로 사용하지 않아야 하고, 대안으로 `position:absolute; top:-9999px` 같은 화면 밖 배치 기법을 쓰더라도 보조 기기로 화면 이동 시 스크롤이 위로 튕기는 부작용이 있어 주의가 필요하다. 색상만으로 정보를 전달할 경우 전경·배경 명도 대비는 최소 4.5 이상을 확보해야 하며, 비율이 동등하게 나란히 배치된 콘텐츠는 사이 간격만으로는 구분이 모호할 수 있어 구분선 등의 시각적 장치가 필요하다. <strong>DOM과 JavaScript</strong>는 콘텐츠의 동적 기능을 구현하는 계층으로, 여기서 발생하는 접근성 문제를 보완하는 표준이 WAI-ARIA다.</p><p><strong>RIA(Rich Internet Applications)</strong>는 정적 HTML과 단순 자바스크립트를 넘어 동적 자바스크립트·Ajax로 높은 수준의 UX를 제공하는 웹 애플리케이션을 말한다. 그러나 RIA는 스크린 리더 같은 보조 기술 사용자에게 취약한 두 가지 문제를 안고 있다. ① `div`, `span`처럼 의미 없는 요소로 구현된 컴포넌트는 스크린 리더가 그 기능을 파악하기 어렵고, ② Ajax 등으로 시간에 따라 자동 업데이트되는 정보는 보조 기기가 변경 사실을 알아채기 어렵다. WAI-ARIA의 <strong>역할(Role)</strong> 속성은 시맨틱 태그를 쓸 수 없는 상황에서 `div` 등에 의미를 부여한다. 예컨대 `role="banner"`는 `<header>`, `role="contentinfo"`는 `<footer>`와 같은 의미를 가지며, `role="main"`은 `<main>` 요소를 대신하되 `<article>`·`<aside>`·`<footer>`의 하위 요소로는 쓸 수 없다는 제약이 있다. <strong>속성(Property)과 상태(State)</strong>는 `aria-` 접두사로 컴포넌트의 특징과 현재 상태를 전달하는데, 실무에서는 시맨틱상 `<button>`이 적절하지만 `<button>` 하위에 `<figure>`를 넣을 수 없어 `<a>` 태그로 대체해야 하는 경우가 있다. 이때 `role="button"`으로 역할을 재정의하고, 클릭 시 팝업이 열린다는 것을 알리는 `aria-haspopup="dialog"`, 버튼의 눌림 상태를 나타내는 `aria-pressed="false"` 같은 속성·상태를 함께 부여해 링크로 오인되지 않도록 보완한다.</p><p><h2>핵심 내용</h2>
<ul><li>WAI-ARIA: W3C가 정의한 동적 웹 환경의 접근성 표준 (role, property, state 속성)</li>
<li>HTML5 시맨틱 태그가 우선, ARIA는 의미 부여가 불가한 경우에만 보완적으로 사용</li>
<li>랜드마크 역할: navigation, main, banner, search, contentinfo 등</li>
<li>라이브 리전(aria-live): 실시간 변경 콘텐츠를 보조 기술에 자동 전달</li>
<li>SPA 환경에서 접근성 보장이 어려워지면서 WAI-ARIA의 중요성 증가</li>
<li>접근성 작업은 시간과 비용이 많이 들어 실무에서 후순위로 밀리는 경향이 있음</li>
<li>웹 접근성 컨설팅 vs 작업자 시각 차이: 검수 항목 기준으로 보면 막연히 준수했다 여긴 부분에서 개선점 도출됨</li>
<li>과잉 친절 주의: 중복·불필요 정보를 스크린 리더로 읽어주는 것도 접근성 문제</li>
<li>웹 접근성 인증 취득 시 개발 환경 정비(Nuxt.js SSR 전환 등)와 병행하면 SEO·유지보수 개선까지 동시에 달성 가능</li>
<li>CSS 숨김 함정: `display:none`은 보조 기기가 콘텐츠로 인식 못 함, `position:absolute; top:-9999px`는 화면 이동 시 스크롤 튐 부작용</li>
<li>RIA(Rich Internet Applications)는 Ajax·동적 JS 기반 웹앱 — 의미 없는 요소로 만든 컴포넌트와 자동 업데이트 정보가 스크린 리더에 취약</li>
<li>ARIA Role 예시: `role="banner"`(header), `role="main"`(main, article/aside/footer 하위 사용 불가), `role="contentinfo"`(footer)</li>
<li>2010년 초기 사례: 휠체어·계단 비유와 국내 스크린 리더 <strong>센스리더</strong> 체험기 — 접근성을 정보 구조(IA) 문제로 규정한 이 블로그의 가장 이른 기록</li>
<li>2025년 인증마크 갱신 심사 실무 오류 유형: `role="tab"` 방향키 탐색 누락, 활성/비활성 보조 텍스트 누락, `<caption>` 내용 불일치, 논리적·시각적 구조 불일치(자동완성 UI), URL 파라미터·앵커 예외 처리 누락, <strong>초점 이동·회귀 누락(오류의 70~80% 차지)</strong></li>
</ul>
<h2>관련 개념</h2>
<ul><li><a href="/concepts/UI-컴포넌트-용어">UI 컴포넌트 용어</a> — UI 컴포넌트의 역할(role)과 상태(state)는 ARIA의 핵심 표현 대상</li>
<li><a href="/concepts/웹-아키텍처">웹 아키텍처</a> — SPA와 Ajax 환경에서 접근성 문제가 심화됨</li>
<li><a href="/concepts/FED-프론트엔드-UX-워크플로우">FED 프론트엔드 UX 워크플로우</a> — 웹 접근성은 프론트엔드 UX 업무의 핵심 실천 영역</li>
<li><a href="/concepts/Docker와-개발-환경-표준화">Docker와 개발 환경 표준화</a> — pxd 홈페이지의 웹 접근성 인증 마크 획득 리뉴얼 작업 과정에서 도입된 개발 환경 통일 수단</li>
<li><a href="/concepts/정보-구조-설계-IA">정보 구조 설계 IA</a> — 스크린 리더 사용자가 메뉴 순서대로 구조를 탐색한다는 점에서 접근성과 정보 구조 설계는 같은 문제의 다른 면</li>
</ul>
<h2>출처</h2>
<ul><li><a href="https://story.pxd.co.kr/239" target="_blank" rel="noopener">[접근성] 휠체어를 타면, 계단은 무용지물이다.</a> — 2010-09-01, 알 수 없는 사용자</li>
<li><a href="https://story.pxd.co.kr/1588" target="_blank" rel="noopener">WAI-ARIA란?</a> — 2021-09-30, seonju.lee</li>
<li><a href="https://story.pxd.co.kr/1835" target="_blank" rel="noopener">A11y Checklist</a> — taeyong.kim, UX Engineer 이야기</li>
<li><a href="https://story.pxd.co.kr/1610" target="_blank" rel="noopener">pxd 홈페이지 웹 접근성 인증 마크 획득기</a> — 2022-01-27, taekie</li>
<li><a href="https://story.pxd.co.kr/1846" target="_blank" rel="noopener">KWCAG 2.2 업데이트 항목의 구체적인 사례 Ch.2</a> — 2025-06-23, hsunj</li>
<li><a href="https://story.pxd.co.kr/1471" target="_blank" rel="noopener">Web Tech Concert 2019 #6 후기</a> — 2019-12-17, 강은영</li>
<li><a href="https://story.pxd.co.kr/1879" target="_blank" rel="noopener">실전 웹 접근성 마크 획득</a> — 2026-02-23, taeyong.kim</li>
</ul> </article> <p class="date" style="margin-top: 2rem;" data-astro-cid-gzwpcbcd>최종 업데이트: 2026-09-07 | 출처 7개</p> </main> </div> <footer> <div class="page-wrapper">
pxd story 블로그의 지식을 구조화한 위키 — Karpathy LLM Wiki 패턴 기반
</div> </footer> </body></html>