16강. 접근성 기초: 키보드·대체 텍스트·명확한 버튼 처리하기

?1. 이번 강의에서 해결할 문제

마우스로는 사용할 수 있지만 Tab 순서가 보이지 않거나 같은 이름의 ‘보기’ 버튼이 반복됩니다. 홈부터 폼까지 키보드와 접근성 트리로 점검합니다.

✓2. 학습 목표

✓이번 강의를 마치면

• 시맨틱 요소의 기본 키보드 동작을 활용합니다.
• 초점 표시와 컨트롤의 접근 가능한 이름을 확인합니다.
• 이미지, 모달, 상태 문구의 대체 정보를 점검합니다.

◇3. 핵심 개념

접근성은 마지막 장식이 아니라 HTML 선택에서 시작합니다. 링크는 이동, 버튼은 동작을 맡고 보이는 label과 제목이 이름을 제공합니다. DOM 순서와 키보드 순서가 자연스러워야 하며 긍정적인 tabindex로 억지로 재배열하지 않습니다.

✎4. 단계별 실습

HTML · 기존 컨트롤 문구와 상태 보강

game-dev-portfolio/index.html

<button type="button" data-action="open-project" data-project-id="parcel-rush">
  Parcel Rush 상세 보기
</button>
<p id="projectStatus" class="status" aria-live="polite">3개 프로젝트 표시 중</p>

CSS · 파일 경로: css/style.css

game-dev-portfolio/css/style.css

:focus-visible { outline: 3px solid var(--color-accent); outline-offset: 4px; }
button, a { min-height: 44px; }
button { cursor: pointer; }
@media (forced-colors: active) {
  .project-card { border: 1px solid CanvasText; }
}

수동 점검 순서

1. 주소창에서 Tab을 눌러 본문 바로가기부터 이동합니다.
2. 메뉴, 필터, 상세 버튼, 모달 닫기, 테마와 폼을 Enter·Space·Escape로 조작합니다.
3. 모든 초점 위치가 보이고 모달 뒤 초점이 돌아오는지 확인합니다.
4. 이미지 끄기 또는 경로 누락에서 대체 텍스트를 확인합니다.

개발자 도구 확인: Accessibility 트리에서 버튼 이름, 상태와 랜드마크를 확인합니다. 자동 검사는 보조 수단이며 키보드 수동 흐름을 대신하지 않습니다.

→5. 코드가 동작하는 이유

브라우저가 링크·버튼·폼의 키보드 행동과 역할을 기본 제공하므로 별도 키 이벤트가 줄어듭니다. 구체적인 버튼 텍스트와 aria-live는 현재 행동과 결과를 전달합니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 버튼처럼 꾸민 div: 실제 button을 사용합니다.
• outline 제거: 대체 초점 표시 없이 제거하지 않습니다.
• 모든 이미지에 같은 alt: 이미지의 정보 목적을 설명합니다.
• tabindex="1"로 순서 조작: 의미 있는 DOM 순서를 먼저 고칩니다.

✎7. 직접 실습

✎직접 실습

마우스를 사용하지 않고 홈부터 폼까지 이동하세요. 막힌 지점, 보이지 않는 초점, 모호한 이름을 각각 찾아 수정하고 전후를 기록합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 시맨틱 버튼이 사용자 정의 div보다 안전한 이유는 무엇인가요?
2. 같은 ‘보기’ 버튼이 여러 개면 어떤 문제가 생기나요?
3. 자동 접근성 검사만으로 충분하지 않은 이유는 무엇인가요?

■9. 핵심 요약

■핵심 요약

의미 있는 HTML, 자연스러운 DOM 순서, 보이는 초점과 명확한 이름이 접근성의 기반입니다. 실제 키보드 흐름으로 확인합니다.