대비율·포커스 표시로 SEO 점수까지 올리는 방법
웹 접근성이라는 단어를 처음 들었을 때 솔직히 코웃음을 쳤다. 그게 무슨 대수냐 싶었다. 화면 잘 보이고 클릭 잘 되면 끝 아니냐는 생각이었다. 그런데 현장에서 10년 넘게 굴러다니다 보니 그 생각이 얼마나 좁은 우물 안 개구리였는지 뼈저리게 느끼게 됐다. 접근성은 장애인을 위한 시혜가 아니었다. 구조가 단단해야 건물이 지진에도 버티듯, 접근성이 갖춰진 웹은 검색 엔진도 제대로 읽어낸다는 걸 알게 됐다.
WCAG가 뭔지부터 제대로 짚고 가자
WCAG는 Web Content Accessibility Guidelines의 줄임말이다. 국제 웹 표준 기구 W3C에서 만든 웹 콘텐츠 접근성 지침이다. 현재 기준으로 2.1 버전이 가장 널리 쓰이며 2.2 버전도 공식 권고안으로 나와 있다. 레벨은 A, AA, AAA 세 단계로 나뉘는데, 실무에서는 AA 수준을 맞추는 걸 목표로 잡으면 된다. AAA는 솔직히 일반 상업용 사이트에서는 과도하다 싶을 정도로 엄격하다.
처음 이걸 접했을 때 느낌은 마치 수십 년 된 전기 배선도를 들고 건물 점검하는 기분이었다. 항목이 너무 많고 용어도 낯설고. 그런데 핵심을 뽑아보면 결국 두 가지로 압축된다. 첫째, 사람 눈이 잘 인식할 수 있어야 한다. 둘째, 키보드만으로도 사용할 수 있어야 한다. 이 두 가지를 해결하는 핵심 도구가 바로 색상 대비율과 포커스 표시다.
색상 대비율: 눈이 아니라 데이터로 증명하는 가독성
색상 대비율이란 텍스트 색상과 배경 색상 사이의 명암 차이를 수치로 표현한 것이다. WCAG AA 기준으로 일반 텍스트는 4.5:1 이상, 크거나 굵은 텍스트는 3:1 이상이어야 한다. 숫자만 보면 별것 아닌 것 같지만 이게 실제로 어느 정도의 차이인지 경험해 보면 충격적이다.
몇 년 전 모바일 앱 연동 웹 페이지를 만들 때였다. 디자이너가 트렌디하다며 연한 회색 배경에 조금 더 연한 회색 텍스트를 밀어붙였다. 비율을 계산해 보니 2.1:1이었다. 건강한 30대 개발자 눈에는 그럴듯해 보였지만, 테스트 기기 중 화면이 다소 낡은 태블릿에서 보니 텍스트가 거의 안 보였다. 외부 햇빛 아래에서는 더 심각했다. 결국 디자인을 갈아엎고 4.7:1 수준으로 맞췄다. 이후 모바일 이탈률이 눈에 띄게 줄었다. 가독성이 개선되면 체류 시간이 늘고, 그게 신호로 작용해 SEO 점수도 올라간다는 걸 그때 처음 몸으로 이해했다.
색상 대비율을 확인하는 도구는 따로 설치할 것도 없다. Chrome 개발자 도구에 내장돼 있고, 아래처럼 간단한 코드로도 확인 가능하다.
<!-- 대비율 불량 예시 (2.1:1 수준, 사용 금지) -->
<p style="color: #aaaaaa; background-color: #cccccc;">
이 텍스트는 대비가 너무 낮아 읽기 어렵습니다
</p>
<!-- 대비율 양호 예시 (7:1 이상, AA/AAA 모두 통과) -->
<p style="color: #1a1a1a; background-color: #ffffff;">
이 텍스트는 충분한 대비율로 누구나 읽기 쉽습니다
</p>
온라인 도구를 쓰고 싶다면 WebAIM Contrast Checker(https://webaim.org/resources/contrastchecker/)가 가장 직관적이다. 색상 코드 두 개 입력하면 바로 통과 여부를 알려준다.
포커스 표시: 키보드 사용자에게도 길을 알려주는 이정표
포커스 표시는 키보드로 Tab 키를 눌러 웹 페이지를 탐색할 때 현재 어느 요소에 집중돼 있는지 표시해 주는 시각적 신호다. 마치 어두운 공연장에서 무대 조명이 배우를 비추는 것처럼, 포커스 링은 사용자에게 지금 커서가 어디 있는지 알려준다.
현장에서 이걸 날려버리는 개발자들이 너무 많았다. 이유가 기가 막혔다. "링 모양이 디자인을 망가뜨린다"는 것이었다. CSS 한 줄, outline: none;으로 싹 지워버리는 거다. 당장 눈에는 깔끔해 보일 수 있다. 그런데 이건 도로에서 차선 표시를 지워버리는 것과 같다. 마우스를 쓰는 사람은 모르지만, 키보드나 보조 기기로 탐색하는 사람은 길을 잃는다.
잘못된 방식과 올바른 방식을 나란히 보자.
/* 잘못된 방법 - 절대 사용하지 말 것 */
* {
outline: none;
}
a:focus {
outline: none;
}
/* 올바른 방법 - 포커스는 살리되 디자인에 맞게 커스터마이징 */
a:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 2px;
border-radius: 2px;
}
button:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 2px;
}
:focus-visible 의사 클래스를 쓰면 마우스 클릭 시에는 포커스 링이 나타나지 않고, 키보드 탐색 시에만 나타난다. 이게 핵심이다. 디자인 팀의 불만도 줄고 접근성도 지킬 수 있다. 이 방법을 팀에 공유했을 때 디자이너가 "왜 진작 말 안 했냐"며 오히려 반겼다.
skip navigation: 현장에서 가장 먼저 넣어야 할 코드
접근성의 또 다른 기본 중 기본이 skip navigation이다. 메뉴가 길고 복잡한 페이지에서 키보드 사용자가 매번 수십 개의 메뉴 링크를 Tab으로 건너뛰어야 한다면 고역이다. 버스 타고 가다가 매 정류장마다 강제로 내렸다 타야 하는 상황과 같다. Skip navigation 링크는 그 고역을 건너뛸 수 있는 직행 노선이다.
<!DOCTYPE html>
<html lang="ko">
<head>
<meta charset="UTF-8">
<title>접근성 예제</title>
</head>
<body>
<!-- 스킵 내비게이션: 반드시 body 최상단에 위치 -->
<a href="#main-content">본문 바로가기</a>
<nav>
<ul>
<li><a href="/about">소개</a></li>
<li><a href="/portfolio">포트폴리오</a></li>
<li><a href="/contact">연락하기</a></li>
</ul>
</nav>
<main id="main-content">
<h1>메인 콘텐츠 영역</h1>
<p>여기서부터 본문이 시작됩니다.</p>
</main>
</body>
</html>
SEO와 접근성의 연결고리: 구글 봇도 스크린 리더처럼 읽는다
접근성이 SEO와 직결되는 이유는 단순하다. 구글 크롤러는 시각이 없다. 이미지를 볼 수 없고, 동영상을 볼 수 없고, JavaScript로 렌더링된 화면을 처음부터 완벽하게 인식하지 못한다. 결국 구글 봇이 페이지를 이해하는 방식은 스크린 리더가 페이지를 읽는 방식과 매우 유사하다.
의미 있는 HTML 구조, 명확한 alt 텍스트, 충분한 색상 대비, 키보드 접근 가능한 인터랙션 요소. 이 모든 것이 접근성 기준이기도 하고 SEO 기준이기도 하다. 두 마리 토끼를 동시에 잡는 게 아니라, 원래부터 같은 토끼였던 것이다.
<!-- SEO와 접근성을 동시에 만족하는 이미지 마크업 -->
<figure>
<img
src="seoul-office-desk.jpg"
alt="서울 도심 오피스 책상 위에 놓인 노트북과 키보드, 현업 개발 환경"
width="800"
height="450"
loading="lazy"
>
<figcaption>현업 개발자의 실제 작업 환경</figcaption>
</figure>
Lighthouse로 접근성 점수 바로 확인하는 방법
Chrome DevTools에서 F12 키를 눌러 Lighthouse 탭을 선택하면 된다. Accessibility 항목이 별도로 있으며 0~100점으로 측정된다. 처음 돌려봤을 때 80점대 초반이 나와서 충격받았던 기억이 있다. 그냥 아무 생각 없이 만든 페이지가 이 정도밖에 안 된다는 거였다.
<!-- Lighthouse 접근성 점수를 올리는 기본 마크업 구조 -->
<!DOCTYPE html>
<html lang="ko">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>페이지 제목 - 사이트명</title>
</head>
<body>
<header role="banner">
<nav aria-label="주요 내비게이션">
<ul>
<li><a href="/">홈</a></li>
</ul>
</nav>
</header>
<main role="main" id="main-content">
<article>
<h1>글 제목</h1>
<p>본문 내용</p>
</article>
</main>
<footer role="contentinfo">
<p>저작권 정보</p>
</footer>
</body>
</html>
현장에서 느낀 장단점 정리
장점은 분명했다. Lighthouse 접근성 점수가 90점대로 올라가자 전체 SEO 점수도 덩달아 올랐다. 페이지 체류 시간이 늘었고 이탈률이 줄었다. 무엇보다 코드 구조 자체가 훨씬 깔끔해졌다. 접근성을 고려하면서 자연스럽게 시맨틱 마크업을 쓰게 되고, 시맨틱 마크업은 유지보수를 쉽게 만든다. 일석삼조라는 말이 이럴 때 쓰는 말이구나 싶었다.
단점은 초기 적용 비용이 생각보다 크다는 것이다. 기존에 만들어진 사이트에 소급 적용하는 건 정말 고통스럽다. 색상 대비율 하나 바꾸면 디자인 전체를 다시 검토해야 하는 경우도 생기고, 포커스 스타일 작업하다 보면 레거시 코드가 줄줄이 딸려 나온다. 신규 프로젝트 시작할 때부터 접근성을 기준으로 잡는 게 결과적으로 몇 배는 더 효율적이다.
마무리: 접근성은 배려가 아니라 기술 실력의 척도다
20대 때는 빠르게 만들어서 올리는 게 능력인 줄 알았다. 30대 초반에는 화려한 애니메이션과 복잡한 기술 스택이 실력인 줄 알았다. 40대가 되어 현장에서 수백 개의 페이지를 만들어보고, 검색 순위가 오르락내리락하는 걸 직접 보고 나서야 진짜 기초가 무엇인지 알게 됐다. 웹 접근성은 그 기초 중에서도 가장 눈에 안 띄지만 가장 중요한 부분이다. 마치 건물 기초 공사처럼, 완성된 건물을 보면 기초가 보이지 않지만 기초가 없으면 건물 자체가 서질 못한다.
색상 대비율 4.5:1. 포커스 표시 살리기. 이 두 가지만 제대로 챙겨도 Lighthouse 접근성 점수는 쉽게 80점대 이상으로 올라간다. 그리고 그 점수는 구글이 이 사이트를 신뢰할 수 있는 정보 소스로 인식하는 신호 중 하나가 된다. 접근성을 챙긴다는 것은 장애인을 배려한다는 의미를 넘어서, 모든 환경에서 모든 기기에서 정보가 제대로 전달되도록 만든다는 의미다. 이건 개발자로서의 기본 책임이고, 동시에 SEO 최적화의 핵심 전략이기도 하다.
현장에서 가장 많이 봐온 실수는 아름다움을 위해 접근성을 희생하는 것이었다. 그런 페이지들은 대부분 6개월을 넘기지 못하고 검색 순위 뒤편으로 밀려났다. 반면 투박해 보여도 구조가 탄탄한 페이지는 꾸준히 검색 결과 상단에서 버텼다. 오랫동안 개발 일을 해오면서 얻은 결론 하나는 이것이다. 빠르게 만드는 것보다 제대로 만드는 것이 결국 더 빠른 길이다. 접근성은 귀찮은 규칙이 아니라, 제대로 만들기 위한 가이드다. 이 관점 하나를 바꿨더니 내가 만드는 페이지의 퀄리티 자체가 달라졌다. SEO 점수는 그 결과로 따라오는 숫자에 불과하다.
앞으로 새 프로젝트를 시작할 때마다 처음 하는 일이 Lighthouse 기준 접근성 체크리스트 작성이 됐다. 프로젝트 막바지에 접근성 이슈를 잡으려 하면 시간도 두 배, 비용도 두 배가 든다는 것을 너무 많이 경험했기 때문이다. 처음부터 올바른 방식으로 만드는 게 가장 효율적인 방법이라는 걸 이제는 확신한다.
출처 및 참고 경로
- WCAG 2.1 공식 문서: https://www.w3.org/TR/WCAG21/
- WCAG 2.2 공식 문서: https://www.w3.org/TR/WCAG22/
- WebAIM 색상 대비율 체크: https://webaim.org/resources/contrastchecker/
- Google Lighthouse 접근성 감사: https://developer.chrome.com/docs/lighthouse/accessibility/
- MDN :focus-visible 문서: https://developer.mozilla.org/ko/docs/Web/CSS/:focus-visible
- 한국형 웹 콘텐츠 접근성 지침(KWCAG): https://www.wah.or.kr