WCAG 1.3.4: 방향 전환

- 제가 할 일: - 원문의 의미와 톤을 유지해 한국어로 번역합니다. - 문단과 줄바꿈 구조를 그대로 보존합니다. - 숫자, 기호, 고유명사를 원문과 동일하게 유지합니다. - 성별 관련 표현을 문맥에 맞게 자연스럽게 옮깁니다. - 번역 후 원문과의 의미·스타일 일치 여부를 간단히 점검합니다. WCAG 1.3.4 Orientation은 특정한 방향이 필수적인 경우를 제외하고, 콘텐츠가 세로 또는 가로와 같은 단일 화면 방향으로만 보기나 조작이 제한되지 않도록 할 것을 요구합니다. 이 기준은 태블릿을 고정해 두었거나 운동 장애가 있는 사용자처럼 기기를 물리적으로 회전시킬 수 없는 사용자들도 모든 콘텐츠에 계속 접근할 수 있도록 보장합니다.

이 규칙의 의미

WCAG 1.3.4 Orientation은 WCAG 2.1에서 도입되어 WCAG 2.2로 이어지는 레벨 AA 기준이다. 이 기준은 콘텐츠가 세로(포트레이트) 또는 가로(랜드스케이프) 중 하나의 화면 방향에만 고정되어서는 안 되며, 특정 방향이 콘텐츠 기능에 본질적으로 필요할 때에만 예외가 허용된다고 규정한다. 실제로는, 웹 페이지와 웹 기반 애플리케이션은 사용자의 기기가 세로로 들려 있든 가로로 들려 있든, 또는 방향이 기기의 운영체제나 사용자의 선호 설정에 의해 제어되든 상관없이 올바르게 반응하고 완전히 조작 가능해야 한다는 의미다.

이 기준은 개발자가 CSS 미디어 쿼리, JavaScript, 또는 디바이스 API를 사용해 의도적으로 콘텐츠를 한 가지 방향으로만 제한하는 상황을 대상으로 한다. 흔한 위반 사례는 “기기를 가로 모드로 회전해 주세요”와 같은 메시지를 표시하면서 동시에 세로 모드에서는 모든 인터랙티브 콘텐츠를 숨기거나 비활성화하는 경우다. 또 다른 위반 사례는 웹 애플리케이션이 CSS transform을 적용하거나 뷰포트를 강제로 회전시켜 사용자의 기기 방향 설정을 덮어쓰는 경우다.

준수로 인정되는 경우: 콘텐츠가 세로와 가로 방향 모두에서 접근 가능해야 한다. 모든 텍스트, 인터랙티브 요소, 폼, 내비게이션, 미디어는 기기의 방향과 관계없이 계속 보이고 조작 가능해야 한다. 레이아웃은 CSS Flexbox, CSS Grid, 미디어 쿼리와 같은 반응형 디자인 기법을 사용해 적응할 수 있지만, 방향만을 이유로 어떤 것도 제거되거나 조작 불가능해져서는 안 된다.

위반으로 인정되는 경우: 한 방향에서 콘텐츠를 숨기거나 비활성화하거나 상호작용을 차단하는 경우, 작동 가능한 대안을 제공하지 않은 채 사용자가 기기를 회전하도록 지시하는 메시지를 표시하는 경우, DeviceOrientationEvent 또는 screen.orientation을 감지한 뒤 UI의 일부를 잠그거나 비활성화하는 JavaScript, 또는 중요한 콘텐츠에 차단 오버레이를 표시하거나 display: none을 적용하기 위해 @media (orientation: portrait)를 사용하는 CSS 등이 이에 해당한다.

본질적 예외: WCAG는 일부 콘텐츠가 본질적으로 특정 방향에 의존하는 목적을 가질 수 있음을 인정한다. 예를 들어, 피아노 키보드 애플리케이션은 세로 레이아웃으로는 음악적으로 유용할 만큼 충분한 건반을 표시할 수 없기 때문에 가로 모드를 정당하게 요구할 수 있다. 카메라가 가로로 된 수표를 촬영하는 데 의존하는 은행 수표 입금 기능은 가로 모드를 요구할 수 있다. 가상 현실 헤드셋 인터페이스는 작동을 위해 고정된 방향이 필요할 수 있다. 그러나 “본질적”이라는 기준은 매우 높다. 단순한 개발 편의성이나 미적 선호는 예외 사유가 될 수 없다. 예외는 디자인 선택이 아니라 콘텐츠 자체의 근본적인 요구 사항에 의해 정당화되어야 한다.

왜 중요한가

방향 제한은 신체적·운동 장애가 있는 사람들에게 불균형적으로 큰 영향을 미친다. 예를 들어, 휠체어 사용자가 태블릿을 의자 팔걸이에 세로 방향으로 고정된 상태로 장착해 사용하는 경우를 생각해 보자. 이 사용자는 기기를 물리적으로 기울일 수 없으므로, 가로 방향을 요구하는 콘텐츠는 완전히 접근 불가능해진다. 이는 가상의 극단적 사례가 아니라, 뇌성마비, 척수 손상, ALS, 심한 관절염과 같은 상태를 가진 사람들을 위해 보조공학 기기를 고정된 방향으로 장착하는 것은 흔한 편의 제공 방식이다.

장착된 기기 외에도, 많은 사용자가 장애와 무관한 이유로 운영체제의 방향 잠금 기능에 의존한다. 침대에 누워 있는 사용자는 화면이 계속 회전하는 것을 막기 위해 휴대폰을 세로로 잠글 수 있다. 전정기관 장애(내이와 균형에 영향을 미치는 상태)가 있는 사용자는 방향 변경으로 인한 갑작스러운 레이아웃 변화가 혼란스럽거나 신체적으로 메스꺼움을 유발할 수 있다. 이러한 사용자에게 콘텐츠에 접근하기 위해 기기 방향 잠금을 해제하도록 강요하는 것은 불필요하고 차별적인 장벽을 만드는 것이다.

인지적 접근성도 중요한 요소다. 인지 장애가 있는 사용자는 일관되고 예측 가능한 레이아웃으로부터 큰 도움을 받는 경우가 많다. 갑자기 콘텐츠를 차단하거나 기기 회전을 요구하는 오류 메시지와 비슷한 화면을 표시하는 애플리케이션은 특히 왜 경고가 나타나는지 이해하지 못할 수 있는 사용자에게 혼란과 불안을 줄 수 있다.

사용성 및 비즈니스 관점에서도 방향 제한은 모든 사용자에게 불리하게 작용한다. 모바일 웹 트래픽의 상당 부분은 세로 모드에서 발생하며, 사이트를 가로 모드로만 제한하면 즉각적인 이탈로 이어질 수 있다. 검색 엔진은 모바일 친화성과 안정적인 레이아웃 동작을 포함한 Core Web Vitals를 점점 더 랭킹 알고리즘에 반영하고 있으므로, 방향 관련 문제는 SEO 성능과 유기적 트래픽에 측정 가능한 부정적 영향을 줄 수 있다.

세계보건기구에 따르면 전 세계적으로 약 13억 명이 어떤 형태로든 장애를 가지고 있다. 이 집단의 상당수는 인터넷에 접근하는 주요 또는 유일한 수단으로 모바일 기기를 사용하므로, 모바일 방향 접근성은 특히 중요한 문제다.

테스트 방법

기본선으로 자동 스캔 실행: Chrome, Firefox, Edge에서 페이지를 연다. axe DevTools 브라우저 확장 프로그램을 사용하거나 Lighthouse 접근성 감사를 실행해 기본선을 설정한다. 이 도구들은 방향 위반을 직접 감지하지는 못하지만, 반응형 디자인 관련 문제, viewport 메타 태그 문제, 방향 접근성 실패를 악화시키는 ARIA 누락 등을 표시할 수 있다. 자동 보고서가 깨끗하다고 해서 1.3.4 준수를 의미하는 것은 아니라는 점에 유의해야 한다.
브라우저 DevTools의 디바이스 에뮬레이션 사용: Chrome 또는 Edge에서 DevTools(F12)를 열고, 디바이스 툴바 아이콘(Ctrl+Shift+M / Cmd+Shift+M)을 클릭한 뒤 iPhone 14나 Galaxy S21과 같은 모바일 기기를 선택한다. 디바이스 툴바의 회전 아이콘을 사용해 세로와 가로 방향을 전환한다. 내비게이션, 제목, 본문 텍스트, 폼, 버튼, 이미지, 미디어 등 모든 콘텐츠가 두 방향 모두에서 계속 보이고 조작 가능한지 체계적으로 확인한다. 한 방향에서만 나타나는 차단 오버레이, 숨겨진 섹션, 비활성화된 인터랙티브 요소가 있는지 살펴본다.
실제 기기에서 테스트: Android 또는 iOS 기기를 연결하고 모바일 브라우저에서 페이지를 연다. 기기를 실제로 세로와 가로 방향으로 회전시킨다. 운영체제의 방향 잠금이(활성화된 경우) 콘텐츠가 깨지거나 회전 프롬프트를 표시하게 만들지 않는지 확인한다. 방향 잠금을 켠 상태와 끈 상태 모두에서 테스트한다.
방향 시뮬레이션을 포함한 스크린 리더 테스트: iOS에서 VoiceOver를 활성화(측면 버튼 3회 클릭)한 상태로 세로 방향에서 스와이프 제스처를 사용해 페이지를 탐색한다. 이후 가로 방향으로 회전하고 VoiceOver의 읽기 순서와 접근 가능한 이름이 올바르게 유지되는지 확인한다. Android에서 TalkBack을 사용해 동일한 테스트를 수행한다. 데스크톱에서는 NVDA와 Firefox를 사용하고 DevTools를 통해 방향을 시뮬레이션하여, 접근성 트리가 방향에 관계없이 일관적인지 확인한다.
CSS와 JavaScript에서 방향 제한 여부 검사: DevTools에서 Sources 또는 Elements 패널을 열고 스타일시트에서 orientation: portrait와 orientation: landscape 미디어 쿼리를 검색한다. 각 블록이 무엇을 하는지 검토한다. display: none으로 콘텐츠를 숨기거나 차단 오버레이를 적용하는지, 아니면 단순히 레이아웃만 조정하는지 확인한다. JavaScript 파일에서 screen.orientation, orientationchange, screen.orientation.lock을 검색한다. 발견된 패턴이 UI를 잠그거나 콘텐츠를 차단하는지 평가한다.
본질적 예외 검증: 사이트가 의도적으로 방향을 제한하는 경우, 문서화되고 정당화된 본질적 사용 사례가 존재하는지 확인한다. 예외는 미관이 아니라 콘텐츠에 의해 주도되어야 한다. 스크린샷과 구체적인 정당화 사유를 함께 기록해 결과를 문서화한다.

수정 방법

세로 모드에서 CSS 차단 오버레이 — 잘못된 예

<!-- A full-screen overlay shown only in portrait that blocks all content -->
<style>
  .rotate-prompt {
    display: none;
    position: fixed;
    inset: 0;
    background: #fff;
    z-index: 9999;
    text-align: center;
    padding: 2rem;
  }
  @media (orientation: portrait) {
    .rotate-prompt {
      display: flex; /* blocks all underlying content */
    }
  }
</style>
<div class='rotate-prompt'>
  <p>Please rotate your device to landscape mode.</p>
</div>
<main id='app-content'>
  <!-- All application content here -->
</main>

세로 모드에서 CSS 차단 오버레이 — 올바른 예

<!-- Remove the blocking overlay entirely. Use responsive CSS to adapt the layout instead. -->
<style>
  /* Portrait layout: stack elements vertically */
  @media (orientation: portrait) {
    .dashboard-grid {
      grid-template-columns: 1fr;
    }
  }
  /* Landscape layout: side-by-side columns */
  @media (orientation: landscape) {
    .dashboard-grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>
<main id='app-content'>
  <div class='dashboard-grid'>
    <!-- Content adapts layout but is always accessible -->
  </div>
</main>

JavaScript 방향 잠금 — 잘못된 예

<script>
  // Locks screen to landscape and shows an error if it fails (e.g. on iOS)
  screen.orientation.lock('landscape').catch(function() {
    document.getElementById('orientation-error').style.display = 'block';
    document.getElementById('main-content').style.display = 'none';
  });
</script>
<div id='orientation-error' style='display:none'>
  This application only works in landscape mode.
</div>
<div id='main-content'>
  <!-- Application content -->
</div>

JavaScript 방향 잠금 — 올바른 예

<script>
  /*
    Do not lock orientation via JavaScript.
    Instead, listen for orientation changes and adapt the UI
    without hiding or disabling content.
  */
  window.addEventListener('orientationchange', function() {
    var isPortrait = window.matchMedia('(orientation: portrait)').matches;
    // Adjust layout class for styling only — never hide content
    document.body.classList.toggle('portrait-layout', isPortrait);
    document.body.classList.toggle('landscape-layout', !isPortrait);
  });
</script>
<div id='main-content'>
  <!-- All content remains visible and operable in both orientations -->
</div>

방향 변경을 방해하는 viewport 메타 태그 — 잘못된 예

<!-- Some older implementations tried to fix orientation via viewport -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
  While 'user-scalable=no' does not directly lock orientation,
  combining it with CSS transforms that rotate the viewport
  is a known anti-pattern that creates orientation accessibility failures.
-->
<style>
  /* Anti-pattern: rotating the entire body to simulate landscape on a portrait device */
  @media (orientation: portrait) {
    body {
      transform: rotate(90deg);
      transform-origin: left top;
      width: 100vh;
      overflow-x: hidden;
    }
  }
</style>

방향 변경을 방해하는 viewport 메타 태그 — 올바른 예

<!-- Use a standard responsive viewport tag. Never rotate the body via CSS transforms. -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
  Let the browser and operating system handle orientation naturally.
  Design responsively so the content works at all viewport aspect ratios.
  Use CSS Grid and Flexbox to reflow content, not transforms.
-->

자주 발생하는 실수

@media (orientation: portrait)를 사용해 내비게이션 메뉴, 사이드바, 메인 콘텐츠 영역에 display: none을 적용하는 경우. 레이아웃을 단순히 재배치하는 것이 아니라, 뷰에서 콘텐츠를 제거하는 모든 CSS 방향 쿼리는 잠재적인 위반이다. 스타일시트의 모든 방향 미디어 쿼리를 점검해 레이아웃만 변경하고 콘텐츠 가용성은 변경하지 않는지 확인해야 한다.
본질적이지 않은 애플리케이션에서 screen.orientation.lock()을 호출하는 경우. 이 Web API는 게임 및 특정 미디어 사용 사례를 위한 것이다. 일반 웹 애플리케이션이나 전자상거래 사이트에서 가로 모드의 “미관 향상”을 위해 사용하는 것은 본질적 예외에 해당하지 않으며, WCAG 1.3.4를 직접적으로 위반한다.
접근 가능한 대안 없이 “기기를 회전하세요” 스플래시 화면을 표시하는 경우. 짧은 방향 안내를 표시하더라도, 콘텐츠 접근을 차단해서는 안 된다. 표시하는 경우에도 반드시 닫을 수 있어야 하고, 메인 콘텐츠를 가리지 않아야 하며, 요구 사항이 아니라 제안으로 전달되어야 한다.
모바일 사용자가 항상 동영상 콘텐츠를 가로 모드로 선호한다고 가정하는 경우. 세로 모드에서 재생 컨트롤이나 재생 버튼을 비활성화해 사용자가 회전해야만 상호작용할 수 있도록 강제하는 동영상 플레이어는, 동영상 포맷이 세로 모드에서 정말로 렌더링될 수 없는 경우(표준 웹 동영상에서는 거의 없다)를 제외하면 1.3.4를 위반한다.
한 방향에서 <body>나 루트 컨테이너에 CSS transform: rotate(90deg)를 적용하는 경우. 이는 기기가 자연스럽게 방향을 처리하도록 두는 대신 CSS로 방향 변경을 흉내 내는 것으로, 깨진 레이아웃, 화면 밖 콘텐츠, 스크린 리더의 접근성 트리 혼란을 초래한다.
QA 과정에서 팀이 데스크톱 브라우저에서만 테스트하기 때문에 방향 동작 테스트를 하지 않는 경우. 데스크톱 브라우저 DevTools의 방향 시뮬레이션은 표준 QA 사이클에서 항상 사용되지 않는다. 방향은 모바일 테스트 계획에서 명시적인 항목이 되어야 하며, iOS와 Android 실제 기기 모두에서 검증해야 한다.
부모 페이지의 방향 상태를 고려하지 않고 iframe 내부에서 방향 동작을 재정의하는 경우. 서드파티 위젯, 임베디드 지도, 결제 iframe은 독립적으로 방향을 잠글 수 있다. 페이지 자체가 준수하더라도, 방향이 잠긴 iframe을 호스팅하면 해당 iframe의 본질적 예외가 문서화되지 않는 한 페이지 전체가 비준수 상태가 된다.
서버 측 사용자 에이전트 감지를 사용해 모바일 사용자에게 “가로 전용” 버전의 페이지를 제공하는 경우. 세로 호환 가능한 대안 없이 모바일 사용자를 가로에서만 작동하는 별도 URL로 리디렉션하는 것은 체계적인 위반이며, SEO와 URL 정규화 문제도 함께 야기한다.
프로덕션 빌드에서만 방향 제한을 적용해 개발 단계 테스트에서는 보이지 않게 만드는 경우. 기능 플래그나 A/B 테스트 프레임워크가 특정 환경이나 특정 사용자 세그먼트에서만 방향 잠금 코드를 활성화하는 경우가 있어, 출시 전 접근성 감사에서 위반이 발견되지 않을 수 있다.
디자이너가 가로 레이아웃을 선호한다는 이유로 본질적 예외가 적용된다고 가정하는 경우. 본질적 예외는 법적·윤리적으로 매우 높은 기준이다. 콘텐츠의 주요 기능이 다른 방향에서는 근본적으로 불가능해야 하며, 단지 더 보기 좋거나 팀이 세로 레이아웃을 구현할 시간이 부족했다는 이유는 예외 사유가 될 수 없다.

터키 접근성 규정과의 관계

터키의 2025/10번 대통령 공고(Presidential Circular No. 2025/10)는 2025년 6월 21일 관보(Resmî Gazete) 32933호에 게재되었으며, 디지털 접근성에 대한 포괄적인 국가 프레임워크를 수립한다. 이 공고는 해당 기관이 WCAG 2.2 레벨 AA를 준수할 것을 의무화하며, 여기에는 WCAG 1.3.4 Orientation이 명시적으로 포함된다. 이는 해당 기관이 운영하는 모든 디지털 서비스나 웹사이트가 콘텐츠를 단일 방향으로 제한해서는 안 되며, 모든 시민—장애인을 포함해—이 기기를 물리적으로 어떻게 다루든 디지털 서비스에 접근할 수 있도록 하려는 공고의 취지를 반영한다.

공고의 적용을 받으며 레벨 AA 적합성을 달성해야 하는 기관에는 공공 기관 및 기관(웹사이트와 디지털 서비스를 운영하는 모든 정부 기관), 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 20만 명 이상의 가입자를 보유한 통신 회사, 전자상거래 플랫폼, 여행사, 민간 운송 회사, 국가교육부(MoNE)가 인가한 민간 학교가 포함된다. 이들 기관의 경우, 가로 전용 접속을 요구하는 정부 포털이나 본질적 이유 없이 세로 모드로 잠기는 뱅킹 앱과 같이 1.3.4를 위반하는 방향 제한은 구속력 있는 국가 규정을 직접적으로 위반하는 행위가 된다.

접근성 로고(Erişilebilirlik Logosu)는 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)가 발급하는 인증 마크로, 국가 접근성 표준에 대한 적합성을 나타낸다. 레벨 AA 적합성을 달성하는 것은 이 로고를 획득하기 위한 전제 조건이다. Erişilebilirlik Logosu를 얻고자 하는 조직은 1.3.4를 포함한 모든 레벨 A 및 레벨 AA 기준을 통과했음을 입증해야 한다. 사이트의 사소한 섹션에서라도 방향 제한 실패가 발생하면 전체 인증이 위태로워질 수 있다.

WCAG 1.3.4는 수동 테스트가 필요하며 자동 스캔만으로는 적합성을 확인할 수 없기 때문에, 해당 기관은 공식 접근성 감사 프로세스에 방향 특화 테스트 케이스를 포함해야 한다. 실제 기기에서 세로와 가로 방향 모두에 대한 테스트 결과 문서는 규정 준수 및 로고 인증에 필요한 접근성 적합성 기록의 일부로 유지되어야 한다. Accsible SDK는 터키의 진화하는 디지털 접근성 의무를 충족하기 위한 총체적 접근의 일환으로, 조직이 방향 관련 장벽을 식별하고 해결하도록 지원한다.