GitHub은 더 이상 Toasts를 사용하지 않음
(primer.style)- Toast 알림 UI는 접근성 문제로 인해 GitHub에서 더 이상 권장되지 않음
- 자동으로 사라지는 일시적 알림 구조가 시각적·기능적 접근성 기준(WCAG)을 위반할 위험 존재
- GitHub은 배너(banner) , 다이얼로그(dialog) 등 지속적이고 접근 가능한 피드백 방식을 대안으로 제시
- Toast는 큰 화면, 멀티태스킹, 배너 무시 현상 등 사용성 문제도 다수 포함
- 접근성과 일관된 사용자 경험을 위해 Primer 디자인 시스템 전반에서 Toast 사용 중단
Toasts 개요
- Toast는 화면 하단 모서리에 잠시 나타나는 작은 직사각형 알림 창으로, 사용자 또는 시스템 동작에 의해 트리거됨
- 일정 시간이 지나면 자동으로 사라지는 구조로, 접근성과 사용성 문제가 내재함
- GitHub은 이러한 이유로 보다 안정적이고 접근 가능한 커뮤니케이션 방식을 권장함
Toast 대체 방안
- 사용 목적에 따라 적절한 UI 선택 필요
- 단순 성공 알림은 별도 피드백 없이 결과 화면 자체로 확인 가능
- 복잡한 작업은 배너나 점진적 콘텐츠 표시로 성공 상태 전달
- 실패한 작업은 배너 또는 다이얼로그를 통해 오류 정보 제공
- 폼 제출의 경우 단순 폼은 별도 확인 불필요, 복잡한 폼은 중간 확인 페이지나 배너 사용
- 입력 검증은 Primer의 기존 폼 검증 컴포넌트 활용
- 장시간 작업은 배너 또는 이메일·푸시 알림 등 다른 채널을 통해 완료 상태 전달
- 세션 비동기화 발생 시 다이얼로그나 배너로 새로고침 필요성 안내
접근성 고려사항 (Accessibility Considerations)
- Toast UI는 여러 WCAG 성공 기준을 위반할 가능성 있음
- 2.2.1 Timing Adjustable (A) : 사용자가 직접 닫기 전까지 유지되어야 함
- 1.3.2 Meaningful Sequence (A) : DOM 순서와 시각적 순서 불일치로 보조기술 사용 시 혼란 발생
- 2.1.1 Keyboard (A) : 키보드로 토스트 내 인터랙션 제어 가능해야 함
- 4.1.3 Status Messages (AA) : 보조기술에 비방해적으로 존재를 알려야 함
- 추가로 위반 가능성이 있는 기준
- 1.4.4 Resize text (AA) : 텍스트 크기 조정 시 화면 가림 또는 오버플로 발생 위험
- 1.4.10 Reflow (AA) : 수평 스크롤 시 키보드 접근성 확보 필요
- 2.4.3 Focus Order (A) : 포커스 순서 혼란 가능성
- 3.2.4 Consistent Identification (AA) : 코드 일관성 유지 필요
사용성 고려사항 (Usability Considerations)
- 대형 화면에서는 토스트가 시야 밖에 위치해 인식되지 않을 수 있음
- 자동 해제 시 사용자가 다른 작업 중이면 메시지를 놓칠 위험 존재
- UI 가림 현상: 토스트가 하단 버튼 등 중요한 요소를 덮을 수 있음
- 화면 확대 사용자는 확대 영역 밖의 토스트를 보지 못할 수 있음
- 작업 기억 문제: 자동 사라짐으로 정보 재확인 불가
- 배너 무시 현상: 과도한 사용으로 사용자가 무시하는 경향
- 위치 불일치: 트리거된 UI와 토스트의 물리적 거리로 인한 연관성 혼란
- 잘못된 닫기 동작: Esc 키로 다른 UI까지 함께 닫히는 문제 발생 가능
추가 참고 자료
Hacker News 의견들
- 접근성에 대해 강의하면서 클릭 후 3초 지연이 생겨 아무 반응이 없는 것처럼 느껴지는 상황을 겪었음
- 배너를 클릭하면 아무 표시도 없이 기다리게 되고, 나중에 관련 없는 페이지로 이동하는 식이라 답답했음
- 로딩 중임을 알려주는 피드백 부재가 문제라고 생각함
- 어떤 이는 그건 단순한 `` 링크라며, 페이지가 불필요하게 커서 생기는 지연일 뿐이라고 말함
- 또 다른 사람은 느린 4G에서도 즉시 반응한다며, 브라우저나 네트워크 문제일 가능성을 제기함
-
GitHub Primer 문서를 흥미롭게 읽었음
- 모든 내용에 동의하지 않아도 배울 점이 있고, 감으로 하는 것보다 훨씬 낫다고 느낌
- 참고로 Apple과 Android도 각각 디자인 가이드라인을 제공하고 있음
- 드디어 이런 트렌드가 확산되길 바람
- 토스트 알림 때문에 놓친 메시지가 너무 많았음
- 다른 사용자는 “토스트는 접근성 문제로 사용을 권장하지 않는다”는 문구에 전적으로 동의하며, 알림 센터가 있었다면 그나마 나았겠지만 여전히 나쁜 방식이라고 강조함
- 나는 토스트를 비방해적 확인용으로는 좋아하지만, 중요한 정보를 전달하는 용도로는 부적절하다고 생각함
- 다른 사람은 토스트의 사용 맥락을 구체적으로 나눠 설명함
- 버튼 클릭 즉시 반응 → 버튼 자체에서 피드백을 주는 게 낫고
- 단축키 반응 → 괜찮음
- 오래 걸리는 작업 완료 알림 → 괜찮지만 지속적인 알림함이 필요함
- 페이지 진입 시 경고 표시 → 중요하다면 페이지 내에 영구적 알림으로 보여야 함
- React에서 전역
toast()호출이 쉬워 남용되는 경향이 있지만,useAlerts()같은 구조로 바꾸는 게 훨씬 낫다고 제안함
- 다른 사람은 토스트의 사용 맥락을 구체적으로 나눠 설명함
- 토스트는 내게 지혈대 같은 존재임
- 급한 문제를 임시로 막는 데 유용하지만, 장기적으로 유지하면 안 됨
- 새 프로젝트에서 피드백이 부족할 때 임시로 붙였다가, UI를 개선하면서 하나씩 제거하는 식으로 써야 함
- GitHub처럼 큰 조직은 이런 임시방편이 필요 없지만, 작은 팀은 다를 수 있음
- GitHub 문서에서 말한 “대량 Issue 생성 시 추가 피드백이 필요하다”는 부분이 마음에 듦
- GitHub Actions에서도 이런 피드백이 있으면 좋겠음, 실행 후 결과가 나타나기까지 너무 오래 걸림
- UI 전반의 행동 로그로 토스트를 활용하는 아이디어가 마음에 듦
- 클릭할 때마다 사라지는 피드백 대신, Sonner처럼 잘 구현된 예시가 있음
- 브라우저 차원에서 토스트의 네이티브 지원을 고려할 때가 된 것 같음
- 타이밍 조절, 알림 센터, 스크린 리더 통합 등 접근성 개선이 가능할 것 같음
- 시각적으로는 괜찮지만, 너무 빨리 사라져 놓치는 경우가 많음
- 시각장애인이 겪는 문제를 직접 이해하긴 어렵지만, 그들의 접근성을 높이는 방법을 듣고 싶음
- 토스트의 장점은 구현이 쉽고 디자인 부담이 적음임
- 단점은 놓치기 쉽고, 다른 정보 위에 겹칠 위험이 있음
- 여유가 있다면 토스트를 모두 없애는 게 낫다고 생각함
- 다른 사람은 “쉽게 만들 수 있어서 문제 해결을 가장한 미봉책으로 남용된다”고 지적함
- 또 다른 사람은 토스트를 단순한 안심용 피드백으로 사용했다고 함
- 반면 어떤 이는 “토스트는 저중요 이벤트에 즉각적 피드백을 주는 유용한 도구”라며, 모달창이나 고정 영역보다 효율적이라고 주장함
- 도구의 남용을 이유로 완전히 배제하는 흑백논리를 비판함
- “GitHub의 토스트 제거가 접근성에 나쁜 소식”이라는 글을 봤음
- 어떤 이는 그 주장이 이상하다고 느낌
- GitHub이 토스트를 없앤 대신 W3C를 통해 브라우저 표준을 만들었어야 한다는 건 비약이라고 생각함
- 이미 생성된 아이템이 리스트에 나타나는 것만으로도 충분한 피드백이라고 봄
- 또 다른 사람은 “토스트가 접근성과 UX에 나쁘다고 하면서, GitHub이 그것을 브라우저에 표준화하지 않았다고 비판하는 건 모순”이라고 말함
- 어떤 이는 그 주장이 이상하다고 느낌