[접근성연구·저시력] 우리 문서 구조는 읽히는가

헤딩·랜드마크 점검 관점

〈디지털 접근성 연구 037〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

앞의 두 편에서 제목 계층과 시맨틱 마크업이 듣는 사용자의 '지도'가 된다는 것(035), 그 지도가 사라지면 사용자가 길을 잃는다는 것(036)을 살펴봤다. 이제 실용적인 질문이 남는다. 우리 문서의 구조는 제대로 읽히는가? 이 질문에 "그럴 것이다"가 아니라 "확인해 보니 이렇다"로 답하는 방법을 정리하는 것이 이번 편이다.

이번 편은 'C 점검' 관점이다. 구조 점검은 대체텍스트 점검보다 한 차원 넓다. 한 요소를 보는 것이 아니라, 페이지 전체의 '줄거리'를 봐야 하기 때문이다. 그래서 점검 동선도 '윤곽을 뽑아 보고', '들어 보고', '이동해 보는' 여러 시선을 함께 쓴다. 누구나 따라 할 수 있는 구조 점검 동선을, 그 함정과 함께 정리한다.

1. 점검 전에 — 무엇을 보는가

구조 점검의 대상은 크게 세 가지다. 이 셋을 미리 나눠 두면 점검이 흩어지지 않는다.

1-1. 제목 윤곽(heading outline)

페이지의 제목만 뽑아 목차처럼 늘어놓은 것이다. 1수준부터 차례로 내려가는지, 빠진 수준이나 건너뛴 수준은 없는지, 윤곽만 읽고도 페이지의 줄거리가 잡히는지를 본다. 제목이 화면에서 크게 보이는지가 아니라, 코드에서 제목으로 인식되는지가 기준이다.

1-2. 랜드마크(구역)

머리말·주 탐색·본문·보조·꼬리말 같은 큰 구역이 의미로 표시되어 있는지를 본다. 특히 '본문(main)' 구역이 있어야 사용자가 머리말을 건너뛰고 본문으로 바로 갈 수 있다. 구역으로 이동했을 때 의도한 자리에 닿는지를 확인한다.

1-3. 콘텐츠 요소의 의미

목록은 목록으로, 표는 표로, 폼은 폼으로 표시되어 있는지를 본다. 화면에서 목록처럼 보이는 것이 코드에서도 목록인지, 표가 칸 구조를 갖췄는지를 확인한다. 스크린리더가 "목록 N개 항목"처럼 구조를 알리는지가 신호다.

세 대상을 한눈에 정리하면 다음과 같다. 무엇을 보는지를 미리 나눠 두면, 점검이 "그냥 훑어보기"로 흐려지지 않는다.

점검 대상	무엇을 보는가	정상 신호	막힘 신호
제목 윤곽	1수준부터 단계적으로 내려가는 목차	윤곽만 읽어도 줄거리가 잡힘	수준 누락·뒤죽박죽·제목 미인식
랜드마크(구역)	머리말·주 탐색·본문·꼬리말 의미 표시	'본문' 구역으로 바로 이동 가능	본문 구역 없음·구역 과다
콘텐츠 요소 의미	목록·표·폼이 의미대로 표시	"목록 N개 항목" 안내됨	보기만 목록, 코드는 단락

(인용) 위 점검 대상 구분은 W3C WAI의 페이지 구조 점검 안내(제목·랜드마크·콘텐츠 의미)를 연구 관점에서 재정리한 것이다. 구체 항목·표현은 도구와 지침 버전에 따라 다를 수 있어 원문 확인이 안전하다. 본 표는 평가 기준이 아니라 점검 시선을 나누기 위한 정리다.

2. 점검 동선 — 뽑아 보고, 들어 보고, 이동해 본다

구조 점검은 도구로 윤곽을 뽑아 보는 시각 점검과, 스크린리더로 들어 보는 청취 점검을 함께 가는 것이 좋다.

2-1. 1단계 — 제목 윤곽을 뽑는다

브라우저 확장이나 접근성 점검 도구로 페이지의 제목 윤곽을 뽑는다. 많은 도구가 제목만 목차처럼 보여 준다. 이 윤곽을 읽으며 본다:

• 1수준 제목이 페이지의 주제를 담고 있는가(보통 하나)
• 수준이 단계적으로 내려가는가(1→2→3, 갑작스러운 점프 없음)
• 화면에서 제목처럼 보이는데 윤곽에 안 잡힌 것은 없는가
• 윤곽만 읽고도 페이지의 줄거리가 잡히는가

윤곽이 뒤죽박죽이거나 제목이 누락되어 있으면, 화면에서 안 보여도 듣는 사용자의 지도가 엉킨 것이다.

2-2. 2단계 — 랜드마크 목록을 본다

같은 도구로 페이지의 랜드마크(구역) 목록을 본다. 본문 구역이 있는지, 주 탐색이 표시되어 있는지, 구역이 과하게 많거나 적지는 않은지를 확인한다. 랜드마크가 전혀 없으면, 사용자는 구역 단위 이동을 할 수 없다.

2-3. 3단계 — 스크린리더로 이동해 본다

가장 중요한 단계다. 스크린리더를 켜고 '제목으로 이동'과 '구역으로 이동'을 직접 해 본다.

• 제목 점프: 멈춰야 할 제목에 멈추는가, 제목 아닌 것에 멈추지는 않는가
• 구역 점프: 본문으로 바로 갈 수 있는가
• 목록·표: "목록 N개", "표 N행 N열"처럼 구조를 알리는가

도구가 보여 주는 '구조'와 스크린리더가 '읽는' 구조가 일치하는지를 귀로 확인한다.

2-4. 4단계 — 키보드만으로 따라가 본다

마우스를 떼고 키보드(주로 Tab)만으로 페이지를 따라가 본다. 초점이 화면의 시각 순서와 같은 순서로 움직이는지, 건너뛰기 링크('본문 바로가기')가 있는지를 본다. 구조와 초점 순서는 맞물려 있어, 함께 보면 막힘이 더 분명히 드러난다(초점은 038·039편에서 더 다룬다).

네 단계를 도구·감각·확인 항목으로 늘어놓으면, 어느 단계를 빠뜨렸는지가 보인다. '뽑아 보기'와 '들어 보기'를 함께 가는 것이 이 동선의 핵심이다.

단계	쓰는 도구	확인하는 것	빠뜨리면
1. 윤곽 뽑기	점검 도구·확장	제목 목차의 단계·누락	화면만 보고 구조 단정
2. 랜드마크 보기	같은 도구	본문 구역·구역 과부족	구역 이동 가능 여부 모름
3. 청취	스크린리더	제목·구역 점프 실제 동작	도구 윤곽=귀로 읽힘 착각
4. 키보드 따라가기	Tab 키	초점 순서·건너뛰기 링크	구조-초점 어긋남 못 봄

(관점) 위 4단계는 "도구로 뽑아 보고, 귀로 들어 보고, 손으로 이동해 본다"는 시선의 정리다. 단계 순서나 도구 이름은 환경에 따라 달라질 수 있으며, 핵심은 한 가지 감각에만 의존하지 않는 것이다. 우리는 윤곽(시각)과 청취(청각)가 어긋날 수 있다는 전제에서 동선을 짠다.

3. 점검에서 빠지기 쉬운 함정

구조 점검은 도구에 기댈수록, 그리고 한 페이지만 볼수록 함정에 빠지기 쉽다.

3-1. 화면 모양을 구조로 착각하는 함정

가장 근본적인 함정이다. 화면에서 잘 정돈되어 보이면 '구조가 있다'고 여기는 것이다. 그러나 035·036편에서 거듭 본 대로, 보이는 구조와 코드 구조는 별개다. 윤곽을 뽑아 보거나 들어 보지 않고 화면만 보면, 이 함정을 벗어날 수 없다.

3-2. 윤곽만 보고 청취를 생략하는 함정

도구로 윤곽이 깔끔하게 나와도, 스크린리더가 실제로 그렇게 읽는다는 보장은 없다. 도구마다 해석이 다를 수 있고, 특정 구현은 도구에는 잡혀도 스크린리더에는 다르게 읽힐 수 있다. 도구의 윤곽은 '단서'이고, 청취가 '확인'이다.

3-3. 한 페이지로 일반화하는 함정

구조 결핍은 템플릿에서 반복된다(036편). 한 페이지의 윤곽이 깔끔해도, 다른 템플릿의 페이지는 다를 수 있다. 반대로 한 페이지가 어그러졌다면 같은 템플릿의 다른 페이지도 의심해야 한다. 점검은 대표 템플릿 여럿을 표본으로 보는 것이 좋다.

3-4. 수준 점프를 무조건 오류로 보는 함정

수준이 단계적인 것이 권장되지만, 모든 점프가 곧 막힘은 아니다. 맥락에 따라 한 수준을 건너뛰는 것이 자연스러운 경우도 있다. 기계적으로 '수준 점프 = 오류'로 적기보다, 그 점프가 사용자의 지도를 실제로 헝클어뜨리는지를 함께 보는 것이 정확하다.

네 함정을 늘어놓고 보면, 공통점이 드러난다 — 도구나 한 페이지에 과하게 기댈수록 빠지기 쉽다는 것이다.

함정	어떻게 빠지는가	벗어나는 시선
화면 모양=구조 착각	정돈돼 보이면 구조 있다고 여김	윤곽 뽑아 보고 들어 보기
윤곽만 보고 청취 생략	도구 목차 깔끔하면 통과로 판단	윤곽은 단서, 청취가 확인
한 페이지로 일반화	한 페이지 깔끔하면 전체 통과	대표 템플릿 여럿 표본
수준 점프=무조건 오류	기계적으로 점프를 오류 처리	지도가 실제로 엉키는지 확인

(관찰) 위 함정은 구조 점검 현장에서 되풀이되어 관찰되는 패턴을 정리한 것으로, 특정 사이트의 사례가 아니다. 빈도나 심각도는 측정된 수치가 아니라 점검 경험에 기반한 정리이며, 우리는 이를 단정이 아니라 '점검할 때 의식해야 할 시선'으로 제시한다.

4. 점검 결과를 어떻게 적을 것인가

구조 점검의 결과는 '제목이 몇 개 있다'는 숫자로 끝내면 절반만 적은 것이다. 윤곽과 청취 결과를 함께 담아야 한다.

• 어디서: 어느 페이지(또는 어느 템플릿)인가
• 무엇이: 제목 윤곽 / 랜드마크 / 목록·표 중 무엇인가
• 어떤 상태: 누락 / 수준 어긋남 / 의미 없는 텍스트 / (정상) 중 무엇인가
• 들은 결과: 스크린리더가 제목·구역 이동에서 어떻게 동작했는가
• 반복 여부: 같은 템플릿의 다른 페이지에서도 나타나는가

특히 '들은 결과'와 '반복 여부'를 적어 두면, 개별 페이지가 아니라 구조의 뿌리를 다시 찾을 수 있다. 우리는 구조 점검의 목적이 '제목 개수'를 채우는 데 있다고 보지 않는다. 듣는 사용자가 페이지를 항해할 지도가 있는지를 확인하고, 그 지도가 엉킨 자리를 다시 찾을 수 있게 남기는 것 — 그것이 점검이 하는 일이다.

5. 점검을 '템플릿'으로 옮기기

구조는 페이지 단위가 아니라 템플릿 단위로 결정되는 경우가 많다. 머리말 구역, 본문 구역, 제목 수준의 틀은 보통 공통 템플릿에 들어 있다. 그래서 구조 점검을 개별 페이지마다 반복하기보다, 템플릿의 구조를 한 번 바로잡는 관점이 효율적이다.

템플릿에 본문 구역과 건너뛰기 링크를 갖춰 두면, 그 템플릿을 쓰는 모든 페이지가 본문 바로가기를 얻는다. 제목 수준의 틀(어디까지가 1수준, 어디부터가 2수준)을 템플릿에 정해 두면, 콘텐츠 담당자가 매번 수준을 고민하지 않아도 일관된 윤곽이 나온다. 035·036편에서 '구조는 전체의 문제'라고 한 것과 같은 맥락이다 — 뿌리를 고치면 가지가 함께 바로 선다.

콘텐츠 단위에서는, 작성 도구에 제목·목록·표를 의미대로 입력할 수 있는 흐름을 두는 것이 도움이 된다. 글자 크기를 키워 제목처럼 '보이게' 하는 대신, '제목'으로 지정하면 코드 의미가 함께 따라온다. 보이게 만드는 것과 의미를 부여하는 것을 한 동작으로 묶는 것이다.

페이지마다 고치는 일과 템플릿에서 한 번 정하는 일을 나눠 보면, 점검 결과를 어디로 옮길지가 분명해진다.

구조 요소	페이지마다 고치면	템플릿에서 정해 두면
본문 구역·건너뛰기 링크	매번 누락 위험, 일관성 흔들림	그 템플릿의 모든 페이지가 함께 얻음
제목 수준의 틀	작성자마다 수준 제각각	일관된 윤곽이 자동으로 나옴
랜드마크 구역 표시	페이지별로 빠뜨리기 쉬움	머리말·본문·꼬리말 의미 고정

(관점) 위 구분은 "구조는 페이지가 아니라 템플릿 단위로 결정되는 경우가 많다"는 관점의 정리다. 모든 사이트가 템플릿 기반은 아니며, 콘텐츠 자체의 구조(제목·목록)는 여전히 작성 단계에서 결정된다. 우리는 '뿌리(템플릿)'와 '가지(콘텐츠)'를 함께 봐야 한다고 본다.

5-1. 반론과 한계

이 글의 점검 관점에도 반론이 가능하다. 우리는 그 반론을 덮기보다 함께 적어 둔다.

가능한 반론	우리의 한계 인정	보완하는 태도
"도구가 윤곽을 뽑아 주면 청취는 생략해도 되지 않나"	도구 윤곽과 스크린리더 읽기가 어긋나는 경우를 모두 잡지는 못한다	윤곽은 단서로, 핵심 동선은 청취로 확인한다
"수준 점프를 일일이 보는 건 과하지 않나"	모든 점프의 적정성을 기계적으로 판정할 수는 없다	점프가 지도를 실제로 엉키게 하는지로 좁혀 본다
"한 페이지만 봐도 충분하지 않나"	표본 한 페이지가 전체를 대표한다는 보장은 없다	대표 템플릿 여럿을 표본으로 넓힌다

5-2. ViewCheck 관점 — 사람과 도구의 분담

구조 점검에서 자동 점검과 사람의 눈은 보는 자리가 다르다. 도구는 윤곽과 구역을 빠르게 뽑지만, '그 구조가 듣는 사용자의 지도로 옮겨졌는지'는 사람이 들어 봐야 안다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
제목 윤곽	제목 태그 존재·수준 단계	윤곽만 읽고 줄거리가 잡히는지
랜드마크	본문·구역 의미 표시 유무	본문으로 실제 바로 가지는지
콘텐츠 의미	목록·표·폼 마크업 여부	"목록 N개"가 귀에 자연스러운지
수준 점프	점프 발생 지점 표시	그 점프가 지도를 엉키게 하는지

자동 점검은 '구조가 코드에 있는가'를 빠짐없이 훑고, 사람은 '그 구조가 항해할 지도가 되는가'를 듣는다. 두 시선이 만나는 자리에서 구조 점검이 비로소 완성된다고 우리는 본다.

한 장 요약

점검 단계	하는 일	함정
제목 윤곽	목차처럼 뽑아 줄거리 확인	화면 모양을 구조로 착각
랜드마크	본문 등 구역 표시 확인	—
스크린리더 청취	제목·구역 이동 직접 확인	윤곽만 보고 청취 생략
키보드 따라가기	초점 순서·건너뛰기 링크	한 페이지로 일반화

맺으며

"우리 문서 구조는 읽히는가"라는 질문에, 우리는 화면의 정돈된 모양이 아니라 '코드가 전하는 구조'로 답하려 했다. 구조 점검의 가장 정직한 방법은 윤곽을 뽑아 보고, 스크린리더로 직접 이동해 보는 것이다. 화면은 잘 정돈되어 보여도, 그 정돈이 듣는 사용자의 지도로 옮겨졌는지는 들어 봐야 안다.

구조는 한 자리의 문제가 아니라 페이지 전체, 나아가 템플릿 전체의 문제다. 그래서 점검도 개별 요소를 넘어 줄거리를 보고, 해결도 페이지를 넘어 템플릿을 본다. 보이는 정돈을 믿지 않고 듣는 구조를 확인하는 습관이, 길 잃지 않는 화면을 만든다. 다음 편부터는 구조에서 한 걸음 더 들어가, 키보드로 화면을 다루는 사용자에게 '지금 어디에 있는지'를 알려 주는 초점(focus) 표시를 살펴본다.

다음 편 예고 (038): 038편은 'A 기준연구' 관점입니다. 마우스 없이 키보드만으로 화면을 다루는 사용자는, '지금 어디에 초점이 있는지'를 봐야 다음 동작을 합니다. 초점 표시가 무엇이고 왜 보여야 하는지를 기준 연구의 시선으로 정리합니다.

---

참고한 공개 자료(출처):

• W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — 1.3.1 Info and Relationships, 2.4.1 Bypass Blocks, 2.4.6 Headings and Labels (원문 확인 권장)
• W3C, WAI — Page Structure / Headings·Landmarks 점검 안내 (원문 확인 권장)
• 한국웹접근성 관련 지침(KWCAG) — 콘텐츠 구조·제목 제공 관련 항목 (원문 확인 권장)
• 행정안전부, 「전자정부 웹사이트 품질관리 지침」 — 접근성 영역 (고시 원문 확인 권장)

※ 위 자료의 구체 조항·수치는 인용 시점과 버전에 따라 달라질 수 있어, 실제 적용 전 원문 확인이 안전합니다. 본 글은 연구·관점 정리이며 특정 기관의 평가가 아닙니다.