Popover API - 브라우저 네이티브 툴팁의 새로운 가능성

• 기존 툴팁 구현에서 필수였던 JavaScript 이벤트 리스너, 상태 관리, ARIA 속성 수동 동기화를 Popover API가 브라우저 네이티브 기능으로 대체
• popover 속성과 popovertarget 속성만으로 열기/닫기, Esc 키 처리, 키보드 내비게이션이 자동 동작
• 스크린 리더 예측 가능성 향상, aria-expanded 자동 동기화, 포커스 복원 등 접근성 관련 버그 범주 자체가 제거
• 타이밍 제어, 호버 인텐트 판별 등 일부 영역에서는 여전히 JavaScript 필요하나, 핵심 상호작용 모델은 브라우저가 담당
• 대규모 디자인 시스템이나 복잡한 포지셔닝이 필요한 경우 라이브러리가 여전히 유효하지만, 기본값이 네이티브 API로 전환 중

---

기존 툴팁의 문제점

• Popover API 이전에는 브라우저에 마우스, 키보드, 보조 기술 전반에서 동작하는 네이티브 툴팁 개념이 부재
• 트리거 요소, 숨겨진 툴팁 요소, 둘을 조율하는 JavaScript라는 동일한 패턴의 반복
• 표면적으로 단순하지만, 실제 사용자에게 배포하면 다양한 문제 노출
  • 키보드 사용자가 Tab으로 트리거에 진입해도 툴팁이 표시되지 않음
  • 스크린 리더가 두 번 읽거나 아예 읽지 않음
  • 마우스를 빠르게 움직이면 깜빡임(flicker) 발생
  • 작은 화면에서 콘텐츠 겹침
  • Esc 키로 닫히지 않음, 포커스 유실
• 시간이 지날수록 이벤트 리스너 누적, hover/focus 별도 처리, 외부 클릭 특수 케이스, ARIA 속성 수동 동기화 등 코드가 비대해짐

라이브러리를 사용한 이유

• 라이브러리는 포지셔닝, 뷰포트 경계에서의 플리핑, 입력 유형별 이벤트 조율, 복잡한 레이아웃 내 스크롤 인식 등 실질적 작업 수행
• 포지셔닝만으로도 의존성이 정당화될 정도로 스크롤 컨테이너, 트랜스폼, 반응형 레이아웃 처리가 복잡
• 진짜 문제는 접근성 동작에서 발생
  • 툴팁이 늦게 나타나거나 아예 나타나지 않음
  • 빠른 탭 이동 시 툴팁 건너뜀
  • Esc 해제가 불안정
• 마우스 사용자는 즉시성, 키보드 사용자는 예측 가능성을 기대하여 둘 다 지원하면 지연과 엣지 케이스 발생
• 스크린 리더에서 툴팁이 읽히거나, 안 읽히거나, 두 번 읽히는 등 비일관적 동작
• ARIA 속성 수동 업데이트에서 하나라도 놓치면 접근성 트리에서 혼란 또는 비가시 상태 발생

코드 자체의 문제가 아닌 플랫폼의 한계

• 구현은 테스트되었고 라이브러리도 견고했으나, 핵심 문제는 웹 플랫폼에 적절한 어포던스가 부재했다는 점
• 브라우저가 해당 요소가 툴팁임을 인식할 방법이 없었으며, 모든 것이 범용 요소, 이벤트 리스너, 수동 ARIA, 커스텀 해제 로직 등 관례(convention) 기반
• 시간이 지나면 작은 변경이 리스크를 수반하고, 사소한 수정이 회귀를 유발하는 취약한 구조
• 새로운 툴팁 추가 시 동일한 복잡성이 그대로 상속

Popover API 첫 적용

• 새로운 실험이 아닌, 브라우저가 이미 이해해야 할 툴팁 동작 유지보수에 지친 것이 전환 동기
• 가장 작은 형태로 시도: <button popovertarget="tip-1"> + <div id="tip-1" popover="manual" role="tooltip">
• 이벤트 리스너 없음, 상태 추적 없음, JavaScript에서 ARIA 업데이트 없음
• 버튼에 포커스하면 툴팁 표시, Esc 누르면 사라짐

즉시 느낀 차이점

• JavaScript 없이 열기/닫기: 브라우저가 HTML만으로 호출 처리, 트리거와 툴팁 간 관계가 명시적
• Esc 키 자동 동작: 키 리스너 추가 없이 브라우저가 popover 해제 가능성을 자체 이해
• ARIA 상태 자동 동기화: aria-expanded 속성이 popover 열림/닫힘 시 자동 업데이트, 수동 관리 불필요, 오래된 상태 위험 제거
• 코드 감소보다 더 중요한 것은 책임의 전환: 이전에는 JavaScript가 "존재시킨" 툴팁이, 이제는 브라우저가 마크업에서의 역할을 이해하고 포커스 모델, 접근성 트리, 네이티브 해제 규칙에 참여

Invoker Commands 이해

• popovertarget="id"는 버튼을 popover 요소에 연결
• popovertargetaction으로 동작 지정
  • show: 열기만
  • hide: 닫기만
  • toggle(기본값): 열려 있으면 닫고, 닫혀 있으면 열기
• 동일 툴팁에 대해 여러 트리거를 가질 수 있으며, 기본 상호작용에 JavaScript 불필요

접근성 관련 무료 이득

• 키보드 "그냥 동작"

  • 이전에는 포커스가 트리거해야 하고, 블러가 숨겨야 하고, Esc를 수동 연결해야 하며, 타이밍까지 맞아야 하는 다층 구조
  • popover 속성(auto 또는 manual) 설정 시 브라우저가 기본 처리: Tab/Shift+Tab 정상 동작, Esc가 매번 확실히 닫힘
  • 코드베이스에서 전역 keydown 핸들러, Esc 전용 정리 로직, 키보드 내비게이션 중 상태 검사 등이 제거

• 스크린 리더 예측 가능성

  • 가장 큰 개선 영역으로, 이전에는 신중한 ARIA 작업에도 동작이 달라지며 작은 변경이 위험했음
  • popover="manual" role="tooltip" 사용 시 훨씬 안정적이고 예측 가능한 동작
  • 전환 후 Lighthouse가 잘못된 ARIA 상태 경고를 더 이상 표시하지 않음 — 실수할 커스텀 ARIA 상태 자체가 없기 때문

• 포커스 관리

  • 이전에는 포커스 트리거 표시, 툴팁 내 포커스 이동 시 닫지 않기, 블러 처리, 포커스 수동 복원 등 복잡한 규칙
  • Popover API에서는 포커스가 popover로 자연스럽게 이동하고, 닫으면 트리거로 포커스 자동 복원
  • 포커스 복원 코드를 추가한 것이 아니라 제거

Popover API가 아직 부족한 영역

• 툴팁 타이밍

  • 네이티브 popover는 즉시 열리고 닫히는데, 마우스를 약간만 빠르게 움직이거나 트리거를 스치면 툴팁이 깜빡이며 불안정하게 느껴질 수 있음
  • hover/focus와 열림 사이에 딜레이 제어가 여전히 필요
  • 기본 열기/닫기 동작은 브라우저와 HTML invoker commands가 담당하고, JavaScript는 포인터가 툴팁으로 이동하면 숨김 취소하는 등 의도적 동작 개선에만 사용
  • CSS에서도 이 영역을 탐색 중으로, interest/invoker 관련 작업이 진입/퇴장 딜레이를 CSS로 직접 표현할 수 있는 방향으로 진행 중

• 호버 인텐트와 Invoker Commands

  • 브라우저는 누군가가 요소 위에 호버한 이유를 알 수 없음 — 의도적인지, 포인터가 지나가는 중인지 판단 불가
  • Invoker commands가 핵심 열기/닫기를 처리하므로, JavaScript는 더 이상 상호작용 모델을 소유하지 않고 그 위에 인텐트만 추가
  • 숨김 전 짧은 딜레이, 포인터가 툴팁으로 이동 시 해제 취소 같은 브라우저가 추론할 수 없는 동작에만 JavaScript 사용

• Manual Popover와 포커스

  • popover="manual"에서는 auto popover와 달리 브라우저가 포커스를 자동 복원하지 않음
  • 툴팁이 포커스로 열리고 블러로 닫힐 때, 트리거로 포커스를 명시적으로 반환해야 함
  • 플랫폼 동작과 사용자 의도 사이의 명확한 경계

• 솔직한 평가

  • Popover API가 툴팁을 마법처럼 해결하지는 않으나, 취약한 인프라를 재구축하는 작업을 중단시킴
  • 여전히 JavaScript를 쓰고 엣지 케이스를 고려하지만, UI 프리미티브 재생산 대신 제품 문제 해결에 집중 가능

여전히 툴팁 라이브러리가 필요한 경우

• 대규모 또는 성숙한 디자인 시스템

  • 여러 팀이 사용하는 대규모 디자인 시스템에서는 중앙화된 동작, 문서화된 패턴, 일관된 기본값을 위해 라이브러리가 합리적
  • 기저 상호작용 모델 변경은 기술적 결정일 뿐 아니라 조직적 결정
  • 접근성 뉘앙스에 익숙하지 않은 팀원에게 가드레일 제공

• 복잡한 포지셔닝 요구사항

  • 중첩 스크롤 컨테이너 간 충돌 감지, 커스텀 플리핑 로직, 오프셋/경계 미세 제어가 필요하면 Floating UI 같은 라이브러리가 여전히 유리
  • CSS anchor positioning이 이 문제의 상당 부분을 커버하기 시작 — 순수 CSS로 트리거 기준 상대 배치, 뷰포트 인식 배치, 엣지 플리핑 가능
  • 아직 신규 기능이며 알려진 이슈가 있으나 Interop에 포함되어 완전하고 일관된 브라우저 지원 전망
  • 현재 일관된 크로스 브라우저 동작이 필요하면 라이브러리가 실용적 선택

• 접근성 경험이 부족한 팀

  • 접근성 지식이 부족한 팀에서 좋은 라이브러리는 안전망 역할 — 완벽한 접근성을 보장하지는 않지만 흔한 실수 방지
  • Popover API가 더 나은 기본값을 제공하지만, role, 레이블, 포커스 관리, 테스트를 언제 추가할지 아는 것은 여전히 필요
  • 이해 없이는 네이티브 도구도 오용 가능

결론

• Popover API로 인해 툴팁은 더 이상 시뮬레이션하는 것이 아닌, 브라우저가 이해하는 요소
• 열기, 닫기, 키보드 동작, Esc 처리, 접근성의 상당 부분이 플랫폼 자체에서 제공
• 복잡한 디자인 시스템, 고도의 커스터마이징, 레거시 제약에서는 라이브러리가 여전히 유효하나, 기본값이 전환
• 가장 단순한 툴팁이 동시에 가장 정확한 툴팁이 될 수 있는 첫 번째 시점
• 제품 내 하나의 툴팁만 Popover API로 교체해 보면, 코드에서 무엇이 사라지는지 확인 가능