popover·앵커 포지셔닝·dialog, 접근성 관점에서 지금 써도 될까

새 기능을 도입할 때 우리가 보는 건 대개 지원표입니다. caniuse에 들어가서 초록색 칸이 몇 퍼센트인지 확인하고, 90%를 넘으면 “이제 써도 되겠네” 하죠.

그런데 지원표가 답해주지 않는 질문이 하나 있습니다. 키보드로 쓸 수 있나? 스크린 리더가 제대로 읽나?

이 둘은 다른 문제입니다. 브라우저가 기능을 구현했다는 것과, 그 기능이 접근성까지 챙겨준다는 것 사이에는 생각보다 큰 간극이 있거든요. 어떤 기능은 예전에 손으로 짜던 접근성 코드를 통째로 대신해주고, 어떤 기능은 오히려 새로운 함정을 만듭니다.

이 글은 요즘 “이제 쓸 만하다"는 말이 도는 네 가지 기능을 그 관점에서 점검한 기록입니다. 2026년 8월 기준이고요.

네 기능 모두 직접 눌러볼 수 있는 데모 페이지를 만들어뒀습니다. 읽다가 “정말 그런가?” 싶은 대목이 나오면 체험 페이지를 열어 Tab 키로 확인해보세요 — 글로 읽는 것과 포커스가 엉뚱한 곳으로 튀는 걸 직접 보는 건 꽤 다릅니다.

이 글에서 짚는 것

• 지원표는 초록불인데 접근성은 직접 챙겨야 하는 기능들 — popover, 앵커 포지셔닝
• 예전에 손으로 짜던 걸 대신해주는 기능 — <dialog>
• 아직 조심할 게 남은 기능 — 뷰 트랜지션
• 각각에 대해 “그래서 뭘 직접 해야 하나”
• Baseline 등급 읽는 법과, 다른 기능을 스스로 확인하는 경로

popover — 모달이 아니라는 게 핵심

🔬 체험 데모 열기 — 팝오버를 열고 Tab을 눌러보면 이 절의 내용이 3초 만에 확인됩니다.

popover 속성은 툴팁·드롭다운·메뉴처럼 위에 떠야 하는 것을 위해 만들어졌습니다. 예전에는 z-index 전쟁을 벌이고 바깥 클릭 감지를 직접 붙여야 했는데, 이제 속성 하나면 됩니다.

<button popovertarget="menu">메뉴</button>
<div id="menu" popover>
  <a href="/settings">설정</a>
  <a href="/logout">로그아웃</a>
</div>

JavaScript가 한 줄도 없습니다. 버튼을 누르면 열리고, 바깥을 클릭하거나 Esc를 누르면 닫힙니다. 항상 최상위 레이어에 뜨니 z-index를 고민할 일도 없고요. 지원도 넉넉합니다 — 크롬·엣지·사파리·파이어폭스 전부 지원하고, 마지막까지 남아 있던 iOS 사파리가 18.3으로 합류하면서 2025년 1월에 Baseline ‘새로 사용 가능(newly available)’ 단계에 들어섰습니다. 다만 그 위 단계인 ‘널리 사용 가능(widely available)‘은 아직입니다 — 새로 사용 가능이 된 뒤 30개월이 지나야 붙는 딱지라서요.

여기까지만 보면 만능처럼 보이는데, 가장 중요한 사실은 이겁니다: popover는 모달이 아닙니다.

무슨 뜻이냐면, 팝오버가 열려 있어도 뒤쪽 콘텐츠가 그대로 살아 있습니다. 포커스가 갇히지 않아서 Tab을 계속 누르면 팝오버 밖으로 나가버리고, 배경도 여전히 클릭됩니다. 이게 결함이냐면 아닙니다 — 툴팁이나 알림처럼 “떠 있지만 방해하지 않아야 하는 것"에는 정확히 맞는 동작이거든요. 문제는 이걸 로그인 모달처럼 반드시 처리하고 넘어가야 하는 UI에 쓸 때입니다.

auto와 manual, 그리고 직접 해야 하는 것

popover는 값에 따라 성격이 갈립니다.

그리고 브라우저가 안 해주는 것들이 있습니다. 이 부분이 이 글의 핵심인데요.

• 역할(role)을 안 붙여줍니다. popover는 속성이지 요소가 아니라서 고유한 역할이 없습니다. 크롬·엣지·파이어폭스가 역할 없는 팝오버에 group을 폴백으로 넣어주긴 하는데(사파리는 그것도 안 합니다), 메뉴면 메뉴답게 대화상자면 대화상자답게 role을 직접 지정해야 스크린 리더가 성격을 압니다.
• 포커스를 안 옮겨줍니다. 팝오버가 열려도 포커스는 버튼에 그대로 있어요. 브라우저가 해주는 건 팝오버 내용을 버튼 바로 다음 탭 순서에 끼워주는 것, 그리고 Esc로 닫을 때 포커스를 버튼으로 되돌려주는 것까지입니다. 열자마자 안으로 들여보내고 싶다면 팝오버 안의 요소에 autofocus를 달아주세요. 명세에 “popover focusing steps"라는 절차가 있어서 브라우저가 이걸 보고 포커스를 옮겨줍니다.

<button popovertarget="menu">메뉴</button>
<div id="menu" popover role="menu">
  <a href="/settings" autofocus>설정</a>
  <a href="/logout">로그아웃</a>
</div>

반대로 aria-expanded는 이제 브라우저가 붙여줍니다. popovertarget으로 버튼과 팝오버를 묶어두면 크롬·엣지·파이어폭스·사파리 모두 버튼의 펼침/접힘 상태를 알아서 알려줘요. 그러니 손으로 aria-expanded="false"를 박아두면 오히려 손해입니다 — 열려도 값이 갱신되지 않아서 계속 “접힘"으로 읽히거든요.

둘이 형제 요소가 아닐 때 브라우저가 걸어주는 암묵적 aria-details 관계도 있습니다. 다만 이건 크롬·엣지·파이어폭스만 하고 사파리는 하지 않습니다. 게다가 스크린 리더가 그 관계를 실제로 읽어주느냐는 또 다른 문제라, JAWS·NVDA에서도 모드에 따라 들리기도 하고 안 들리기도 해요. 정리하면 — aria-expanded는 믿어도 되지만, 그 이상의 연결까지 자동으로 될 거라 기대하지는 마세요.

앵커 포지셔닝 — 눈과 손이 따로 노는 문제

🔬 체험 데모 열기 — 화면상 똑같은 두 메뉴에서 Tab이 어디로 가는지 비교해볼 수 있습니다.

CSS 앵커 포지셔닝은 “이 요소를 저 요소 옆에 붙여라"를 CSS만으로 표현하게 해줍니다. 팝오버와 짝을 이루는 기능이죠.

.trigger { anchor-name: --menu-btn; }
.menu {
  position: absolute;
  position-anchor: --menu-btn;
  top: anchor(bottom);   /* 버튼 아래쪽에 붙인다 */
  left: anchor(left);
}

지원 상황이 최근에 꽤 바뀌었습니다. 한동안 크롬 전용이라는 인식이 있었는데, 파이어폭스와 사파리도 이제 핵심 기능을 지원합니다. 크롬이 125(2024년 5월), 사파리가 26(2025년 9월), 파이어폭스가 147(2026년 1월)로 차례차례 합류했어요.

한 가지 바로잡을 게 있습니다. 화면 밖으로 넘칠 때 위치를 뒤집는 @position-try가 더 최신 버전을 요구한다는 이야기가 도는데, 사파리와 파이어폭스에서는 핵심 기능과 같은 버전에 함께 들어왔습니다. 초기에 잠깐 어긋났던 건 크롬뿐이고요(position-try-fallbacks가 128). 앵커 포지셔닝이 되는 브라우저면 이 폴백도 대체로 같이 됩니다.

그럼 마음 놓고 써도 되느냐 하면, 아직은 아닙니다. 파이어폭스 지원이 이제 반년 남짓이라 현장에는 구버전이 많이 남아 있고, position-anchor의 초기값이나 position-visibility의 일부 값처럼 엔진마다 어긋나는 구석도 남아 있어서 webstatus.dev의 Baseline 등급은 여전히 ‘제한적(limited)’입니다. 폴백 없이 앵커 포지셔닝에만 기대어 배치를 잡는 건 조금 이릅니다.

접근성 관점에서 주목할 점은 따로 있습니다. 앵커 포지셔닝은 DOM 순서를 바꾸지 않습니다.

당연한 말 같지만 결과가 만만치 않아요. 어떤 요소를 화면상 버튼 바로 아래에 붙여놨는데, 마크업에서는 문서 맨 끝에 있다고 해봅시다. 눈으로 보는 사람에게는 버튼과 메뉴가 한 덩어리인데, 키보드로 Tab을 누르는 사람에게는 그 둘 사이에 페이지 전체가 끼어 있습니다. 스크린 리더로 순서대로 읽는 사람도 마찬가지고요.

이건 WCAG가 명시적으로 다루는 문제입니다. 읽기 순서가 의미를 유지해야 한다는 기준(1.3.2)과 포커스 순서가 논리적이어야 한다는 기준(2.4.3)에 정면으로 걸리거든요.

당분간의 안전선은 이렇습니다: 시각적 순서와 DOM 순서를 일치시켜 두세요. CSS로 위치를 자유롭게 옮길 수 있게 됐다고 해서 순서까지 마음대로 흩어놓으면, 화면을 보지 않는 사용자에게는 뒤죽박죽인 페이지가 됩니다. 읽기 순서를 CSS로 조정하는 표준이 논의 중이긴 하지만, 아직 기다릴 단계입니다.

레이아웃 자유도가 올라갈 때마다 이 문제가 반복됩니다. 플렉스박스의 order, 그리드의 배치 속성도 같은 함정을 갖고 있었죠. 도구가 강력해질수록 “보이는 것"과 “읽히는 것"이 갈라지기 쉬워집니다.

dialog — 이건 실제로 일을 덜어줍니다

🔬 체험 데모 열기 — 열고 닫아보면 포커스가 어디로 돌아갔는지 화면이 알려줍니다.

앞의 둘이 “직접 챙겨야 할 것” 이야기였다면, <dialog>는 반대입니다. 예전에 손으로 짜던 걸 브라우저가 대신해주거든요.

<dialog id="confirm">
  <h2 id="confirm-title">삭제하시겠어요?</h2>
  <p>이 작업은 되돌릴 수 없습니다.</p>
  <button id="cancel">취소</button>
  <button id="ok">삭제</button>
</dialog>

document.getElementById('confirm').showModal()

showModal()로 열면 브라우저가 알아서 해주는 것들입니다.

• 포커스 트랩 — 대화상자 바깥의 페이지 콘텐츠가 불활성 상태가 되면서, Tab이 대화상자 안에서만 돕니다. 예전에 직접 짜던, 첫 요소와 마지막 요소를 잡아 순환시키던 그 코드가 필요 없어집니다.
• Esc로 닫기 — 키 이벤트를 붙일 필요가 없습니다.
• 배경 비활성화와 ::backdrop — 뒤쪽 콘텐츠가 불활성 상태가 되고, 어두운 배경도 CSS 한 줄로 스타일링됩니다.

여기서 한 가지 짚어둘 게 있습니다. 대화상자를 열고 Tab을 계속 누르다 보면 주소창이나 탭 바 같은 브라우저 UI로 포커스가 넘어갑니다. 트랩이 깨진 게 아니라, 트랩이 걸리는 범위가 문서 안까지이기 때문입니다. 브라우저 자체의 UI는 문서 바깥이라 웹페이지가 손댈 수 없거든요. 브라우저 UI를 한 바퀴 돌면 포커스는 다시 대화상자 안으로 돌아옵니다.

오해하지 않으셔도 되는 게, 모달이 포커스를 가두는 것 자체는 의도된 동작이고 옳습니다. “이걸 처리하기 전에는 뒤로 못 갑니다"를 키보드 사용자에게도 똑같이 전달하는 방법이 그것뿐이니까요. WCAG의 키보드 트랩 금지 기준(2.1.2)도 “가두지 말라"가 아니라 “들어갔으면 나올 수 있어야 한다”는 요구입니다. 대화상자는 Esc와 닫기 버튼이라는 출구가 있으니 이 기준을 만족하고요. 정말 문제가 되는 건 출구 없이 갇히는 쪽입니다 — 커스텀 위젯에 포커스가 들어간 뒤 Tab으로도 Esc로도 빠져나올 수 없는 경우요.

직접 짜본 분은 아실 텐데, 포커스 트랩 하나만 제대로 만들어도 코드가 수십 줄 나옵니다. 그걸 통째로 걷어낼 수 있다는 건 꽤 큰 이야기예요.

그래도 두 가지는 남습니다

다만 “열기만 하면 끝"은 아닙니다. 두 가지는 여전히 우리 몫입니다.

첫째, 이름을 붙여야 합니다. 대화상자에 접근 가능한 이름이 없으면 스크린 리더가 그냥 “대화상자"라고만 읽습니다. 무슨 대화상자인지 모른 채 갇힌 셈이죠. 안의 제목과 연결해주면 됩니다.

<dialog aria-labelledby="confirm-title">
  <h2 id="confirm-title">삭제하시겠어요?</h2>

둘째, 포커스 복귀는 “확인"이 필요합니다. 예전에는 “닫을 때 포커스를 직접 되돌려야 한다"가 정설이었는데, 지금은 아닙니다. HTML 명세가 대화상자를 열 때 직전에 포커스였던 요소를 기억해뒀다가 닫을 때 그리로 되돌리도록 정하고 있고, 파이어폭스는 90부터 이 동작을 구현했습니다. 크롬·사파리도 마찬가지고요. 그냥 열고 닫으면 포커스는 알아서 버튼으로 돌아옵니다.

그럼 신경 쓸 게 없느냐, 그건 또 아니에요. 되돌아갈 요소가 그 사이에 사라졌을 때가 문제입니다. 목록에서 “삭제” 버튼을 눌러 확인 대화상자를 띄우고, 삭제를 실행하면서 그 버튼이 통째로 없어지는 경우죠. 이때는 브라우저도 돌려보낼 곳이 없어서 포커스가 <body>로 떨어지고, 스크린 리더 사용자는 페이지 맨 위로 튕겨 나갑니다. 이런 흐름이 있는 곳에만 안전망을 깔아두면 됩니다.

// 브라우저가 열기 직전의 포커스를 기억했다가 닫을 때 알아서 되돌려준다.
// 다만 그 요소가 사라졌다면 포커스는 <body>로 떨어진다 — 그때만 손을 댄다.
dialog.addEventListener('close', () => {
  if (document.activeElement === document.body) {
    // main에 tabindex="-1"이 있어야 포커스를 받습니다
    document.querySelector('main')?.focus()
  }
})

그리고 <dialog> 요소 자체에는 tabindex를 주지 마세요. 포커스 모델이 깨집니다.

남은 버그도 있습니다. 사파리와 VoiceOver 조합에서 모달 대화상자 안의 일반 텍스트가 안 읽히는 문제는 WebKit 버그 174667로 등록돼 있는데, P1·Critical로 분류돼 있으면서도 아직 열려 있습니다. 여러 줄짜리 설명이나 입력 칸 옆 에러 메시지가 통째로 안 들리는 상황이라, 사파리 사용자가 많은 서비스라면 한 번 직접 들어보시길 권합니다.

반대로 aria-haspopup="dialog"는 예전만큼 나쁘지 않습니다. dialog 값이 오래도록 지원되지 않는다는 이야기가 유명한데, NVDA가 2023.2에서 받아들인 뒤로는 JAWS·NVDA·VoiceOver·Orca 모두 읽어주는 것으로 보고돼 있어요(a11ysupport.io 기준, 윈도우 내레이터만 부분 지원). 다만 그 테스트 결과 자체가 몇 년 된 것이라 맹신할 건 아닙니다.

그래도 손으로 짜던 시절보다는 확실히 나아졌습니다.

뷰 트랜지션 — 예뻐지는 만큼 조심할 것

🔬 체험 데모 열기 — 이 브라우저가 지원하는지, 동작 줄이기가 켜져 있는지 바로 보여줍니다.

페이지가 바뀔 때 요소가 부드럽게 이어지는 그 효과입니다. 같은 문서 안에서의 전환은 파이어폭스가 144(2025년 10월)로 마지막에 합류하면서 이제 주요 브라우저가 모두 지원합니다. 문서를 넘나드는 전환은 크롬 126과 사파리 18.2가 지원하지만, 파이어폭스는 아직입니다. 교차 문서 전환은 아직 모든 브라우저에서 되는 단계가 아니에요.

접근성에서 가장 먼저 걸리는 건 움직임 자체입니다. 화면이 미끄러지고 확대되는 연출은 전정기관에 문제가 있는 사용자에게 어지럼증이나 메스꺼움을 유발할 수 있거든요. 그래서 사용자가 운영체제에서 “동작 줄이기"를 켜뒀다면 반드시 존중해야 합니다. 이건 선택이 아니라 기본값에 가깝습니다.

@media (prefers-reduced-motion: reduce) {
  ::view-transition-group(*),
  ::view-transition-old(*),
  ::view-transition-new(*) {
    animation: none !important;   /* 움직임 대신 즉시 전환 */
  }
}

덜 알려진 문제도 있습니다. 전환 중에는 이전 화면과 새 화면의 스냅샷이 동시에 존재합니다. 그래서 읽던 위치를 잃거나, 포커스가 어디로 갔는지 알 수 없어지거나, aria-live 영역에 담아둔 알림(스크린 리더가 화면 변화를 자동으로 읽어주도록 표시해둔 자리)이 엉뚱한 타이밍에 읽히는 일이 생길 수 있어요. 이 부분은 아직 깔끔하게 정리된 해법이 없는 영역이라, 화려한 전환을 넣기 전에 키보드로 한 바퀴 돌아보는 게 최선입니다.

초록불에도 등급이 있다 — Baseline 읽는 법

앞에서 “Baseline 새로 사용 가능”, “아직 제한적” 같은 말을 계속 썼는데, 이 등급이 뭔지 한 번 정리하고 넘어가는 게 좋겠습니다. 다른 기능을 직접 확인할 때 쓰게 될 잣대거든요.

Baseline은 크롬 팀이 시작해 지금은 W3C의 WebDX 커뮤니티 그룹이 정의하는 표기입니다. “이 기능이 주요 브라우저에 다 들어왔나"를 한 단어로 알려주자는 취지예요. 기준이 되는 브라우저는 7종인데, 모바일을 따로 셉니다 — 사파리(iOS·macOS), 크롬(안드로이드·데스크톱), 엣지(데스크톱), 파이어폭스(안드로이드·데스크톱). 삼성 인터넷이나 앱 안의 웹뷰는 여기 안 들어갑니다.

등급은 셋입니다.

30개월이라는 숫자가 뜬금없어 보이는데, 근거가 있습니다. 새 버전이 나온 뒤 그 정도 시간이 지나면 대체로 전 세계 사용자의 95% 안팎이 그 버전을 쓰게 된다는 관측이에요. 쉽게 말해 ‘새로 사용 가능’은 “최신 브라우저에서는 다 된다”, ‘널리 사용 가능’은 “업데이트 안 한 사람까지 대체로 된다”는 뜻입니다. 같은 문서 뷰 트랜지션이 널리 사용 가능이 되는 건 2028년 봄쯤이겠네요.

등급 한 글자에 가려지는 것

그런데 이 표기를 곧이곧대로만 읽으면 놓치는 게 있습니다. 이 글에 마침 좋은 사례가 둘이나 있어요.

popover는 왜 2025년 1월이었을까요. 사파리 macOS는 2023년 9월에 이미 지원했고 파이어폭스도 2024년 4월에 합류했는데, 등급은 그로부터 9개월을 더 기다렸습니다. iOS 사파리 때문이었는데, 이유가 재밌습니다. 기능이 아예 없어서가 아니라 팝오버 바깥을 탭해도 닫히지 않는 버그가 ‘부분 구현’으로 기록돼 있었거든요. 딱 이 글이 계속 이야기하는 종류의 문제죠 — 되긴 되는데 제대로 안 되는.

앵커 포지셔닝은 보는 곳마다 답이 다릅니다. webstatus.dev에서 기능 전체를 조회하면 ‘제한적’이라고 나오는데, MDN에서 anchor-name 페이지를 열면 ‘Baseline 2026’이라고 뜹니다. 그런데 같은 MDN에서 position-anchor 페이지는 또 ‘제한적’이고요. 틀린 게 아니라 묶음 안의 조각마다 상태가 달라서 생기는 일입니다. 그러니 “이 기능 쓸 만한가"보다 “내가 지금 쓰려는 이 속성이 되나”를 물어야 정확한 답이 나옵니다.

다른 기능은 어디서 확인하나

네 가지만 보고 끝낼 순 없으니, 직접 확인하는 경로를 정리해둡니다.

MDN을 볼 때 요령이 하나 있습니다. 상단 배너에 별표와 함께 “일부 기능은 지원 수준이 다를 수 있다"는 문구가 붙어 있으면, 그 페이지가 여러 조각을 묶어 보여주고 있다는 신호입니다. 그럴 땐 아래 호환성 표까지 내려가서 각주를 봐야 해요. 아까 iOS 팝오버의 ‘바깥 탭으로 안 닫힘’ 같은 건 배너가 아니라 그 각주에 적혀 있습니다.

caniuse와 Baseline이 서로 다른 답을 주는 것도 알아두면 좋습니다. caniuse는 “측정된 트래픽 중 몇 %가 되나”(시장 점유율), Baseline은 “기준 브라우저 7종에 다 있나”(브라우저 집합)를 묻습니다. 그래서 교차 문서 뷰 트랜지션처럼 크로미움 계열과 사파리에 다 있는 기능은 caniuse 비율이 꽤 높게 나오지만 Baseline은 여전히 ‘제한적’입니다 — 파이어폭스가 통째로 빠져 있으니까요. 어느 쪽이 옳다기보다, 질문이 다른 겁니다.

참고로 사파리 쪽은 예전에 쓰던 WebKit Feature Status 페이지가 은퇴했습니다. 지금은 릴리스마다 올라오는 WebKit 블로그 글을 보는 게 정확해요.

그런데 어디에도 안 나오는 것

여기까지가 “동작하는가"를 확인하는 방법입니다. 그리고 이 글의 출발점이었던 질문, “스크린 리더가 제대로 읽나"는 저 표들 어디에도 없습니다.

이건 제 주장이 아니라 MDN이 Baseline 설명에 직접 적어둔 내용입니다. Baseline은 접근성·사용성·성능·보안 테스트를 대신하지 않으며, 보조기술에서 동작하는지는 알려주지 않는다고요. Baseline을 만든 쪽의 문서에도 스크린 리더·화면 확대·음성 제어 지원은 다루지 않는 범위로 명시돼 있습니다. 정직한 태도인데, 정작 그 문장이 홍보용 소개 페이지에는 없어서 대부분의 사람은 못 보고 지나갑니다.

그럼 보조기술 지원은 어디서 볼까요. 솔직히 말하면 Baseline만큼 잘 관리되는 곳이 아직 없습니다.

• a11ysupport.io — 가장 넓은 매트릭스지만 항목에 따라 테스트가 4~5년 전 것입니다. 각 항목에 적힌 테스트 날짜를 반드시 같이 보세요.
• ARIA-AT — W3C가 실제 보조기술로 표준 테스트를 돌리는, 지금 살아 움직이는 프로젝트입니다. 대신 테스트 계획이 만들어진 패턴만 다룹니다.
• ARIA APG의 보조기술 지원표 — ARIA-AT 결과가 정리돼 올라오는 곳입니다.

결국 남는 건 직접 확인하는 일입니다. 거창하지 않아도 됩니다. 새 기능을 붙였다면 이 세 가지만 해보세요.

1. 마우스를 치우고 Tab만으로 한 바퀴 — 못 가는 곳, 안 보이는 포커스, 순서가 튀는 지점이 대부분 여기서 걸립니다.
2. 개발자도구의 접근성 트리 확인 — 내가 만든 요소가 어떤 역할과 이름으로 노출되는지 봅니다. 이름이 비어 있으면 그 자리가 문제입니다.
3. 스크린 리더로 한 번 들어보기 — 윈도우는 NVDA가 무료고, 맥은 VoiceOver가 기본으로 들어 있습니다. 5분이면 충분합니다.

한 장 요약

• popover: 2025년 1월 Baseline ‘새로 사용 가능’. 단 모달이 아니다 — 포커스가 갇히지 않고 배경도 살아 있다. role과 포커스 이동은 직접(포커스는 안쪽 요소의 autofocus로), 다만 aria-expanded는 브라우저가 붙여준다. 반드시 처리해야 하는 UI라면 <dialog>를 쓸 것
• 앵커 포지셔닝: 크롬 125·사파리 26·파이어폭스 147로 세 엔진 모두 지원. @position-try도 사파리·파이어폭스에선 같은 버전에 함께 들어왔다. 그래도 Baseline은 아직 ‘제한적’. 그리고 DOM 순서를 바꾸지 않으므로 시각 위치와 읽기·탭 순서가 어긋나면 WCAG 1.3.2·2.4.3 위반이 된다. 순서를 일치시켜 둘 것
• <dialog> + showModal(): 포커스 트랩·Esc·배경 비활성화에 더해 닫을 때 포커스 복귀까지 브라우저가 해준다. 남는 건 접근 가능한 이름(aria-labelledby)과, 열었던 요소가 사라진 경우의 안전망. <dialog>에 tabindex 금지
• 뷰 트랜지션: 같은 문서는 파이어폭스 144로 전 브라우저 지원, 교차 문서는 파이어폭스 미지원. prefers-reduced-motion 존중은 필수, 전환 중 포커스·읽기 위치 문제는 미해결
• Baseline 읽는 법: 제한적 → 새로 사용 가능 → (30개월) → 널리 사용 가능. 등급은 묶음 단위라 조각마다 다를 수 있으니 쓰려는 속성 페이지를 볼 것. 상태 확인은 webstatus.dev·MDN, 점유율은 caniuse
• 공통 교훈: 지원표의 초록불은 “동작한다"까지고, “모두가 쓸 수 있다"는 아니다 — Baseline 문서도 보조기술 지원은 다루지 않는다고 밝히고 있다

새 장난감을 받았을 때

새 기능이 나오면 반가운 마음에 바로 끼워보게 됩니다. 저도 popover를 처음 보고는 “이제 드롭다운 라이브러리 안 써도 되겠다” 싶었거든요. 실제로 그렇기도 하고요.

다만 브라우저가 대신해주는 범위를 정확히 아는 게 중요하더라고요. <dialog>처럼 정말 일을 덜어주는 것도 있고, popover처럼 편해 보이지만 접근성은 그대로 우리 몫인 것도 있으니까요. 이 경계를 모르면 “최신 기능 썼으니 잘 됐겠지” 하고 넘어가게 되는데, 그 사이에 키보드 사용자는 조용히 막혀 있습니다.

앞에서 적어둔 세 가지 — Tab 한 바퀴, 접근성 트리 확인, 스크린 리더로 들어보기 — 를 다 해도 10분이 안 걸립니다. 지원표를 확인하는 데 쓰는 시간과 비슷하죠. 그런데 그 10분이 “새 기능 썼다"와 “모두가 쓸 수 있다” 사이의 거리를 대부분 메워줍니다.