왜 웹 표준과 접근성을 한 편에 묶었는가

지금까지 배운 HTML·CSS·JavaScript는 “코드가 어떻게 동작하는가”에 초점을 맞췄습니다. 이 편은 시선을 조금 바꿔 “이 코드를 왜 이렇게 짜야 하는가”라는 질문을 다룹니다. 웹 표준(web standards)은 모든 브라우저·기기에서 웹 페이지가 똑같이 동작하도록 만드는 공통 규칙이고, 웹 접근성(web accessibility)은 장애가 있거나 특수한 환경에 있는 사용자도 웹 페이지를 문제없이 이용할 수 있게 만드는 원칙입니다. 이 둘은 서로 다른 개념이지만, 04편에서 다룬 시맨틱 태그(semantic tag, 의미를 가진 태그)를 정확히 쓰는 것이 두 가지 목표를 동시에 달성하는 핵심 수단이라는 점에서 밀접하게 연결됩니다. 독학사 2단계 시험은 이 두 개념의 정의를 암기했는지보다, 구체적인 마크업 사례를 보여 주고 “이것이 표준·접근성을 지켰는가”를 판별할 수 있는지를 주로 묻습니다.

쉽게 말하면: 웹 표준이 “모두가 같은 규칙으로 건물을 지어야 어떤 사람이 와도 헤매지 않는다”는 약속이라면, 웹 접근성은 “휠체어를 탄 사람도, 시각장애인도 그 건물에 문제없이 들어올 수 있게 경사로와 점자 안내판을 만들어야 한다”는 원칙입니다.

1. 웹 표준 — 브라우저마다 다르게 동작하지 않도록

웹 표준이 필요했던 이유

웹 초창기에는 브라우저마다 HTML·CSS를 해석하는 방식이 조금씩 달랐습니다. 그 결과 같은 HTML 코드를 작성해도 어떤 브라우저에서는 정상적으로 보이고, 다른 브라우저에서는 레이아웃이 깨지는 일이 흔했습니다. 개발자는 이를 피하기 위해 브라우저마다 다른 코드를 따로 작성해야 했고, 이는 비효율적일 뿐 아니라 사용자 경험의 일관성도 해쳤습니다.

웹 표준(web standards)은 이 문제를 해결하기 위해 W3C(World Wide Web Consortium, 월드와이드웹 컨소시엄)나 WHATWG(Web Hypertext Application Technology Working Group, 웹 하이퍼텍스트 애플리케이션 기술 워킹 그룹) 같은 국제 표준화 단체가 정한, HTML·CSS·JavaScript 등이 따라야 할 공식 규칙입니다. 브라우저 제작사들이 이 표준을 준수해 브라우저를 만들면, 개발자는 표준에 맞게 작성한 코드 하나만으로 어떤 브라우저에서도 동일하게(또는 최대한 비슷하게) 동작하는 페이지를 만들 수 있습니다.

쉽게 말하면: 웹 표준은 전 세계 콘센트 모양을 하나로 통일하는 것과 비슷합니다. 규격이 통일되어 있으면 어떤 나라에서 만든 전자제품이든 그 콘센트에 꽂아 쓸 수 있습니다.

웹 표준을 지키지 않았을 때의 문제

이 표에서 보듯 “검색 엔진 최적화 저하”와 “접근성 저하”는 서로 다른 문제처럼 보이지만, 뿌리는 같습니다. 웹 표준을 지키며 의미가 명확한 태그(시맨틱 태그)를 쓰면 검색 엔진도, 스크린 리더 같은 보조 기술도 문서의 구조를 정확히 파악할 수 있기 때문입니다. 이 연결 고리가 바로 다음 절에서 다룰 웹 접근성의 핵심입니다.

2. 웹 접근성 — 누구나 이용할 수 있는 웹

웹 접근성의 정의

웹 접근성(web accessibility)은 시각·청각·운동·인지 등에 장애가 있는 사용자나, 나이가 많거나, 일시적으로 신체 기능이 제한된 사용자(예: 손을 다쳐 마우스를 못 쓰는 상황), 또는 특수한 환경(예: 화면이 작은 기기, 느린 네트워크)에 있는 사용자도 웹 콘텐츠를 문제없이 인식하고 이용할 수 있도록 만드는 것을 말합니다. W3C 산하의 WAI(Web Accessibility Initiative, 웹 접근성 이니셔티브)가 이 분야의 국제 표준을 주도하고 있습니다.

자주 틀리는 점: 웹 접근성을 “시각장애인을 위한 기능”으로만 좁게 이해하는 경우가 많습니다. 실제로는 청각장애(자막 필요), 운동장애(키보드만으로 조작), 인지장애(단순하고 명확한 구조 필요), 그리고 일시적·상황적 제약(밝은 야외에서 화면이 잘 안 보이는 경우 등)까지 모두 포괄하는 개념입니다.

접근성의 네 가지 원칙 (POUR)

WAI가 정리한 웹 콘텐츠 접근성 지침(WCAG, Web Content Accessibility Guidelines)은 접근성을 네 가지 원칙으로 요약합니다. 각 원칙의 앞 글자를 따서 POUR(파우어처럼 읽으며, 원래 “붓다”라는 뜻의 단어에서 앞글자만 따온 약칭)라고 부릅니다.

이 네 원칙 중 시험에서 가장 자주 구체적인 사례로 등장하는 것은 “인식의 용이성”과 “운용의 용이성”입니다. 예를 들어 이미지에 alt 속성이 없으면, 스크린 리더(시각장애인이 화면 내용을 음성으로 듣도록 돕는 보조 기술 프로그램)가 그 이미지를 사용자에게 전혀 설명해 줄 수 없어 “인식” 자체가 불가능해집니다.

<!-- 접근성을 지키지 않은 예: 이미지의 의미를 스크린 리더가 전혀 알 수 없음 -->
<img src="chart.png">
 
<!-- 접근성을 지킨 예: alt 속성으로 이미지의 의미를 텍스트로 제공 -->
<img src="chart.png" alt="2024년 분기별 매출 증가 추이를 나타낸 막대그래프">

자주 틀리는 점: alt 속성에 이미지 파일명(chart.png)이나 의미 없는 문구(“이미지”)를 그대로 넣는 경우가 많습니다. alt의 목적은 그 이미지가 전달하는 의미를 텍스트로 대신 전달하는 것이므로, 파일명이 아니라 이미지의 실제 내용을 설명하는 문장을 넣어야 합니다. 단, 순수하게 장식용이라 의미 전달이 필요 없는 이미지는 alt=""(빈 문자열)로 두어, 스크린 리더가 그 이미지를 건너뛰게 하는 것도 올바른 접근성 처리입니다.

시맨틱 마크업과 접근성의 연결

04편에서 header, nav, main, article, footer 같은 시맨틱 태그(semantic tag)가 문서의 의미 있는 구조를 나타낸다고 배웠습니다. 이 시맨틱 태그는 접근성 관점에서도 결정적인 역할을 합니다. 스크린 리더는 시맨틱 태그를 인식해 “지금 내비게이션 영역입니다”, “본문이 시작됩니다”처럼 사용자에게 구조를 안내할 수 있기 때문입니다. 반대로 문서 전체를 의미 없는 div로만 채우면, 스크린 리더 사용자는 지금 자신이 페이지의 어느 영역을 읽고 있는지 전혀 알 수 없습니다.

<!-- 접근성이 떨어지는 예: 의미 없는 div만 사용 -->
<div class="상단">사이트 이름</div>
<div class="메뉴">
  <div>홈</div>
  <div>소개</div>
</div>
<div class="본문">여기부터 실제 내용입니다.</div>
 
<!-- 접근성을 고려한 예: 시맨틱 태그로 구조를 명확히 표시 -->
<header>사이트 이름</header>
<nav>
  <a href="/">홈</a>
  <a href="/about">소개</a>
</nav>
<main>여기부터 실제 내용입니다.</main>

두 코드는 화면에 보이는 모습(CSS를 적용하기 전이라면)이 비슷할 수 있지만, 스크린 리더가 읽어 주는 정보의 질은 완전히 다릅니다. nav 태그를 쓴 두 번째 예제에서는 스크린 리더 사용자가 “내비게이션 영역으로 건너뛰기” 같은 기능을 사용해 메뉴 부분만 곧바로 찾아갈 수 있지만, 첫 번째 예제의 div들은 스크린 리더 입장에서 아무 의미 없는 상자의 나열일 뿐입니다.

쉽게 말하면: div로만 만든 페이지는 방 이름표가 하나도 없는 건물과 같습니다. 눈으로 보는 사람은 가구 배치를 보고 “여기가 거실이구나” 짐작할 수 있지만, 앞을 보지 못하는 사람에게는 안내판(시맨틱 태그) 없이는 그 방이 거실인지 화장실인지 알 방법이 없습니다.

키보드 접근성 — 운용의 용이성 사례

마우스를 사용할 수 없는 사용자(운동장애가 있거나, 스크린 리더를 쓰는 시각장애인 대부분 포함)를 위해서는 키보드만으로 페이지의 모든 기능을 사용할 수 있어야 합니다. 이때 핵심이 되는 것이 tabindex(탭 순서, Tab 키를 눌렀을 때 초점이 이동하는 순서를 지정하는 속성)와, 클릭 가능한 요소를 의미에 맞는 태그로 만드는 것입니다.

<!-- 접근성이 떨어지는 예: div에 클릭 이벤트만 붙임 -->
<div onclick="제출하기()">제출</div>
 
<!-- 접근성을 고려한 예: button 태그 사용 -->
<button onclick="제출하기()">제출</button>

div는 원래 클릭이나 키보드 초점(포커스)과 아무 관련이 없는 태그이므로, div에 클릭 이벤트만 걸어 두면 마우스로는 눌러지지만 Tab 키로는 그 요소에 초점이 가지 않고, Enter 키를 눌러도 아무 반응이 없습니다. 반면 button 태그는 브라우저가 기본적으로 Tab 키로 초점을 받을 수 있게, Enter나 스페이스바로 클릭과 동일하게 동작하게 만들어 놓았습니다. “버튼처럼 보이게 CSS만 입힌 div”와 “실제 button 태그”의 차이를 판별하는 문제가 접근성 파트에서 자주 나오는 이유가 여기에 있습니다.

3. 웹 표준·접근성 판별 연습

다음은 시험에서 실제로 나올 수 있는 형태의 판별형 사례입니다. 각 사례가 웹 표준·접근성 관점에서 무엇이 문제인지 짚어 봅니다.

이 표의 공통점은 “시각적으로는 문제없어 보이지만, 특정 조건의 사용자에게는 정보가 아예 전달되지 않거나 조작이 불가능해진다”는 것입니다. 웹 표준과 접근성을 함께 고려한다는 것은, 화면을 눈으로 보고 마우스로 조작하는 사용자뿐 아니라 그렇지 않은 사용자까지 염두에 두고 마크업을 설계하는 태도를 뜻합니다.

핵심 정리

• 웹 표준은 W3C·WHATWG 같은 단체가 정한 규칙으로, 이를 지키면 브라우저·기기와 무관하게 일관된 동작을 보장할 수 있다.
• 웹 접근성은 장애·고령·일시적 제약이 있는 사용자도 웹 콘텐츠를 이용할 수 있게 하는 원칙이며, POUR(인식·운용·이해·견고성) 네 원칙으로 요약된다.
• 시맨틱 태그는 웹 표준과 접근성을 동시에 만족시키는 핵심 수단으로, 스크린 리더 등 보조 기술이 문서 구조를 정확히 파악하게 해 준다.
• 이미지에는 의미를 설명하는 alt 속성을, 클릭 가능한 요소에는 div 대신 button 같은 의미에 맞는 태그를 사용해야 키보드·스크린 리더 사용자도 조작할 수 있다.
• 색상만으로 정보를 전달하거나 placeholder만으로 입력창의 용도를 표시하는 것은 접근성을 해치는 대표적인 실수다.

마무리 복습

참고 자료

• W3C WAI - Web Accessibility Initiative 
• W3C WAI - Introduction to Web Accessibility