WCAG 1.3.2: 의미 있는 순서

WCAG 1.3.2는 콘텐츠의 순서가 그 의미에 영향을 미치는 경우, 보조 기술이 이를 올바르게 제시할 수 있도록 그 순서를 프로그램적으로 판별할 수 있어야 한다고 요구합니다. 이 기준을 충족하지 못하면 화면 읽기 프로그램 사용자와 기타 보조 기술 사용자들은 콘텐츠를 혼란스럽거나 의미 없는 순서로 전달받게 됩니다.

이 규칙의 의미

WCAG 성공 기준 1.3.2 — 의미 있는 순서(레벨 A)는 다음과 같이 규정한다. "콘텐츠가 제시되는 순서가 그 의미에 영향을 미치는 경우, 올바른 읽기 순서를 프로그램적으로 결정할 수 있어야 한다." 쉽게 말해, 페이지 콘텐츠의 시각적 순서가 의미를 담고 있다면 — 절차의 단계, 대화 스레드, 입력 필드와 짝을 이루는 폼 레이블, 번호 매기기 목록 등 — 보조 기술이 이를 올바르게 노출할 수 있도록, 기저의 DOM 순서가 그와 동일한 순서를 반영해야 한다는 뜻이다.

핵심 문구는 "순서가 의미에 영향을 미치는 경우"이다. 페이지의 모든 정렬 결정이 여기에 포함되는 것은 아니다. 예를 들어, 서로 관련 없는 로고를 장식적으로 나열한 목록은 순차적인 의미를 담고 있지 않다. 하지만 순서를 바꾸면 사용자가 이해하는 내용이 달라지는 콘텐츠 — 레시피의 재료 목록과 그 뒤를 잇는 조리 순서, 제품에 대응하는 가격표, 다단계 결제 흐름 등 — 는 반드시 의미 있는 시각적 순서와 일치하는 DOM 순서를 가져야 한다.

통과로 인정되는 경우: DOM 소스 순서가 논리적인 읽기 순서와 일치하거나, (시각적 표현을 재정렬하는 CSS와 같은) 변환이 적용되더라도 보조 기술이 프로그램적으로 올바른 읽기 순서를 여전히 결정할 수 있는 경우이다. CSS의 시각적 위치가 DOM 순서와 다르더라도, DOM을 직접 읽는 스크린 리더는 여전히 의미 있는 올바른 순서로 콘텐츠를 만나야 한다.

실패로 인정되는 경우: CSS 기법 — position: absolute, CSS Grid의 order 속성, CSS Flexbox의 order 속성, CSS 다단(column) 레이아웃 — 을 사용해 콘텐츠를 시각적으로 재배치함으로써, 시각적 순서는 의미를 전달하지만 DOM 순서는 그렇지 못하게 만드는 경우이다. 고전적인 예로, DOM에서는 사이드바가 본문보다 먼저 위치하지만 시각적으로는 본문 뒤에 렌더링되는 경우를 들 수 있다. 이때 사이드바에 담긴 맥락 설명은 본문을 읽은 뒤에야 의미가 있는데, 스크린 리더는 이를 먼저 읽게 된다.

WCAG 명세는 예외를 명시적으로 언급한다. 순서가 의미를 갖지 않는 경우에는 프로그램적으로 결정 가능할 필요가 없다. 또한 이 기준은 시각적 순서와 DOM 순서가 항상 동일해야 한다고 요구하는 것이 아니라, 올바른 읽기 순서를 결정할 수 있어야 한다는 점에 초점을 둔다 — CSS가 시각적으로 재정렬하더라도, 보조 기술에 노출되는 순서가 의미를 유지하면 된다. 그러나 실제로는 CSS만으로 재정렬하는 방식이 보조 기술의 순서를 깨뜨리는 경우가 매우 많으므로, 극도로 주의해서 사용해야 한다.

왜 중요한가

스크린 리더 사용자가 가장 직접적인 영향을 받는 집단이다. 미국에서 약 750만 명이 스크린 리더 소프트웨어를 사용하고 있으며, 전 세계적으로는 세계보건기구(WHO)가 시각 장애가 있는 사람을 22억 명으로 추산한다. NVDA, JAWS, VoiceOver로 페이지를 탐색하는 시각장애 사용자에게 읽기 경험은 전적으로 프로그램적 순서 — 구체적으로 DOM 순서 — 에 의해 결정된다. 개발자가 Flexbox 레이아웃에서 CSS order를 사용해 경고 메시지를 폼 위로 시각적으로 이동시켰지만, DOM에서는 그 경고가 폼 입력 뒤에 위치한다면, 스크린 리더 사용자는 경고를 듣기 전에 폼을 모두 작성하게 된다. 이는 사소한 불편이 아니라, 오류, 거래 실패, 핵심 서비스에서의 배제로 이어질 수 있다.

인지 장애가 있는 사용자도 의미 있는 순서로부터 큰 혜택을 얻는다. 난독증, 주의력 결핍, 정보 처리 차이가 있는 사용자는 논리적이고 예측 가능한 콘텐츠 흐름에 의존하는 경우가 많다. 제목 계층과 콘텐츠 블록이 뒤섞인 DOM 순서로 나타나면, 페이지를 볼 수 있는 사용자라도 브라우저 읽기 모드, 텍스트 음성 변환 도구, CSS를 제거하고 DOM만 보여주는 단순화 확장 기능에 의존할 때 큰 어려움을 겪을 수 있다.

키보드나 스위치 접근으로 탐색하는 운동 장애 사용자 역시 DOM 순서에 따라 Tab 키로 인터랙티브 요소를 이동한다. DOM에서 제출 버튼이 관련 폼 필드보다 먼저(하지만 시각적으로는 뒤에) 위치한다면, Tab 순서는 혼란스럽고 오류를 유발하기 쉽다.

구체적인 실제 사례: 한 터키 전자상거래 결제 페이지가 CSS Grid 레이아웃을 사용하면서, order 속성으로 "주문 요약" 패널을 시각적으로는 청구 폼 오른쪽, 즉 폼 뒤에 보이도록 배치한다. 그러나 DOM에서는 주문 요약 HTML이 먼저 온다. 스크린 리더 사용자는 청구 폼을 듣기 전에 총액과 상품 목록을 먼저 듣게 되며, 자신이 무엇을 위해 결제하는지에 대한 맥락이 없다. 이는 이탈, 혼란, 접근성 민원으로 이어질 수 있다. 터키의 새로운 접근성 규제 하에서, 상업 플랫폼에서 이러한 실패는 규제상 책임이 되는 사안이다.

접근성을 넘어, 의미 있는 DOM 순서는 SEO에도 이점을 준다. 검색 엔진 크롤러는 DOM 순서를 스크린 리더와 유사하게 읽는다. 가장 의미 있는 콘텐츠 — 제목, 주요 콘텐츠, 핵심 행동 유도 요소 — 를 DOM 상에서 먼저 배치한 잘 구조화된 DOM은 페이지가 인덱싱되고 랭킹되는 방식에 긍정적인 영향을 줄 수 있다.

테스트 방법

먼저 자동 스캔 실행: axe DevTools(브라우저 확장)나 Chrome DevTools의 Lighthouse를 사용해 전체 페이지 접근성 스캔을 수행한다. 두 도구 모두 1.3.2 위반을 직접 표시하지는 않지만, 순서 문제를 시사할 수 있는 관련 구조적 이슈 — 레이아웃 테이블, 잘못된 제목 순서, ARIA 오용 — 를 드러낸다. 시각적 순서나 구조적 이상에 대한 경고를 기록해 두고 수동으로 후속 검토한다.
모든 CSS를 비활성화하고 선형화된 콘텐츠 확인: Firefox DevTools나 Chrome DevTools에서 모든 스타일시트를 비활성화하거나, Web Developer 확장의 "Disable All Styles" 기능을 사용한다. 페이지를 위에서 아래로 읽어 내려가며, 이 순서에서 콘텐츠가 여전히 의미가 있는지 자문한다. 이야기, 폼, 프로세스를 혼란 없이 따라갈 수 있는가? 의미가 깨진다면, 해당 페이지는 1.3.2를 위반했을 가능성이 크다.
DOM 소스 순서를 직접 검사: DevTools를 열고 Elements/Inspector 패널로 이동해 HTML 소스를 읽어 내려간다. 각 주요 콘텐츠 블록의 DOM 위치를 시각적 위치와 비교한다. 특히 CSS Flexbox나 Grid를 사용하는 요소에 주의를 기울이고, 계산된 스타일에서 order 속성을 찾아 의미 있는 순서 불일치를 만들지 않는지 확인한다.
NVDA와 Firefox로 테스트: NVDA를 실행하고 Firefox를 열어 페이지로 이동한다. Insert + 아래쪽 화살표를 눌러 "모두 읽기(Say All)" 모드를 활성화하고, 페이지 전체를 위에서 아래로 들으면서 시각적으로 따라간다. 음성으로 읽히는 콘텐츠 순서가 의미 있는 시각적 순서와 일치하지 않는 부분이 있는지 기록한다. 폼 레이블과 입력, 번호 매기기 목록, 단계별 안내, 앞선 콘텐츠를 참조하는 콘텐츠에 특히 주의한다.
VoiceOver와 Safari(macOS/iOS)로 테스트: VoiceOver를 활성화(macOS에서는 Command + F5)한다. 로터(Control + Option + U)를 사용해 제목이나 랜드마크 단위로 이동하고, Control + Option + 오른쪽 화살표로 페이지를 선형적으로 읽는다. 콘텐츠가 논리적이고 의미 있는 순서로 흐르는지 확인한다. iOS에서는 오른쪽으로 스와이프해 콘텐츠를 이동하며 순서의 일관성을 검증한다.
JAWS와 Chrome으로 테스트: JAWS를 Chrome과 함께 실행하고 Insert + 아래쪽 화살표 "모두 읽기(Say All)" 명령을 사용한다. NVDA와 마찬가지로 시각적으로 따라가며, 의미 있는 순서에서 벗어나 제시되는 콘텐츠를 표시한다. JAWS는 DOM 순서를 대부분 반영하는 접근성 트리를 읽기 때문에, 순서 문제를 찾는 데 신뢰할 수 있는 테스트이다.
키보드 Tab 순서 테스트: 스크린 리더 없이, 페이지의 모든 인터랙티브 요소를 대상으로 Tab 키를 반복해서 누른다. 포커스 순서는 논리적이고 의미 있는 경로를 따라야 한다 — 라틴 문자권에서는 일반적으로 왼쪽에서 오른쪽, 위에서 아래 방향으로, 시각 사용자가 페이지를 읽는 방식과 일치해야 한다. 섹션 사이를 예측 불가능하게 건너뛰는 Tab 순서는 DOM 순서 문제를 나타낸다.

해결 방법

CSS Flexbox order 속성 — 잘못된 예

<!-- 시각적 순서: 경고, 그 다음 폼. DOM 순서는 그 반대. -->
<div style='display: flex; flex-direction: column;'>
  <form style='order: 1;'>
    <label for='email'>Email</label>
    <input type='email' id='email' name='email' />
    <button type='submit'>Subscribe</button>
  </form>
  <div class='warning' style='order: 0;'>
    <p>Warning: You must be 18 or older to subscribe.</p>
  </div>
</div>

CSS Flexbox order 속성 — 올바른 예

<!-- DOM 순서가 이제 의미 있는 시각적 순서와 일치: 경고 먼저, 그 다음 폼. -->
<!-- CSS order 속성을 제거하고, DOM 순서만으로 시각적/보조기술 순서를 모두 제어. -->
<div style='display: flex; flex-direction: column;'>
  <div class='warning'>
    <p>Warning: You must be 18 or older to subscribe.</p>
  </div>
  <form>
    <label for='email'>Email</label>
    <input type='email' id='email' name='email' />
    <button type='submit'>Subscribe</button>
  </form>
</div>

절대 위치 지정 콘텐츠가 잘못된 순서를 만드는 경우 — 잘못된 예

<!-- 단계 레이블이 시각적으로는 콘텐츠 박스 위에 보이지만, DOM에서는 그 뒤에 온다. -->
<div style='position: relative; height: 200px;'>
  <div style='position: absolute; top: 50px; left: 0;'>
    <p>Step 1: Fill in your personal details below.</p>
  </div>
  <div style='position: absolute; top: 0; left: 0;'>
    <p><strong>1</strong></p>
  </div>
</div>

절대 위치 지정 콘텐츠가 잘못된 순서를 만드는 경우 — 올바른 예

<!-- DOM 순서가 이제 의미 있는 읽기 순서를 반영: 레이블 먼저, 그 다음 숫자. -->
<!-- 절대 위치 지정은 의미 있는 순서를 뒤집지 않는 시각적 보정에만 사용. -->
<div style='position: relative; height: 200px;'>
  <div style='position: absolute; top: 0; left: 0;'>
    <p><strong>1</strong></p>
  </div>
  <div style='position: absolute; top: 50px; left: 0;'>
    <p>Step 1: Fill in your personal details below.</p>
  </div>
</div>

CSS Grid로 콘텐츠 영역을 재배치한 경우 — 잘못된 예

<!-- 사이드바(맥락 설명)가 시각적으로는 오른쪽, 본문 뒤에 보인다. -->
<!-- 그러나 DOM에서는 먼저 오므로, 스크린 리더는 기사보다 사이드바를 먼저 읽는다. -->
<div class='layout'>
  <aside class='sidebar'>
    <p>Note: The statistics below are sourced from the 2024 annual report.</p>
  </aside>
  <main class='content'>
    <h1>Annual Sales Overview</h1>
    <p>Total revenue grew by 23% compared to the prior year...</p>
  </main>
</div>
<!--
.layout { display: grid; grid-template-columns: 3fr 1fr; }
.sidebar { grid-column: 2; }
.main { grid-column: 1; }
-->

CSS Grid로 콘텐츠 영역을 재배치한 경우 — 올바른 예

<!-- 본문이 DOM에서 먼저 와서 의미 있는 읽기 순서를 이룬다. -->
<!-- 본문을 보완하는 사이드바는 DOM에서 그 뒤를 잇는다. -->
<!-- CSS Grid는 DOM 순서를 바꾸지 않고 사이드바를 시각적으로 오른쪽에 배치한다. -->
<div class='layout'>
  <main class='content'>
    <h1>Annual Sales Overview</h1>
    <p>Total revenue grew by 23% compared to the prior year...</p>
  </main>
  <aside class='sidebar'>
    <p>Note: The statistics above are sourced from the 2024 annual report.</p>
  </aside>
</div>
<!--
.layout { display: grid; grid-template-columns: 3fr 1fr; }
.content { grid-column: 1; }
.sidebar { grid-column: 2; }
-->

자주 발생하는 실수

CSS Flexbox나 Grid의 order 속성을 사용해 의미 있는 콘텐츠 블록을 시각적으로 재배치하면서 HTML 소스 순서를 수정하지 않는 경우 — 이는 현대 웹 개발에서 1.3.2 실패의 가장 흔한 원인이다. 항상 DOM 순서를 먼저 조정하고, CSS는 시각적 표현을 다듬는 용도로만 사용해야 한다.
페이지의 기본 <main> 콘텐츠를 DOM에서 <nav>나 <aside> 뒤에 배치하면서, CSS로 메인 콘텐츠가 시각적으로 먼저 보이게 만드는 경우 — 스크린 리더는 기본 기사보다 내비게이션이나 사이드바를 먼저 읽어 의미 있는 순서를 깨뜨린다.
CSS columns나 float로 다단 매거진 스타일 레이아웃을 구성하는 경우 DOM 순서는 각 열 안에서 위에서 아래로 흐르지만, 시각적 순서는 행 단위인 경우 — 많은 그리드 기반 콘텐츠 레이아웃에서처럼 사용자가 행 단위 읽기를 기대할 때, 잘못된 순서로 콘텐츠를 받게 된다.
position: absolute나 position: fixed를 사용해 폼 오류 요약을 시각적으로 페이지 상단으로 끌어올리면서, 오류 요약 요소는 DOM 하단에 그대로 두는 경우 — 폼을 제출한 스크린 리더 사용자는 페이지 맨 아래에 도달하기 전까지 오류 요약을 만나지 못해, 중요한 피드백을 놓치게 된다.
단계별 안내나 번호 매기기 시퀀스를 CSS counter reset으로 렌더링하면서, DOM 상의 단계 순서가 의미 있는 순서와 일치하지 않는 경우 — 시각적으로는 번호가 올바르게 보이지만, 읽어 주는 순서는 잘못된다.
동적 콘텐츠(예: 채팅 메시지, 실시간 피드 항목, 토스트 알림)를 DOM에서 컨테이너 상단에 삽입하는 경우 시각적 관례는 최신 항목을 하단에 두거나 그 반대인데, ARIA 라이브 리전이나 의미 있는 순서에 맞춘 DOM 조정 없이 이를 수행하는 경우 — 시각적 관례와 프로그램적 순서가 어긋난다.
HTML 테이블을 표 형식 데이터가 아닌 레이아웃 용도로 사용하면서, 셀을 DOM에서 열 우선 순서로 배치하는 경우 — 보조 기술은 테이블 셀을 DOM 순서(행 단위)로 읽기 때문에, 열 우선으로 구성된 레이아웃 테이블은 잘못된 순서로 읽힌다.
JavaScript에 의존해 콘텐츠를 시각적으로 정렬하거나 재배치하면서 (예: 정렬 가능한 상품 목록), 기저 DOM 순서를 업데이트하지 않는 경우 — 사용자가 가격순으로 정렬한 뒤에도, 스크린 리더는 CSS 클래스나 시각적 위치만 바뀌고 DOM 순서는 그대로라면 여전히 원래 정렬 순서대로 항목을 읽게 된다.
각주나 미주를, 시각적 표현에서는 페이지 하단에 모아 두면서도 DOM에서는 해당 문단 바로 뒤에 배치하는 경우 또는 그 반대의 경우 — 의도된 읽기 흐름에 대해 보조 기술에 노출되는 순서가 의미 있게 유지되도록 처리하지 않으면 문제가 된다.
하나의 논리적 콘텐츠 단위를 서로 떨어진 DOM 위치로 분할하는 경우 — 예를 들어, <figure> 요소와 그 <figcaption>을 소스 상에서 멀리 떨어뜨려 배치하면, 스크린 리더가 캡션을 맥락과 동떨어진 위치에서 읽게 된다.

터키 접근성 규제와의 관계

터키의 대통령령 2025/10호는 2025년 6월 21일 관보 제32933호에 게재되었으며, WCAG 2.2와 정렬된 의무적 웹 접근성 요구사항을 수립한다. WCAG 1.3.2 의미 있는 순서는 레벨 A 기준으로, 모든 적용 대상 기관이 충족해야 하는 기본 요구사항 집합에 포함된다.

이 대통령령은 단계적 일정에 따라 준수를 의무화한다. 공공 기관은 공포일로부터 1년 이내에 적합성을 달성해야 하며, 민간 부문은 2년 이내에 준수해야 한다.

다음 유형의 기관은 대통령령에 의해 명시적으로 적용 대상에 포함되며, 따라서 모든 디지털 콘텐츠와 웹 인터페이스에서 정보가 프로그램적으로 결정 가능한 의미 있는 순서로 제시되도록 보장해야 한다.

공공 기관 및 정부 부처 — 중앙 및 지방 정부 기관, 각 부처, 공공 서비스를 제공하는 모든 국가 산하 조직의 웹사이트 및 디지털 서비스.
은행 및 금융 기관 — 온라인 뱅킹 포털, 투자 플랫폼, 보험사 웹사이트 등으로, 계좌 요약, 단계별 대출 신청, 거래 내역과 같은 순차적 콘텐츠가 모든 사용자가 올바른 순서로 읽을 수 있어야 한다.
전자상거래 플랫폼 — 상품 목록, 다단계 결제 흐름, 주문 확인 시퀀스는 의미 있는 시각적 순서를 정확히 반영하는 DOM 순서를 가져야 하며, 이를 통해 시각장애 및 저시력 쇼핑객이 보조 기술로 인한 혼란 없이 구매를 완료할 수 있어야 한다.
병원 및 의료 서비스 제공자 — 환자 포털, 예약 시스템, 의학 정보 페이지 등에서, 안내, 경고, 폼 필드의 순서는 직접적인 안전과 관련된 의미를 갖는다.
20만 명 이상의 가입자를 보유한 통신사 — 요금제 비교 페이지, 계약 관리 인터페이스, 지원 포털 등에서, 요금표와 기능 목록이 의미 있고 프로그램적으로 올바른 순서로 제시되어야 한다.
여행사 및 민간 운송 회사 — 예약 흐름, 일정(이티너러리) 표시, 좌석 선택 인터페이스는 출발이 도착보다 먼저, 1단계가 2단계보다 먼저 등 시각적 순서에 크게 의존하며, 이 순서가 DOM에도 정확히 반영되어야 한다.
국가교육부(MoNE)의 인가를 받은 사립학교 — 학습 관리 시스템, 강의 콘텐츠 페이지, 등록 포털 등에서, 수업, 모듈, 평가와 같은 교육 시퀀스를 프로그램적으로 결정 가능한 순서로 제시해, 보조 기술을 사용하는 학생도 과정을 올바르게 따라갈 수 있어야 한다.

이들 플랫폼에서 WCAG 1.3.2를 준수하지 않는 것은 단순한 모범 사례 미준수에 그치지 않는다. 2025/10 대통령령 하에서는 감독과 시정 조치의 대상이 되는 규제상 비적합에 해당한다. 1.3.2 위반은 터키 웹 개발에서 널리 사용되는 현대 CSS 레이아웃 기법(Flexbox, Grid)에서 자주 발생하는 만큼, 조직은 준수 로드맵의 일환으로 레이아웃 패턴과 DOM 정렬 관행에 대한 체계적인 감사를 우선순위에 두어야 한다.