접근성(a11y) 기초 — 모두를 위한 사이트

시맨틱 태그(Day 2)를 왜 그렇게 강조했는지, 오늘 그 답이 나옵니다

10초 핵심 요약

01

스크린 리더는 태그 이름으로 화면을 "듣습니다"

시각 장애가 있는 사용자는 화면을 소리로 변환해주는 스크린 리더를 씁니다. 이 프로그램은 <div>만 보면 "그냥 덩어리"라고만 읽지만, <nav>을 보면 "탐색 메뉴입니다"라고, <button>을 보면 "버튼입니다, 클릭 가능"이라고 읽어줍니다. Day 2에서 배운 시맨틱 태그가 여기서 진짜 힘을 발휘합니다.

div로 만든 버튼

스크린 리더: "텍스트: 제출" (클릭 가능한지 알 수 없음)

실제 button 태그

스크린 리더: "버튼, 제출" (클릭 가능하다고 명확히 안내)

02

alt 텍스트 제대로 쓰기

Day 3~9에서 이미지에 alt를 습관적으로 비워뒀다면(alt=""), 그건 "이 이미지는 순수 장식이라 설명이 필요 없다"는 뜻이어야 정확합니다. 내용을 전달하는 이미지라면 그 내용을 설명하는 텍스트를 넣어야 합니다.

이미지 종류alt 처리
순수 장식용 배경/아이콘alt="" (있으나 마나한 정보는 건너뛰게)
글의 썸네일, 정보 전달 사진내용을 요약한 실제 설명 텍스트
버튼 대신 쓰인 아이콘"메뉴 열기"처럼 기능을 설명
03

키보드만으로 다 되는가

마우스 없이 Tab 키만으로 링크, 버튼, 폼 입력칸을 순서대로 옮겨 다닐 수 있어야 합니다. Day 18의 햄버거 메뉴처럼 클릭으로만 열리게 만든 요소가 있다면, 키보드로 포커스가 갔을 때도 Enter로 열리는지 확인해야 합니다(버튼 태그를 썼다면 기본으로 지원됩니다).

지금 이 페이지에서 마우스를 내려놓고 Tab 키만 눌러보세요. 어떤 요소에 포커스가 가는지, 지금 어디에 있는지 시각적으로 표시(포커스 링)되는지 확인해보세요.
04

오늘의 실습 + AI 프롬프트

1F12 → Lighthouse 탭(Day 21에서 다룬 도구)에서 Accessibility 점수를 측정해봅니다.
2지적된 항목(대비 부족, alt 누락 등)을 하나씩 고쳐가며 점수 변화를 확인합니다.
AI에게 이렇게 지시해 보세요: "이 HTML에서 접근성 문제(누락된 alt, 시맨틱하지 않은 클릭 요소, 색상 대비 부족 등)를 찾아서 목록으로 알려주고 수정해줘."
05

Day 37 완료 체크리스트

시맨틱 태그가 스크린 리더에게 어떻게 다르게 읽히는지 설명할 수 있다.
alt="" 와 실제 설명 텍스트를 상황에 맞게 구분해서 쓸 수 있다.
Lighthouse Accessibility 점수를 측정하고 지적 사항을 하나 이상 고쳐봤다.
스스로 설명해보기 — 시맨틱 태그가 스크린 리더에게 왜 다르게 읽히는지 설명할 수 있나요?

오늘의 용어

a11y
accessibility(접근성)의 줄임말. a와 y 사이 11글자를 숫자로 축약
스크린 리더
화면 내용을 음성으로 읽어주는 보조 기술 프로그램
포커스 링
키보드로 이동 중인 요소를 시각적으로 표시하는 테두리