
HTML inert 속성 기준 정리
배경을 가린 모달이나 아직 활성화되면 안 되는 패널을 화면에 남겨 두되, 사용자 입력과 포커스는 막아야 할 때가 있다. 2026년 7월 7일 기준 WHATWG HTML Living Standard은 inert를 요소와 그 flat tree 하위 요소를 사용자 에이전트가 비활성 상태로 다루게 하는 boolean attribute로 정의한다.
실무에서는 "정말 상호작용 자체를 막아야 하는가", "시각적으로도 가려져 있는가", "단순 비노출이면 hidden이 더 맞는가"를 먼저 나누면 선택이 빨라진다. 이 글은 inert의 동작, dialog.showModal()과의 관계, hidden과의 차이, 무난한 적용 기준만 정리한다.
먼저 무엇을 막을까?
| 항목 | inert |
hidden |
|---|---|---|
| 주된 목적 | 보이더라도 상호작용과 접근을 막음 | 콘텐츠를 렌더링 대상에서 숨김 |
| 포커스/클릭 | 포커스 불가, 명령 비작동 | 보이지 않으므로 상호작용 대상이 아님 |
| 접근성 API 노출 | 노출되지 않음 | 표시되지 않으므로 보통 접근 대상이 아님 |
| 적합한 상황 | 모달 뒤 배경, 로딩 중 비활성 폼, 잠긴 오프캔버스 패널 | 현재 문맥에서 아예 보여 주지 않을 콘텐츠 |
inert는 정확히 어떤 의미일까?
HTML 표준은 inert가 지정된 요소와 그 flat tree 하위 요소를 inert 상태로 만들어야 한다고 설명한다. 이 상태의 노드는 클릭 같은 사용자 상호작용 대상이 되지 않고, 텍스트 선택과 find-in-page 대상에서도 제외될 수 있으며, 포커스를 받을 수 없고 접근성 API에도 노출되지 않는다.
중요한 점은 inert가 단순 CSS 편의 기능이 아니라 "사용자에게 지금 접근 가능한가"를 표현하는 의미적 상태라는 점이다. 표준도 사용자가 이해하거나 조작해야 하는 핵심 콘텐츠를 inert subtree 안에 두지 말라고 권고한다.
dialog.showModal()과는 왜 함께 언급될까?
표준은 modal dialog가 top layer에 올라가면, 그 외 문서 영역이 inert가 되는 메커니즘을 설명한다. 그래서 모달을 직접 구현하면서 배경에 임의로 tabindex를 조정하거나 클릭 방지 오버레이만 덧씌우는 방식보다, 실제 모달 의미와 배경 비활성 상태를 함께 맞추는 쪽이 더 일관적이다.
다만 모든 비활성 UI가 dialog인 것은 아니다. 사이드 패널이 아직 열리지 않았거나, 저장 중이라 폼 일부만 잠가야 할 때처럼 모달이 아닌 경우에는 해당 구역에 inert를 직접 쓰는 편이 자연스럽다.
hidden으로는 왜 부족할 수 있을까?
hidden은 "현재 직접 관련 없어서 렌더링하지 않는다"는 의미에 가깝다. 반면 inert는 요소가 화면 구조 안에 남아 있더라도 사용자 상호작용과 접근성 노출을 함께 끊고 싶을 때 맞는다.
예를 들어 배경 콘텐츠가 시각적으로 그대로 보이는 모달 화면이라면 hidden은 맞지 않는다. 콘텐츠를 숨기려는 것이 아니라, 잠시 조작 불가 상태로 바꾸려는 것이기 때문이다. 반대로 아코디언 패널을 아예 접어서 보이지 않게 할 때는 inert보다 hidden, details, 또는 적절한 표시 제어가 더 직접적일 수 있다.
언제 쓰는 편이 무난할까?
| 상황 | 무난한 선택 | 이유 |
|---|---|---|
| 모달 뒤 배경 전체를 잠가야 한다 | dialog + modal 동작 우선 |
표준이 정의한 inert 처리와 자연스럽게 연결됨 |
| 로딩 중이라 폼 일부를 잠시 비활성화한다 | 해당 컨테이너에 inert |
하위 입력과 포커스를 한 번에 막을 수 있음 |
| 콘텐츠를 아예 숨겨야 한다 | hidden 또는 다른 표시 제어 |
목적이 비상호작용이 아니라 비노출임 |
| 개별 버튼 하나만 잠그면 된다 | disabled 우선 검토 |
컨테이너 전체 inert보다 의도가 더 직접적임 |
실제 마크업은 어떻게 두면 될까?
inert는 boolean attribute라서 존재 자체가 상태를 뜻한다. 로딩 중이나 오버레이 표시 시점에 속성을 붙이고, 다시 상호작용을 허용할 때 제거하는 방식이 가장 단순하다.
<section id="profile-form" inert>
<input type="text" name="nickname" />
<button type="submit">저장</button>
</section>
다만 표준은 inert subtree 안의 콘텐츠가 사용자에게도 시각적으로 가려져 있어야 한다고 본다. 즉 속성만 붙이고 외형상 평소와 똑같이 보여 주면 "왜 클릭이 안 되지"라는 혼란을 만들기 쉽다. 로딩 오버레이, dim 처리, 패널 닫힘 상태 같은 시각적 신호를 함께 두는 편이 안전하다.
자주 놓치는 점
첫째, inert는 하위 요소 전체를 묶어서 비활성화하는 도구다. 개별 폼 컨트롤 하나의 활성 여부만 바꾸는 문제라면 disabled가 더 정확할 수 있다.
둘째, 표준은 modal dialog 같은 경우를 예외로 들며, 하위 요소가 조상으로부터의 inertness를 벗어날 수 있는 경우가 있다고 설명한다. 그래서 복잡한 오버레이 구조에서는 "컨테이너 하나에 속성을 붙였으니 모든 것이 똑같이 잠긴다"라고 단순 가정하지 말고 실제 포커스 이동과 접근성을 같이 확인해야 한다.
셋째, inert는 보안 경계가 아니다. 개발자 도구나 스크립트로 상태를 바꾸는 것은 가능하므로, 서버 검증이나 권한 제어를 대신할 수는 없다.
자주 헷갈리는 질문
Q. 클릭만 막고 화면은 그대로 두고 싶다면 pointer-events: none이면 충분할까?
항상 충분하지는 않다. pointer-events: none은 포인터 입력 차단에는 도움이 되지만, 포커스 이동이나 접근성 API 노출까지 함께 정리하지는 않는다. 사용자 상호작용 전체를 멈추려는 목적이라면 inert가 더 직접적이다.
Q. 숨김 패널에도 inert를 같이 붙여야 할까?
경우에 따라 다르다. 이미 hidden 등으로 렌더링 대상에서 빠진다면 추가 inert가 꼭 필요하지 않을 수 있다. 반대로 화면에 남아 있으나 잠겨 있어야 하는 구역이라면 inert의 의미가 분명해진다.
Q. 모달 구현에서 직접 배경 컨테이너에 inert를 붙여도 될까?
가능은 하지만, 먼저 dialog.showModal()로 해결 가능한 구조인지 보는 편이 좋다. 표준이 modal dialog와 배경 inert 관계를 이미 정의하고 있기 때문이다. 커스텀 레이아웃 때문에 직접 제어해야 한다면 포커스 이동, 스크린 리더 노출, 시각적 obscuring까지 함께 확인해야 한다.
정리
inert는 "안 보이게"가 아니라 "지금은 접근 불가하게"를 표현하는 속성으로 이해하면 실수가 줄어든다. 화면에 남아 있는 배경이나 로딩 중 구역을 사용자 입력, 포커스, 접근성 노출에서 함께 분리해야 할 때 가장 유용하다.
2026년 7월 7일 기준 WHATWG HTML Living Standard과 그 문서에 표시된 MDN 호환성 정보만 놓고 보면, inert는 현재 엔진 전반에서 지원되는 기능으로 안내된다. 다만 선택 기준은 여전히 단순하다. 비노출이면 hidden, 개별 컨트롤 비활성화면 disabled, 화면에 남아 있는 구역 전체를 잠글 때는 inert가 무난하다.
참고 자료
'프로그래밍 > HTML, Javascript, CSS' 카테고리의 다른 글
| HTML autocomplete 속성 기준 정리 (0) | 2026.07.10 |
|---|---|
| HTML popover 속성 사용법 (0) | 2026.07.09 |
| Permissions-Policy 헤더 기준 정리 (0) | 2026.07.04 |
| Clear-Site-Data 헤더 기준 정리 (1) | 2026.06.28 |
| Content-Disposition 헤더 사용 기준 정리 (0) | 2026.06.23 |





