앞 편에서 나는 접근성이 왜 중요한지를 이야기했다. 그렇다면 접근성을 챙기는 첫걸음은 무엇일까. 놀랍게도 그것은 특별한 기술이 아니라, 우리가 이미 배운 시맨틱 마크업이다. 의미에 맞는 요소를 제대로 골라 쓰는 것만으로 접근성의 절반은 이미 이루어진다. 이번 편은 시맨틱이 어떻게 곧 접근성이 되는지를 다룬다.
나는 한때 화면에 보이는 모양만 맞으면 어떤 요소를 쓰든 상관없다고 생각했다. 겉모습이 같으니 문제될 게 없어 보였다. 그러나 화면 낭독기로 내 페이지를 들어보고 나서 생각이 완전히 바뀌었다. 겉은 같아도 의미가 없는 요소로 만든 페이지는, 눈으로 보지 않는 사용자에게는 뒤죽박죽 소음이나 다름없었다.
1. 시맨틱은 접근성의 뼈대다
시맨틱 마크업이란 요소를 그 의미에 맞게 쓰는 것이다. 제목은 제목 요소로, 목록은 목록 요소로, 버튼은 버튼 요소로 표현한다. 이 의미는 눈으로 보는 사람에게는 굳이 필요 없어 보이지만, 화면 낭독기에게는 유일한 단서다. 낭독기는 픽셀을 보지 못하니 오직 요소의 의미로 페이지를 이해한다. 그래서 시맨틱이 곧 접근성의 뼈대가 된다.
화면 낭독기는 페이지를 소리로 바꿔 읽어 준다. 이때 요소의 의미에 따라 이것은 제목이다, 이것은 버튼이다, 이것은 목록의 세 번째 항목이다 하고 알려준다. 의미가 담긴 요소를 써야 이런 안내가 가능하다. 나는 시맨틱 요소가 화면 낭독기에게 지도 역할을 한다는 걸 깨닫고, 요소 하나를 고르는 일을 훨씬 신중하게 대하게 됐다.
시맨틱이 없으면 낭독기는 페이지를 밋밋한 텍스트 덩어리로 읽는다. 제목인지 본문인지, 누를 수 있는지 아닌지 구분이 사라진다. 눈으로 보는 사람은 크기와 색으로 단번에 알아채지만, 낭독기 사용자에게는 그 단서가 통째로 사라지는 것이다. 나는 이 차이를 직접 들어본 뒤로 시맨틱을 접근성의 필수 조건으로 여기게 됐다.
좋은 소식은 시맨틱이 대단히 어렵지 않다는 점이다. 이미 있는 의미 있는 요소를 골라 쓰기만 하면 된다. 새 기술을 배우는 게 아니라, 아무 요소나 쓰던 습관을 의미에 맞게 바로잡는 것이다. 나는 화면을 만들 때 이 자리에 가장 어울리는 요소가 무엇인지 먼저 묻는 습관을 들였고, 그것만으로 접근성이 눈에 띄게 좋아졌다.
시맨틱은 접근성뿐 아니라 검색과 유지보수에도 이롭다. 의미가 또렷한 코드는 검색 로봇도 잘 읽고, 나중에 코드를 볼 사람도 구조를 쉽게 파악한다. 하나의 좋은 습관이 여러 이득으로 되돌아오는 셈이다. 나는 시맨틱을 챙기면서 접근성, 검색, 가독성이 함께 좋아지는 걸 겪으며 이 습관을 더 굳게 다졌다.
정리하면 시맨틱 마크업은 화면 낭독기가 페이지를 이해하는 유일한 단서이자 접근성의 뼈대다. 별도의 기술이 아니라 의미에 맞게 요소를 고르는 습관일 뿐이다. 나는 이 뼈대 위에서 나머지 접근성 작업이 훨씬 수월해진다는 걸 경험했다. 이제 이 원리가 구체적인 요소에서 어떻게 나타나는지 하나씩 살펴보자.
2. 네이티브 요소가 주는 선물
버튼을 예로 들어 보자. 나는 예전에 평범한 상자 요소 div에 클릭을 붙여 버튼처럼 만들곤 했다. 겉보기엔 멀쩡한 버튼이었다. 그러나 이 가짜 버튼은 키보드로 포커스가 가지 않고, 엔터나 스페이스로 눌리지도 않으며, 화면 낭독기가 버튼이라고 알려주지도 못했다. 눈으로 마우스를 쓰는 사람에게만 버튼이었던 것이다.
반면 진짜 버튼 요소 button은 이 모든 것을 처음부터 갖고 있다. 키보드 포커스가 자연스럽게 가고, 엔터와 스페이스로 눌리며, 화면 낭독기가 버튼이라고 또렷이 알려준다. 내가 아무 코드를 더하지 않아도 브라우저가 이 기능을 공짜로 준다. 나는 이 사실을 알고 나서 버튼을 만들 때 두 번 다시 상자 요소를 쓰지 않게 됐다.
링크도 마찬가지다. 다른 페이지로 이동하는 것은 링크 요소 a로 만들어야 한다. 상자에 클릭을 붙여 이동을 흉내 내면, 키보드 사용자는 그 링크에 닿을 수도 없고 낭독기도 링크라고 알리지 못한다. 이동은 링크, 동작은 버튼이라는 원칙을 지키기만 해도 접근성 문제의 상당수가 애초에 생기지 않는다.
목록도 의미 있는 요소로 표현해야 한다. 여러 항목이 나열될 때는 목록 요소를 쓴다. 그러면 낭독기가 항목이 모두 몇 개이며 지금 몇 번째인지 알려준다. 상자를 여러 개 늘어놓기만 하면 이 안내가 사라진다. 나는 메뉴나 카드 묶음을 만들 때 겉모양은 자유롭게 꾸미되 바탕은 목록 요소로 짜는 습관을 들였다.
가짜 요소로 진짜 요소를 흉내 내려면 잃어버린 기능을 전부 손으로 되살려야 한다. 포커스를 받게 하려면 tabindex를 붙이고, 역할을 알리려면 role="button"을 붙이고, 키보드 처리까지 직접 코드로 짜야 한다. 그렇게 애써도 진짜 요소만 못한 경우가 많다. 나는 이 수고를 겪고 나서, 처음부터 진짜 요소를 쓰는 게 압도적으로 낫다는 걸 배웠다.
정리하면 네이티브 요소는 포커스, 키보드 조작, 역할 안내를 공짜로 준다. 이 선물을 마다하고 상자 요소로 흉내 내는 것은 스스로 일을 늘리는 동시에 접근성을 해치는 일이다. 나는 이 자리에 맞는 진짜 요소가 무엇인지 먼저 묻는 것을 접근성의 첫 번째 습관으로 삼았다. 다음은 페이지 전체의 골격을 잡는 요소들이다.
3. 랜드마크로 골격을 잡는다
페이지에는 큰 구획들이 있다. 머리글, 주요 메뉴, 본문, 곁가지, 바닥글이다. 이 구획을 header, nav, main, aside, footer 같은 의미 있는 요소로 표현하면, 각 구획이 랜드마크라는 이정표가 된다. 화면 낭독기 사용자는 이 이정표를 따라 페이지를 영역 단위로 건너뛰며 탐색할 수 있다.
랜드마크가 없는 페이지는 낭독기 사용자에게 출구 없는 미로와 같다. 원하는 곳으로 바로 갈 수 없어 처음부터 끝까지 순서대로 들어야 한다. 반면 랜드마크가 잘 잡힌 페이지에서는 본문으로, 메뉴로, 바닥글로 단숨에 점프할 수 있다. 나는 이 차이를 알고 나서 페이지 골격을 상자가 아니라 의미 있는 구획 요소로 짜기 시작했다.
본문을 담는 main은 페이지에 하나만 두는 것이 원칙이다. 이 페이지의 핵심 내용이 어디인지를 딱 하나로 가리켜야 낭독기가 본문 바로가기를 정확히 안내할 수 있기 때문이다. 머리글과 바닥글은 이 본문 바깥에 둔다. 나는 이 규칙을 지키면서 페이지의 중심이 어디인지가 코드에서도 또렷해지는 걸 느꼈다.
같은 종류의 랜드마크가 여러 개일 때도 있다. 예를 들어 주요 메뉴와 바닥글 메뉴가 둘 다 있으면, 낭독기는 둘을 구분하지 못해 혼란스러워한다. 이럴 때는 각 메뉴에 이름표를 붙여 무슨 메뉴인지 알려준다. 나는 이름을 붙이는 작은 수고가 여러 개의 같은 영역을 또렷이 구분해 준다는 걸 배우고 습관으로 삼았다.
랜드마크는 눈으로 보는 사람에게는 드러나지 않는다. 그러나 낭독기 사용자에게는 페이지를 오가는 지하철 노선도와 같다. 보이지 않는 이 구조를 챙기는 것이 성숙한 마크업이라고 나는 생각한다. 겉모습은 상자로 만든 것과 똑같지만, 그 안의 의미는 하늘과 땅 차이다. 이 보이지 않는 층이 접근성을 좌우한다.
정리하면 머리글, 메뉴, 본문, 곁가지, 바닥글을 의미 있는 구획 요소로 표현하면 각 영역이 랜드마크가 되어 낭독기 탐색을 돕는다. 본문은 하나로, 같은 영역이 여럿이면 이름표로 구분한다. 나는 이 골격을 먼저 잡고 그 안을 채우는 순서로 작업한다. 골격 다음으로 중요한 것은 그 안의 제목 계층이다.
4. 제목 계층이 목차가 된다
제목은 페이지의 목차를 만든다. 큰 제목부터 작은 제목까지 h1에서 h6까지 여섯 단계가 있고, 이 단계를 순서대로 쓰면 화면 낭독기 사용자가 제목만 훑어 페이지 구조를 파악할 수 있다. 낭독기 사용자에게 제목 이동은 가장 즐겨 쓰는 탐색 수단이다. 그래서 제목 계층은 접근성에서 매우 중요하다.
제목을 고를 때는 크기가 아니라 의미로 골라야 한다. 나는 예전에 글자를 작게 보이고 싶어서 큰 제목 대신 작은 제목 요소를 쓰곤 했다. 이건 계층을 망가뜨리는 실수다. 크기는 스타일로 조절하고, 요소는 의미에 맞는 단계를 골라야 한다. 나는 이 원칙을 지키고 나서 제목만 들어도 페이지 구조가 그려지는 코드를 만들 수 있었다.
제목 단계는 건너뛰지 않는 것이 좋다. 큰 제목 바로 아래에 두 단계를 건너뛴 제목이 오면, 낭독기 사용자는 중간 단계가 빠진 이유를 알 수 없어 혼란스러워한다. 한 단계씩 차근차근 내려가야 목차가 매끄럽다. 나는 제목을 넣을 때마다 바로 위 제목과의 단계 차이를 확인하는 습관으로 이 실수를 막는다.
가장 큰 제목 h1은 페이지의 대표 제목이라 하나만 두는 것이 원칙이다. 이 페이지가 무엇에 관한 것인지를 한마디로 알려주는 자리이기 때문이다. 여러 개를 두면 페이지의 주제가 흐릿해진다. 나는 페이지마다 대표 제목을 딱 하나 정하고, 그 아래로 작은 제목들을 가지처럼 뻗어 나가게 구성한다.
제목 계층이 잘 잡히면 눈으로 보는 사람에게도 이롭다. 잘 나뉜 제목은 글을 훑어보기 쉽게 하고, 검색 로봇에게도 문서 구조를 알려준다. 접근성을 위해 챙긴 제목 계층이 가독성과 검색까지 함께 끌어올리는 것이다. 나는 이 겹치는 이득을 겪으며 제목 계층을 그냥 스타일이 아니라 문서의 설계도로 대하게 됐다.
정리하면 제목은 페이지의 목차이자 낭독기 사용자의 주요 이동 수단이므로, 크기가 아니라 의미로 고르고 단계를 건너뛰지 않으며 대표 제목은 하나만 둔다. 나는 이 계층을 페이지의 설계도처럼 먼저 그린다. 마지막으로, 시맨틱만으로 부족할 때 쓰는 도구인 별도 속성에 대한 원칙을 짚어 보자.
5. 별도 속성은 최후의 수단이다
시맨틱 요소로도 표현하기 어려운 복잡한 구성이 있다. 이럴 때 요소의 역할과 상태를 보조기기에 알려주는 별도의 접근성 속성을 쓴다. 이 속성들은 강력하지만, 첫 번째 원칙은 되도록 쓰지 않는 것이다. 네이티브 요소로 되는 일을 굳이 이 속성으로 대체하지 말라는 뜻이다. 나는 이 원칙을 배우고 나서 접근성 속성을 훨씬 조심스럽게 다루게 됐다.
이 원칙이 있는 이유는, 잘못 쓴 접근성 속성이 아예 안 쓴 것보다 나쁘기 때문이다. 네이티브 버튼을 쓰면 브라우저가 모든 걸 챙겨주지만, 상자에 버튼 역할만 붙이고 키보드 처리를 빠뜨리면 겉만 버튼인 함정이 된다. 나는 이런 반쪽짜리 처리가 사용자를 더 헷갈리게 만든다는 걸 겪고 나서, 속성보다 요소를 먼저 떠올리게 됐다.
별도 속성은 동작을 만들어 주지 않는다는 점도 중요하다. 이 속성들은 보조기기에 역할과 상태를 알릴 뿐, 키보드 조작이나 실제 기능은 하나도 만들어 주지 않는다. 버튼 역할을 붙였다고 엔터로 눌리지는 않는다. 나는 이 사실을 오해했다가 헛수고를 한 적이 있어, 속성과 동작은 별개라는 점을 늘 되새긴다.
그렇다면 별도 속성은 언제 쓸까. 네이티브 요소로 표현할 수 없는 상황에서만 쓴다. 예를 들어 접었다 펴는 상태나, 텍스트 없는 아이콘 버튼의 이름처럼 요소만으로는 전할 수 없는 정보를 보조기기에 알릴 때다. 이런 자리에서는 별도 속성이 꼭 필요하다. 나는 이 속성을 요소로 안 되는 틈을 메우는 도구로 이해한다.
순서를 정리하면 이렇다. 먼저 의미에 맞는 네이티브 요소를 찾고, 그것으로 안 되면 그때 별도 속성을 더한다. 이 순서만 지켜도 대부분의 접근성 문제가 풀린다. 나는 새 구성을 만들 때마다 이 순서를 밟는다. 요소가 먼저, 속성은 나중이라는 이 단순한 규칙이 나를 수많은 함정에서 구해 주었다.
정리하면 시맨틱 마크업은 그 자체로 접근성의 절반을 이룬다. 의미에 맞는 요소를 고르고, 랜드마크로 골격을 잡고, 제목으로 목차를 만들며, 별도 속성은 최후의 수단으로만 쓴다. 나는 이 원리를 접근성의 출발점으로 삼는다. 다음 편에서는 이미지에 의미를 입히는 대체 텍스트를 어떻게 잘 쓰는지 더 깊이 파고든다.