접근성 높은 웹 버튼을 위한 짧고 분명한 체크리스트

버튼 접근성 조언의 문제

대부분의 버튼 접근성 가이드는 두 부류로 나뉩니다. 아무도 읽지 않는 40쪽짜리 WCAG 해설이거나, 실행 가능한 단계 없이 "버튼을 접근성 있게 만들라"는 모호한 제안입니다. 목요일에 기능을 배포해야 할 때는 둘 다 도움이 되지 않습니다.

이 체크리스트는 프로덕션에서 흔히 보이는 버튼 접근성 실패 다섯 가지를 다룹니다. 이 목록만으로 WCAG 전문가가 될 수는 없지만, 실제로 사용자에게 영향을 주는 문제는 잡아낼 수 있습니다.

1. 버튼에는 button 요소를 사용하세요

버튼처럼 동작한다면 <button> 요소여야 합니다. onclick이 달린 <div>도 아니고, role="button"이 있는 <span>도 아니며, href="#"와 preventDefault를 사용하는 <a>도 아닙니다.

<button> 요소는 키보드 탐색, 포커스 관리, 스크린 리더 안내를 기본으로 제공합니다. <div>를 사용하면 이 모든 것을 처음부터 다시 만드는 셈입니다. 그리고 결국 어딘가에서 틀리게 됩니다.

유일한 예외: 동작이 새 페이지로 이동하거나 URL을 변경한다면 <a> 요소를 사용하세요. 링크와 버튼은 의미적으로 다릅니다. 스크린 리더 사용자는 요소 유형별로 탐색하며, 버튼은 동작을 수행하고 링크는 이동한다고 기대합니다.

2. 히트 타깃은 최소 44×44픽셀로 만드세요

WCAG 2.5.5(Level AAA)는 인터랙티브 요소의 최소 타깃 크기를 44×44 CSS 픽셀로 요구합니다. 이는 시각적 크기에 관한 것이 아니라 클릭 가능한 영역에 관한 것입니다.

시각적으로 작은 버튼에 충분한 패딩을 줄 수도 있고, 의사 요소로 히트 타깃을 확장할 수도 있습니다. 중요한 것은 사용자가 정밀하게 조준하지 않아도 된다는 점입니다.

모바일 사용자, 운동 기능에 제약이 있는 사람, 움직이는 환경에서 기기를 사용하는 사람은 작은 타깃을 놓치기 쉽습니다. 24×24픽셀 아이콘 버튼은 깔끔해 보일 수 있지만, 사용성 측면에서는 실패입니다.

3. 브라우저 기본값에만 의존하지 않는 보이는 포커스 상태를 제공하세요

브라우저 기본 포커스 링은 없는 것보다 낫지만, 브라우저마다 일관되지 않고 특정 배경에서는 보이지 않는 경우가 많습니다. 디자인 시스템 안에서 제대로 동작하는 사용자 정의 포커스 상태가 필요합니다.

좋은 포커스 표시기는 세 가지 특성을 가집니다.

• 높은 대비: 인접한 색상과 최소 3:1
• 보이는 오프셋: 버튼 자체의 테두리나 배경에 가려지지 않음
• 일관된 형태: 사용자가 인터페이스 전반에서 포커스 표시기로 인식할 수 있음

더 나은 대체 수단 없이 outline: none을 적용하지 마세요. 그리고 완벽한 조명 조건에서 당신에게만 보일 정도로 포커스 상태를 미묘하게 만들지 마세요.

4. 문맥 없이도 의미가 통하는 버튼 레이블을 작성하세요

스크린 리더 사용자는 버튼 사이를 건너뛰며 탐색하는 경우가 많습니다. 그때 주변 문맥 없이 버튼 레이블 목록을 듣게 됩니다.

그 목록에서 "자세히 알아보기"라는 버튼은 쓸모가 없습니다. "여기를 클릭"이나 "제출"도 마찬가지입니다. 레이블은 동작을 설명해야 합니다. 예를 들어 "접근성 체크리스트 다운로드", "업데이트 구독", "이 댓글 삭제"처럼 작성하세요.

디자인상 짧은 시각적 레이블이 필요하다면 aria-label을 사용해 설명적인 대안을 제공하세요. 하지만 더 나은 해결책은 모두에게 통하는 레이블을 쓰는 것입니다.

아이콘만 있는 버튼에는 aria-label이 필수입니다. 돋보기 아이콘만 있는 버튼에는 aria-label="Search" 또는 이에 준하는 텍스트가 필요합니다. 아이콘은 스크린 리더에 접근 가능하지 않습니다.

5. 충분한 색상 대비를 보장하세요

WCAG 2.1은 일반 텍스트에 최소 4.5:1, 큰 텍스트(18pt 또는 14pt 굵게)에 3:1 이상의 대비율을 요구합니다. 버튼 레이블은 대개 일반 텍스트입니다.

흰색 버튼 위의 밝은 회색 텍스트는 실패입니다. 연한 파란색 배경 위의 옅은 파란색도 실패입니다. 이런 조합은 세련되어 보일 수 있지만, 저시력 사용자, 색각 이상이 있는 사용자, 밝은 햇빛 아래에서 화면을 보는 모든 사용자를 배제합니다.

대비 검사기는 출시 후가 아니라 디자인 중에 사용하세요. 프로덕션에서 대비 문제를 고치는 일은 비용이 큽니다. 디자인 시스템 변경이 필요한 경우가 많기 때문입니다.

이미지 처리 도구를 다루고 있다면, 클라이언트 측 처리는 접근 가능한 시각 자산을 생성하면서 개인정보 보호에 도움이 될 수 있습니다. 특히 색상 조합을 테스트하거나 미리보기 상태를 생성할 때 유용합니다.

이 체크리스트가 다루지 않는 것

이 목록은 의도적으로 불완전합니다. 비활성 상태의 의미론, 로딩 상태, 오류 처리, 분할 버튼이나 드롭다운 트리거 같은 복잡한 버튼 패턴은 다루지 않습니다. 그런 패턴에는 별도의 지침이 필요합니다.

또한 버튼을 언제 다른 인터랙티브 요소 대신 사용해야 하는지에 대한 더 넓은 질문도 다루지 않습니다. 이를 위해서는 semantic HTML과 accessibility tree를 이해해야 하며, 이 주제들은 각각 별도의 글이 필요합니다.

이 체크리스트가 다루는 것은 손쉽게 고칠 수 있는 문제들입니다. 거의 모든 코드 리뷰에서 나타나고, 가장 많은 사용자에게 영향을 주며, 개발 중에 가장 쉽게 수정할 수 있는 실수들입니다.

워크플로에 통합하는 방법

접근성 체크리스트는 나중에 덧붙이는 것이 아니라 개발 프로세스의 일부일 때만 효과가 있습니다. 이를 실현하는 방법은 다음과 같습니다.

디자인에서: 디자인 파일에 포커스 상태와 히트 타깃 주석을 추가하세요. 개발자가 추측하게 두지 마세요.

코드 리뷰에서: <button> 요소, 아이콘 버튼의 aria-label, 포커스 상태 CSS를 확인하세요. 빠르게 찾아볼 수 있는 항목들입니다.

테스트에서: 키보드로 인터페이스를 탭 이동해 보세요. 버튼에 도달할 수 없거나 포커스가 어디 있는지 볼 수 없다면, 사용자도 마찬가지입니다.

문서에서: 컴포넌트 라이브러리에 버튼 접근성 요구사항을 포함하세요. 잘못된 일을 하는 것보다 올바른 일을 하는 것이 더 쉽도록 만드세요.

프로덕션 문제를 디버깅하고 있다면, HTTP 헤더와 리디렉션을 검사하는 도구가 보조 기술이 마크업을 어떻게 해석하는지 이해하는 데 도움이 될 수 있습니다. 특히 탐색 후 포커스 관리를 문제 해결할 때 유용합니다.

이 작업을 건너뛰는 비용

접근성 없는 버튼은 WCAG 준수에 실패하는 데 그치지 않습니다. 워크플로 자체를 깨뜨립니다. 제출 버튼을 클릭할 수 없는 사용자는 양식을 완료할 수 없습니다. 포커스 상태를 볼 수 없는 사용자는 키보드로 탐색할 수 없습니다. 버튼 텍스트와 배경을 구분할 수 없는 사용자는 레이블을 읽을 수 없습니다.

이는 예외적인 사례가 아닙니다. 전 세계 인구의 약 15%는 어떤 형태로든 장애가 있으며, 일시적인 제약(고장 난 마우스, 밝은 햇빛, 아기를 안고 있음)은 결국 누구에게나 영향을 줍니다.

다행히 버튼 접근성은 대부분 이미 해결된 문제입니다. 새로운 패턴을 발명하거나 브라우저 지원을 기다릴 필요가 없습니다. 플랫폼을 올바르게 사용하고 작업물을 테스트하기만 하면 됩니다.

핵심 요약

• 버튼에는 <button> 요소를, 탐색에는 <a> 요소를 사용하세요. 이 의미적 차이는 보조 기술에 중요합니다
• 운동 기능 제약이 있는 사용자와 모바일 사용자를 고려해 히트 타깃을 최소 44×44 CSS 픽셀로 보장하세요
• 디자인 시스템 전반에서 동작하는, 보이고 대비가 높은 포커스 상태를 제공하세요
• 단독으로 읽혀도 의미가 통하는 버튼 레이블을 작성하고, 아이콘만 있는 버튼에는 aria-label을 사용하세요
• 비용이 큰 사후 수정을 피하려면 출시 후가 아니라 디자인 중에 색상 대비를 확인하세요

FAQ

Q: 키보드 핸들러를 추가한다면 <div>에 role="button"을 사용해도 되나요?

A: 할 수는 있지만 권장하지 않습니다. Enter, Space, 포커스 관리, 비활성 상태를 모두 수동으로 처리해야 하며, 결국 무엇인가를 놓치게 됩니다. <button> 요소는 이 모든 것을 기본적으로 올바르게 처리합니다. 사용하세요.

Q: 재생/일시정지 버튼처럼 상태를 전환하는 버튼은 어떻게 해야 하나요?

A: 현재 상태를 나타내기 위해 aria-pressed="true" 또는 aria-pressed="false"를 사용하세요. 버튼 레이블도 현재 상태가 아니라 클릭하면 일어날 동작을 반영해야 합니다(재생 중이면 "일시정지", 일시정지 중이면 "재생"). 스크린 리더 사용자는 시스템이 어떤 상태인지가 아니라 버튼이 무엇을 할지 알아야 합니다.

Q: 비활성 버튼도 대비 요구사항을 충족해야 하나요?

A: WCAG 2.1은 비활성 컨트롤을 대비 요구사항(1.4.3)에서 제외하지만, 이는 논쟁적인 부분입니다. 대비가 낮은 비활성 버튼은 누구에게나 인지하기 어렵습니다. 비활성 버튼을 보여주려면 읽을 수 있게 만드세요. 더 나은 방법은 숨기거나 왜 비활성인지 설명하는 것입니다.

Q: 스크린 리더 없이 버튼 접근성을 어떻게 테스트하나요?

A: 키보드를 사용하세요. 인터페이스를 탭으로 이동하며 모든 버튼에 도달할 수 있는지, 포커스가 어디 있는지 볼 수 있는지, Enter 또는 Space로 버튼을 활성화할 수 있는지 확인하세요. 이것만으로도 대부분의 문제를 잡을 수 있습니다. 더 깊이 테스트하려면 Chrome 또는 Firefox DevTools의 접근성 검사기를 사용해 계산된 역할과 레이블을 확인하세요.

Q: aria-label과 aria-labelledby의 차이는 무엇인가요?

A: aria-label은 텍스트 문자열을 직접 제공합니다. aria-labelledby는 다른 요소의 ID를 참조하며, 그 요소의 텍스트 콘텐츠가 레이블이 됩니다. 레이블 텍스트가 이미 DOM의 다른 곳에 존재할 때는 aria-labelledby를 사용하세요. 화면에 보이지 않는 레이블을 제공해야 할 때는 aria-label을 사용하세요.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM