[접근성연구·저시력] 표를 소리로 읽는다는 것
표는 눈으로 보면 강력하다. 가로줄과 세로줄이 만나는 칸에 숫자가 놓이면, 우리는 그 칸이 어느 행과 어느 열에 속하는지를 거의 동시에 파악한다. "2024년 / 신청 건수" 칸에 적힌 숫자가 무엇을 뜻하는지, 우리는 칸 하나만 봐도 위쪽의 열 제목과 왼쪽의 행 제목을 함께 읽어 의미를 완성한다. 이 동시 읽기가 표를 표
![[접근성연구·저시력] 표를 소리로 읽는다는 것](https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/91duzwnc-113598.jpeg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC85MWR1enduYy0xMTM1OTguanBlZyIsInNjb3BlIjoiZG93bmxvYWQiLCJpYXQiOjE3ODQ0NjU3NzIsImV4cCI6MjA5OTgyNTc3Mn0.gW7m82e_x8ES2VYzfJzWB9DDTHRZgpjT3qQhZqUIxdI)
데이터 표 접근성 연구
〈디지털 접근성 연구 040〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.
들어가며
표는 눈으로 보면 강력하다. 가로줄과 세로줄이 만나는 칸에 숫자가 놓이면, 우리는 그 칸이 어느 행과 어느 열에 속하는지를 거의 동시에 파악한다. "2024년 / 신청 건수" 칸에 적힌 숫자가 무엇을 뜻하는지, 우리는 칸 하나만 봐도 위쪽의 열 제목과 왼쪽의 행 제목을 함께 읽어 의미를 완성한다. 이 동시 읽기가 표를 표답게 만든다.
그런데 화면을 눈이 아니라 소리로 읽는 사용자에게 표는 전혀 다른 물건이 된다. 스크린리더는 표를 칸 단위로, 한 번에 하나씩 읽어 준다. 사용자는 숫자 하나를 들으며 "이 숫자가 어느 행, 어느 열의 것인가"를 머릿속으로 다시 맞춰야 한다. 눈으로는 한순간에 이루어지던 가로·세로의 교차가, 소리로는 기억과 추론의 작업이 된다.
이 글은 그 '소리로 읽히는 표'를 하나의 연구 주제로 놓는다. 표가 소리로 어떻게 읽히는지, 표 머리글(header)이 왜 중요한 단서가 되는지, 그리고 공개된 기준들은 표를 어떻게 다루는지를 따라가 본다. 표를 잘 만들라는 지시가 아니라, 표가 소리로 읽힐 때 무슨 일이 일어나는지를 이해하는 데 무게를 둔다.
1. 표는 소리로 어떻게 읽히는가
1-1. 칸 단위의 선형 읽기
스크린리더가 표를 읽는 방식은 본질적으로 선형이다. 화면 위에서는 격자로 펼쳐진 표가, 소리로는 한 줄로 늘어선 칸의 행렬이 된다. 사용자는 키보드로 칸과 칸 사이를 옮겨 다니며 한 칸씩 듣는다. 위로, 아래로, 옆으로 이동할 수 있지만, 듣는 것은 언제나 지금 머문 한 칸이다.
이 선형 읽기에서 가장 어려운 것은 '맥락의 유지'다. 눈으로 보는 사람은 어떤 칸을 봐도 그 칸이 속한 행과 열의 제목이 시야에 함께 들어온다. 그러나 소리로 듣는 사람은 지금 칸의 숫자를 들을 때, 그 칸이 어느 행·열의 것인지를 스스로 기억하거나 다시 확인해야 한다. 표가 클수록 이 기억의 부담은 커진다.
1-2. 머리글이 길잡이가 된다
여기서 표 머리글이 결정적인 역할을 한다. 표의 칸들이 '이 열의 제목은 무엇이고, 이 행의 제목은 무엇이다'라는 정보를 품고 있으면, 스크린리더는 칸을 읽을 때 그 칸이 속한 머리글을 함께 알려 줄 수 있다. 사용자는 "신청 건수 — 2024년 — 1,240"처럼 제목과 값을 한 묶음으로 듣게 되어, 그 숫자가 무엇인지를 칸 하나만으로 이해한다.
반대로 머리글 정보가 없으면, 스크린리더는 그저 숫자만 차례로 읽는다. "1,240. 980. 1,310." 사용자는 이 숫자들이 무엇의 무엇인지 알 수 없다. 머리글은 소리로 읽히는 표에서 길을 잃지 않게 하는 길잡이다.
2. 기준은 표를 어떻게 다루는가
2-1. 구조와 관계를 드러내라는 취지
웹 접근성 기준에서 표는 '정보와 관계'를 다루는 큰 주제의 일부로 등장한다. WCAG에는 화면에 시각적으로 드러나는 정보·구조·관계가 프로그램으로도 파악될 수 있어야 한다는 취지의 항목(1.3.1 Info and Relationships로 알려진 항목)이 있는 것으로 정리된다. 표에서 행과 열, 머리글과 데이터 칸의 관계는 바로 이 '시각적으로 드러나는 관계'에 해당한다. 눈으로 보이는 가로·세로의 교차가 소리로도 전달되려면, 그 관계가 화면 뒤편의 구조에도 담겨 있어야 한다는 관점이다.
다시 말해, 표를 표답게 만든다는 것은 단지 격자처럼 보이게 칸을 그리는 일이 아니라, 어느 칸이 머리글이고 어느 칸이 데이터인지, 어떤 머리글이 어떤 칸을 책임지는지를 구조로 표현하는 일에 가깝다. 보이는 격자와 구조의 격자가 일치할 때, 표는 소리로도 읽힌다.
2-2. 표가 '진짜 표'인지의 문제
화면에서 표처럼 보이는 것이 모두 구조상의 표는 아니다. 칸을 일일이 배치해 격자처럼 보이게 만든 것, 이미지로 표를 그려 넣은 것은 눈으로는 표지만 소리로는 표가 아니다. 스크린리더는 그것을 표로 인식하지 못하므로, 칸과 칸의 관계를 알려 줄 수 없다. 이미지로 된 표라면, 그 안의 숫자는 대체텍스트가 없는 한 아예 읽히지조차 않는다(이 시리즈의 대체텍스트 편 032~034에서 다룬 주제와 이어진다).
그래서 표 접근성의 첫 질문은 종종 "이것이 구조상의 표인가"가 된다. 보이는 격자가 구조의 격자와 어긋나 있으면, 머리글을 아무리 잘 붙여도 소리로 전달되지 않는다.
2-3. 머리글의 범위가 분명한가
표가 구조상의 표라 해도, 어떤 머리글이 어떤 칸을 책임지는지가 분명해야 한다. 단순한 표라면 위쪽 한 줄이 열 제목, 왼쪽 한 줄이 행 제목으로 자연스럽게 정리된다. 그러나 머리글이 두 줄로 겹쳐 있거나, 한 칸이 여러 칸을 묶는 복잡한 표라면, 어떤 머리글이 어떤 데이터를 가리키는지가 모호해질 수 있다. 복잡한 표일수록 머리글과 데이터의 연결을 분명히 드러내는 일이 까다로워진다는 점은, 기준 원문에서도 별도로 다루어지는 영역으로 알려져 있다.
표 접근성의 세 질문을 한자리에 모으면, 머리글 작업이 어디에 놓이는지가 보인다.
| 점검 질문 | 무엇을 보는가 | 관련 관점 |
|---|---|---|
| 구조상의 표인가 | 이미지·배치용 가짜 표가 아닌가 | 보이는 격자=구조 격자 |
| 머리글이 표현됐나 | 머리글 칸이 머리글로 표시되나 | 1.3.1 정보와 관계 |
| 머리글 범위가 분명한가 | 어떤 머리글이 어떤 칸 책임지나 | 복잡한 표 별도 영역 |
(인용) 위 구분은 WCAG 1.3.1(정보와 관계)와 표 접근성 해설을 연구 관점에서 재정리한 것이다. 항목 번호·등급·문구는 판본에 따라 달라질 수 있고, 복잡한 표의 머리글 연결은 단일 항목으로 환원되지 않는 경우가 많다. 실제 적용은 기준 원문 확인이 안전하며, 본 표는 평가 기준이 아니다.
3. 관찰 — 표가 어긋나는 자리
3-1. 보기 위한 표와 읽기 위한 표
공공 웹의 표는 종종 '보기 위한 표'와 '읽기 위한 표' 사이에서 갈린다. 눈으로 한눈에 보기 좋게 디자인된 표가, 소리로 읽힐 때를 함께 고려한 표인지는 별개의 문제다. 보기 좋게 만드는 과정에서 표가 구조상의 표가 아니게 되거나, 머리글이 데이터처럼 처리되거나, 칸의 병합이 복잡해져 관계가 흐려지는 일이 생길 수 있다. 이는 누군가의 부주의라기보다, 표를 다루는 두 시선(보기/읽기)이 한 화면에서 만나기 어렵다는 구조적 어려움에 가깝다.
3-2. 레이아웃을 위한 표
과거에는 화면의 배치를 잡기 위해 표 구조를 빌려 쓰는 방식이 흔했다. 내용상 표가 아닌데도 칸을 나누어 요소를 배치하기 위해 표 구조를 사용한 것이다. 이런 표는 소리로 읽힐 때 '표'로 안내되어, 사용자에게 있지도 않은 행·열 관계를 듣게 만든다. 데이터를 담은 표와 배치를 위한 표가 구분되지 않으면, 사용자는 의미 없는 격자 안에서 헤맨다.
3-3. 너무 큰 표
행과 열이 매우 많은 표는 눈으로 보기에도 부담스럽지만, 소리로 듣기에는 훨씬 더 그렇다. 머리글이 잘 붙어 있어도, 수백 개의 칸을 하나씩 들으며 맥락을 유지하는 일은 큰 인지 부담이다. 큰 표를 어떻게 나누고 요약할지는 단순한 머리글 부착을 넘어서는 설계의 문제로, 정답을 단정하기 어려운 영역이다. 다만 '눈으로 큰 표는 소리로 더 크다'는 점은 표를 설계할 때 기억해 둘 만하다.
표가 어긋나는 세 자리를 늘어놓으면, 눈으로는 멀쩡해도 소리로 막히는 지점이 드러난다.
| 어긋나는 자리 | 눈으로는 | 소리로는 |
|---|---|---|
| 보기용 가짜 표 | 격자로 보임 | 표로 인식 안 됨·관계 안 들림 |
| 배치용 표 | 깔끔한 레이아웃 | 있지도 않은 행·열 관계 안내 |
| 너무 큰 표 | 한눈에 훑음 | 칸마다 맥락 유지 부담 폭증 |
(관찰) 위 어긋남은 공공 웹의 표에서 되풀이되어 관찰되는 패턴을 정리한 것으로, 특정 사이트를 가리키지 않는다. 이는 누군가의 부주의라기보다 '보기'와 '읽기' 두 시선이 한 화면에서 만나기 어렵다는 구조적 어려움에 가깝다고 우리는 본다. 빈도는 측정값이 아니라 경험 기반 정리다.
4. 만드는 사람의 시선에서
4-1. 한 번 소리로 들어 본다
표를 점검하는 가장 직접적인 방법은 그것을 소리로 들어 보는 것이다. 스크린리더로 표의 칸들을 옮겨 다니며 들어 보면, 어떤 칸에서 머리글이 함께 안내되고 어떤 칸에서 숫자만 덩그러니 읽히는지가 드러난다. 만드는 사람이 직접 들어 보면, 눈으로는 멀쩡하던 표가 소리로는 길을 잃게 만든다는 사실을 체감하게 된다.
4-2. 표인지부터 확인한다
머리글을 손보기 전에, 그 표가 구조상의 표인지부터 확인하는 편이 순서에 맞는다. 이미지로 된 표, 칸을 배치만 한 가짜 표라면 머리글 작업 자체가 의미를 갖기 어렵다. 구조상의 표임을 확인한 뒤에, 머리글이 머리글로 표현되어 있는지, 어떤 머리글이 어떤 칸을 가리키는지가 분명한지를 차례로 살핀다.
4-3. 기준은 관계를 보라고 말한다
WCAG의 관련 항목이 표를 직접 거명하기보다 '정보와 관계'라는 넓은 언어로 말하는 것은 의미가 있다. 표든 목록이든 양식이든, 화면에 보이는 관계가 소리로도 전달되어야 한다는 것. 표는 그 관계가 가장 촘촘한 사례일 뿐이다. 항목의 정확한 번호·등급은 기준 원문에서 확인하되, '눈으로 보이는 가로·세로의 의미가 소리로도 전해지는가'라는 질문은 표를 다룰 때마다 되짚어 볼 만하다.
만드는 사람의 점검을 순서로 두면, 머리글 작업을 어디서 시작할지가 분명해진다.
| 순서 | 하는 일 | 빠뜨리면 |
|---|---|---|
| ① 소리로 들어 보기 | 스크린리더로 칸 옮겨 가며 청취 | 눈으로 멀쩡해 문제 못 봄 |
| ② 표인지 확인 | 구조상의 표/가짜 표 구분 | 머리글 작업이 헛일 됨 |
| ③ 머리글 표현·범위 | 머리글이 머리글로, 범위 분명 | 숫자만 덩그러니 읽힘 |
(관점) 위 순서는 "머리글을 손보기 전에 표인지부터 본다"는 관점의 정리다. 모든 표가 같은 순서로 풀리는 것은 아니며, 큰 표의 요약·분할은 이 순서를 넘어서는 설계 문제다. 우리는 점검을 '눈으로 보이는 관계가 소리로도 전해지는가'를 되짚는 일로 본다.
5. 반론·한계와 ViewCheck 관점
5-1. 반론과 한계
이 글의 표 접근성 정리에도 반론과 한계가 있다. 덮기보다 함께 적어 둔다.
| 가능한 반론 | 우리의 한계 인정 | 보완하는 태도 |
|---|---|---|
| "머리글만 잘 붙이면 끝 아닌가" | 큰 표·복잡한 병합표는 머리글만으로 풀리지 않는다 | 표 분할·요약을 설계 문제로 함께 본다 |
| "자동 도구가 표 구조를 잡아 주지 않나" | 도구는 '표인가·머리글 있나'는 잡아도 '소리로 자연스러운가'는 단정 어렵다 | 직접 소리로 들어 확인한다 |
| "보기 좋은 표면 충분하지 않나" | 보기용과 읽기용 시선이 어긋날 수 있다 | 두 시선을 한 표에서 맞춰 본다 |
5-2. ViewCheck 관점 — 사람과 도구의 분담
표 점검에서 자동 점검과 사람의 눈·귀는 보는 자리가 다르다. 도구는 표 구조와 머리글 마크업을 빠르게 훑지만, '소리로 들었을 때 맥락이 이어지는지'는 사람이 직접 들어 봐야 안다.
| 점검 항목 | 자동 점검이 보는 것 | 사람이 봐야 하는 것 |
|---|---|---|
| 구조상의 표 | <table>·셀 마크업 존재 |
이미지·배치용 가짜 표 아닌지 |
| 머리글 표현 | 머리글 셀 표시 여부 | 칸 읽을 때 제목이 함께 들리는지 |
| 머리글 범위 | 머리글-데이터 연결 속성 | 복잡한 병합표에서 헷갈리지 않는지 |
| 표 크기 | 행·열 수 | 소리로 끝까지 따라갈 만한지 |
자동 점검은 '표가 구조와 머리글을 갖췄는가'를 빠짐없이 훑고, 사람은 '그 표가 소리로 맥락이 이어지는가'를 귀로 확인한다. 두 시선이 만나는 자리에서 표 점검이 완성된다고 우리는 본다.
한 장 요약
| 구분 | 핵심 내용 |
|---|---|
| 표를 소리로 읽으면 | 격자가 칸 단위 선형 읽기가 되어 맥락 유지가 어려워짐 |
| 머리글의 역할 | 칸을 읽을 때 행·열 제목을 함께 안내해 의미를 완성 |
| 관련 기준 | 시각적 정보·관계가 프로그램으로도 파악돼야 한다는 취지(1.3.1로 알려짐) |
| 흔한 어긋남 | 이미지·배치용 가짜 표, 머리글 미표현, 지나치게 복잡·큰 표 |
| 점검 순서 | ①구조상의 표인가 → ②머리글이 표현됐는가 → ③머리글 범위가 분명한가 |
| 점검 방법 | 스크린리더로 칸을 옮겨 다니며 직접 소리로 들어 보기 |
맺으며
표는 눈으로 보면 한순간에 읽히지만, 소리로 들으면 칸 하나하나를 기억으로 이어 붙이는 일이 된다. 그 이음을 도와주는 것이 머리글이다. 머리글이 칸과 연결되어 있으면 숫자는 의미가 되고, 끊겨 있으면 숫자는 그저 숫자로 흘러간다. 보이는 격자와 구조의 격자가 일치할 때, 표는 소리로도 표가 된다.
이 글은 표가 소리로 읽히는 과정과 머리글의 역할을 기준의 배경과 함께 따라가 보았다. 다음 편에서는 시선을 자신의 표로 돌린다. 머리글 없는 표가 만드는 혼란을 관찰하며, 우리 화면의 표를 어떻게 점검해 볼 수 있는지를 살핀다.
다음 편 예고 (041): 〈머리글 없는 표의 혼란 / 표 점검 관점〉 — 머리글이 빠진 표가 소리로 어떻게 읽히는지를 따라가며, 우리 화면의 데이터 표를 어떻게 스스로 점검해 볼 수 있는지를 정리한다.
참고한 공개 자료(출처):
- WCAG(Web Content Accessibility Guidelines) — 정보와 관계(1.3.1로 알려진 항목) 및 데이터 표 머리글 관련 해설
- W3C WAI(Web Accessibility Initiative) — 표(table) 접근성 작성 해설 자료
- KWCAG(한국형 웹 콘텐츠 접근성 지침) — 콘텐츠의 논리적 구조 관련 항목
- 행정안전부 등 공공기관 웹 접근성 안내 자료
※ 위 자료의 항목 번호·등급·세부 문구는 판본에 따라 달라질 수 있으므로, 실제 적용 시에는 각 기준의 원문을 직접 확인하는 것이 안전합니다. 이 글은 특정 기준의 공식 해석이 아니라 하나의 연구 관점입니다.
관련 글
[접근성연구·디지털포용] 한 사람이 여러 벽을 동시에
앞 편(081)에서 디지털 포용이 여러 갈래의 사용자를 하나의 목표로 묶는다고 봤다. 그리고 끝에서 한 가지를 남겼다 — 현실의 한 사람은 여러 조건을 동시에 가질 수 있다고. 이 시리즈를 닫는 이번 편은 그 '겹침'을 정면으로 본다. 영역의 경계를 가로질러, 조건이 겹칠 때 접근성이 어떻게 더 가팔라지는지를 관찰한다.
[접근성연구·디지털포용] 디지털포용법이 말하는 '포용'
앞 편(080)에서 초고령사회라는 인구구조의 신호를 봤다. 그리고 끝에서 한 가지를 분명히 했다 — 디지털 격차는 고령에만 있는 것이 아니라고. 이번 편은 그 여러 갈래의 격차를 '디지털 포용(digital inclusion)'이라는 하나의 정책 틀에서 함께 본다. 이 시리즈는 그동안 사용자를 영역별로 나눠 다뤘다. 고령
[접근성연구·디지털포용] 초고령사회, 공공웹은 준비됐나
공공앱 세 편(077~079)으로 매체의 확장을 닫았다. 이제 시선을 한 번 더 넓힌다. 지금까지 이 시리즈는 주로 '한 사람이 화면 앞에서 겪는 어려움'을 다뤘다. 고령(001~014), 저시력(029~043), 키보드(047~049)처럼, 개별 사용자의 자리에서 벽을 봤다. 이번 묶음(080~082)은 그 시선을 거시