Toggle button VS A11y

배경 및 소개

최근 기업용 SaaS 플랫폼에서 디자인 시스템을 구축하는 과정에서 접근성(a11y) 해석이 화제입니다. 특히 WCAG 지침을 실제 컴포넌트 설계에 어떻게 적용할지, 그리고 팀 안에서 흔히 퍼지는 접근성 관련 오해를 어떻게 정리할지가 중요한 맥락인데요. 질문의 핵심은 토글 버튼(toggle button)의 레이블을 상태에 맞게 바꿔도 되는지에 관한 논쟁입니다. 예를 들어 음소거 버튼이 눌리면 “Unmute”, 다시 해제되면 “Mute”로 바뀌는 방식이 과연 허용되는지 묻고 있습니다. 이는 단순한 문구 선택이 아니라, 버튼을 “상태를 가진 토글”로 볼 것인지 “행동을 실행하는 일반 버튼”으로 볼 것인지에 따라 설계 원칙이 달라진다는 점에서 의미가 있습니다.

주요 내용

질문자 팀은 WAI-ARIA APG의 버튼 패턴을 참고하고 있는데요, 문서 안에는 “토글의 레이블은 상태가 바뀌어도 바뀌면 안 된다”는 문장과, 반대로 “디자인상 Mute가 Unmute로 바뀌는 것이 목적이라면 aria-pressed가 필요 없다”는 문장이 함께 있어 혼란이 생긴 상황입니다. 이 지점은 사실 문서가 모순된다기보다, 서로 다른 두 가지 패턴을 함께 읽으면서 생긴 혼선이라고 볼 수 있습니다. 즉 하나는 누름 상태가 있는 진짜 토글 버튼이고, 다른 하나는 클릭에 따라 행동 문구가 바뀌는 일반 버튼인데요. 이 둘을 같은 규칙으로 해석하면 레이블과 상태의 역할이 뒤섞이기 쉽습니다.

커뮤니티의 첫 번째 반응은 이 구분을 아주 명확하게 짚고 있습니다. 진짜 토글 버튼이라면 레이블은 안정적으로 유지되고, 현재 상태는 aria-pressed로 전달해야 한다는 설명인데요. 예를 들어 “Sound”라는 이름은 그대로 두고 On/Off 같은 상태를 바꾸는 방식입니다. 반면 “Mute”와 “Unmute”처럼 문구 자체가 바뀐다면, 그것은 상태 표시라기보다 수행할 행동을 설명하는 버튼에 가깝다고 해석할 수 있습니다. 이는 버튼의 이름과 상태를 분리해야 접근성이 훨씬 선명해진다는 점에서 흥미롭습니다. 사용자는 무엇을 누르는지와 현재 무엇이 켜져 있는지를 다른 정보로 받아야 하기 때문입니다.

또 다른 댓글은 질문에서 말한 “레이블”이 사실은 “상태”에 더 가깝다고 지적합니다. 즉 레이블은 모든 상태를 포괄하는 고정된 이름이고, Mute/Unmute는 그 안에서 변하는 개별 상태라는 설명인데요. 이 관점에서는 “Sound”나 “Volume control”처럼 고정된 이름을 두고, 옆에 별도의 상태 표시로 On/Off 또는 Muted/Unmuted를 전달하는 편이 더 명확합니다. 개인적으로도 이 방식이 훨씬 실무적이라고 생각하는데요. 사용자에게는 버튼의 정체성과 현재 결과가 분리되어 전달되므로, 스크린 리더나 시각적 사용성 모두에서 해석 부담이 줄어듭니다. 이는 디자인 시스템 관점에서도 컴포넌트의 문구 규칙을 일관되게 유지할 수 있다는 점에서 유리합니다.

다만 댓글 중에는 문서 표현이 다소 애매하게 쓰였다고 보는 의견도 있습니다. “Alternatively”라는 표현이 있는 만큼 둘 다 허용되는 것처럼 읽힐 수 있다는 건데요. 실제로 많은 팀이 토글 위에 추가 상태 텍스트를 붙이거나, 공간이 허용되면 상태 표시기를 함께 두는 방식으로 문제를 해결합니다. 여기서 중요한 점은 웹 토글 자체가 표준 HTML 요소로 존재하지 않는 경우가 많아, 프레임워크나 개발자가 checkbox 등을 바탕으로 직접 구현해야 한다는 사실입니다. 그래서 native 동작에 기대기 어렵고, 포커스 처리나 스크린 리더 읽기 순서, 실제 상태 동기화까지 꼼꼼히 확인해야 한다는 점이 중요합니다. 이는 “보이는 UI”보다 “전달되는 의미”가 더 중요해지는 접근성 설계의 본질을 보여준다고 볼 수 있습니다.

결론 및 시사점

정리하면, 이 논쟁의 핵심은 토글 버튼의 레이블 변경이 허용되느냐보다도, 지금 구현하려는 것이 정말 토글인지 아니면 상태를 바꾸는 일반 버튼인지 구분하는 데 있습니다. 레이블이 상태를 직접 말하는 구조라면 Mute/Unmute처럼 문구가 바뀔 수 있지만, 그 경우에는 aria-pressed 기반의 토글 패턴과는 다른 해석이 필요합니다. 반대로 진짜 토글이라면 고정된 이름을 유지하고 상태는 별도의 속성이나 표시로 전달하는 편이 더 명확합니다. 이는 접근성에서 “무엇을 말하느냐”와 “어떤 상태냐”를 섞지 않는 것이 핵심이라는 점에서 의미가 있습니다.

실무적으로는 디자인 시스템에서 이 두 패턴을 아예 분리해 정의하는 것이 좋습니다. 토글 버튼은 레이블 고정 + 상태 표시, 행동 버튼은 문구 변경 가능이라는 식으로 규칙을 나누면 팀 내 해석 차이를 줄일 수 있습니다. 다만 실제 구현에서는 시각적 레이블만 보지 말고 스크린 리더가 어떤 이름과 상태를 읽는지까지 함께 검증해야 합니다. 접근성은 문서 해석만으로 끝나지 않고 실제 상호작용에서 완성되기 때문에, QA 단계에서 반드시 사용자 맥락 기준으로 다시 확인하는 과정이 필요합니다.