(Level AA)
성공 기준(SC)
콘텐츠는 정보나 기능 손실 없이, 그리고 다음의 경우에 대하여 2차원 스크롤 없이 표시될 수 있어야한다.
사용이나 의미 전달을 위해 2차원 레이아웃이 필요한 콘텐츠는 예외로 한다.
참고
320 CSS 픽셀은 400% 확대 시, 초기 뷰포트 너비 1280 CSS 픽셀과 동일한 의미이다. 가로 스크롤을 전제로 설계된 콘텐츠(예: 세로 텍스트)의 경우, 256 CSS 픽셀은 400% 확대 시 초기 뷰포트 높이 1024 CSS 픽셀과 동일하다.
참고
2차원 레이아웃이 필요한 콘텐츠의 예로는 이해를 위해 필요한 이미지(예: 지도 및 다이어그램), 동영상, 게임, 프레젠테이션, 데이터 표(개별 셀 제외), 콘텐츠를 조작하는 동안 툴바를 계속 표시해야 하는 인터페이스 등이 있다. 이러한 콘텐츠 부분에 2차원 스크롤을 제공하는 것은 허용된다.
이 성공 기준의 목적은 사용자가 텍스트 및 관련 콘텐츠를 확대하더라도, 읽기 위해 2차원으로 스크롤하지 않도록 하는 데 있다. 텍스트 줄이 화면 경계를 넘어가게 되면, 사용자는 한 줄씩 읽기 위해 좌우로 반복해서 스크롤해야 한다. 이 과정에서 읽던 위치를 놓치기 쉽고, 신체적·인지적 부담이 크게 증가할 수 있다. 따라서 대부분의 콘텐츠는 이 기준에서 정의한 적절한 크기 조건 내에서 재배치되어야 한다.
이해나 기능 수행을 위해 2차원 레이아웃이 필요한 콘텐츠(예: 표, 지도 등)는 이 성공 기준의 예외로 인정된다. 그러나 이러한 2차원 레이아웃 내부의 콘텐츠, 예를 들어 표의 각 셀과 같은 요소는 여전히 이 기준을 충족해야 한다. 비록 2차원 레이아웃 콘텐츠에 대해 예외가 허용되더라도, 해당 콘텐츠에서의 스크롤을 줄이기 위한 노력을 통해 사용자 경험을 개선할 수 있다.
가장 기본적인 형태의 재배치는 텍스트만으로 구성된 페이지에서 나타난다. 기본적으로 긴 텍스트 줄은 사용 가능한 화면 영역에 맞도록 자동으로 줄바꿈된다. 왼쪽에서 오른쪽(LTR) 또는 오른쪽에서 왼쪽(RTL)으로 작성되는 가로쓰기 언어의 경우, 텍스트는 화면의 너비에 맞춰 줄바꿈된다. 세로쓰기를 사용하는 언어의 경우에는 화면의 높이에 맞춰 줄바꿈된다.
텍스트를 확대(줌)하여 읽어야 하는 사용자는 텍스트 재배치 기능 덕분에 큰 이점이 있다. 텍스트 크기에 관계없이 화면에 보이는 범위 내에서 자동으로 줄 바꿈된다. 한 줄 전체가 화면에 표시되므로 시선이 한 줄의 끝에서 다음 줄의 시작 부분으로 자연스럽게 이동하기 쉽다. 사용자는 읽는 방향으로 스크롤하기만 하면 다음 줄을 읽을 수 있다.
이 기준은 예외에 해당되지 않는 콘텐츠 영역이, 가로 방향으로 작성된 경우 320 CSS 픽셀 너비까지 줄어들었을 때에도 재배치되어야 함을 요구한다. 마찬가지로 세로 방향으로 작성된 콘텐츠(웹에서 흔히 사용되지 않으므로 예시에서도 자주 사용되지 않음)는 256 CSS 픽셀 높이까지 줄어든 상태에서도 재배치될 수 있어야 한다.
최신 웹사이트와 애플리케이션은 일반적으로 반응형 웹 디자인 모범 사례를 활용하여 작은 화면 크기에 맞춰 콘텐츠 섹션을 조정하거나 재배치한다. 콘텐츠를 조정하거나 재배치하는 것은 사용자가 콘텐츠에 계속 접근할 수 있는 한 정보나 기능의 손실로 간주하지 않는다. 콘텐츠가 작은 화면 크기에 맞도록 조정되면 모바일 기기 사용자가 콘텐츠를 읽기 쉬울 뿐만 아니라, 더 큰 기기에서 웹 인터페이스 크기를 조정하거나 확대/축소해야 하는 사용자에게도 도움이 된다. 이것이 바로 이 성공 기준의 핵심이다.
많은 기사 기반 웹페이지가 재배치 성공 기준을 충족하는 일반적인 방법은 웹페이지의 표시 방식을 단일 열 콘텐츠에 맞게 조정하여 320 CSS 픽셀 너비의 뷰포트에 맞추고 사용자가 웹페이지 콘텐츠를 읽기 위해 세로 스크롤만 하도록 하는 것이다.
‘콘텐츠를 하나의 세로 열로 쌓는 방식’은 관련 사이드바가 있는 기사나 시각적 그리드 또는 벽돌식 레이아웃(메이슨리 레이아웃)으로 티저 콘텐츠를 구분해서 보여주는 홈페이지처럼, 사람들이 읽을 콘텐츠를 섹션별로 제시하는 것이 주된 목적인 많은 웹페이지에 효과적이다. - 이 경우 해당 레이아웃이 콘텐츠 이해에 필수적인 요소가 아니라면 문제가 없다. 하지만 이러한 방식은 모든 경우에 적합한 것은 아니다. 일반적이지만 복잡한 위젯이나 레이아웃의 경우, 단순히 하나의 세로 열로 쌓아버리면 오히려 시각적으로 이해하거나 상호작용하기 더 어려워질 수 있다.
복잡한 웹 인터페이스를 구축하려면, 콘텐츠가 확대되었을 때 레이아웃 수정, 기능 조정 또는 그 둘 모두가 필요한 복잡한 레이아웃과 위젯을 포함하게 되는 경우가 많다.
이 성공 기준을 준수한다고 해서, 모든 콘텐츠 영역이 작은 뷰포트에서 반드시 하나의 세로 열로 쌓여야 하는 것은 아니다. 또한 모든 콘텐츠 영역이 반드시 한 방향으로만 스크롤되어야 하는 것도 아니다. 각 섹션의 텍스트를 읽기 위해 2차원 스크롤을 할 필요가 없다면 모든 섹션을 한 방향으로 스크롤할 수 있어야 한다.
다음 예시들은 가로 스크롤 없이도 작동하도록 설계될 수 있지만, 성공 기준에 적합함을 보여주기 위해 설계되었다.
목록과 코드 블록은 계층 구조와 의미를 시각적으로 전달하기 위해 들여쓰기를 활용하는 경우가 많다. 들여쓰기를 제거하면 의미 전달이나 기능이 손상될 수 있다. 예를 들어, 들여쓰기가 없으면 순서 없는 목록의 계층 구조를 파악하기가 어려워진다. 또한, 들여쓰기와 줄 바꿈 방지 기능을 유지하는 것은 코드 패턴을 이해하는 데 중요할 뿐만 아니라, 코드가 제대로 동작하는 데 반드시 필요하기도 하다.
자세한 내용은 G224: Accounting for meaningful text indentation and Reflow 기법을 참조하라.
세로 스크롤 방식의 웹 페이지에서 캐러셀을 구현하면 콘텐츠를 가로로 스크롤할 수 있다. 캐러셀이 스크롤될 때마다 화면에 보이는 뷰포트 내에 새로운 캐러셀 패널이 표시된다. 캐러셀 내의 각 패널이 320 CSS 픽셀의 뷰포트 내에 들어갈 수 있다면, 사용자는 한 방향으로만 스크롤하여 각 패널의 콘텐츠를 볼 수 있다.
그림 6. 적합: 이 캐러셀은 매물로 나온 주택에 대한 미리보기 콘텐츠를 여러 패널로 보여준다. 캐러셀 컨테이너는 기본 웹 페이지의 세로 스크롤과 관계없이 가로로 스크롤된다. 캐러셀 내의 각 패널은 웹 페이지 콘텐츠의 읽는 방향(위에서 아래로)을 따라 세로로 읽도록 설계되었다. 확대했을 때 각 패널은 320 CSS 픽셀 뷰포트 내에 들어갈 수 있다.
그림 7. 부적합: 이전 캐러셀을 수정한 이 버전에서는 두 번째 패널의 내용이 320 CSS 픽셀 뷰포트 안에 들어가지 않는다 .
자세한 내용은 G225: Section panels that scroll horizontally are designed to fit within a width of 320 CSS pixels on a vertically scrolling page 기법을 참조하라.
코드나 텍스트의 차이점을 나란히 놓고 검토할 수 있는 경우, 스크롤 가능한 2단 레이아웃이 사용자에게 도움이 될 수 있다.
그림 8. 적합: 코드/문서 변경 사항을 검토하는 인터페이스는 원본 콘텐츠와 수정된 콘텐츠를 두 열로 비교하여 보여준다. 각 열은 CSS 픽셀 너비의 320픽셀 컨테이너 안에 맞도록 설계되었으며, 가로 스크롤 막대를 사용하여 각 열을 화면에 보이는 위치에 배치할 수 있다.
다른 보기 방식은 변경된 각 줄을 위아래로 쌓아서 보여주는 것이지만, 두 열로 된 비교 보기는 원본 코드와 수정된 코드 줄을 같은 가로 평면에서 직접 비교할 수 있도록 해준다. 특히 변경 사항이 여러 줄에 걸쳐 있는 경우, 원본 코드와 변경된 코드 블록 사이를 세로로 스크롤해야 하는 번거로움을 줄여주기 때문에 일부 사용자에게는 이해하기 쉬울 수 있다.
대부분의 기존 웹 페이지는 페이지의 주요 목적이 여러 줄의 문단 텍스트를 포함한 서로 구분되는 콘텐츠 영역을 사용자가 읽는 데 있다. 이러한 웹페이지는 일반적으로(서구권 언어 기준으로 작성된 경우) 세로 방향으로 스크롤된다. 시력이 좋지 않은 사용자는 콘텐츠를 읽기 위해 웹 페이지를 확대해야 할 수 있다. 브라우저의 확대/축소 기능을 사용하면 콘텐츠는 커지지만 반대로 뷰포트의 크기는 작아진다.
모든 콘텐츠가 정보나 기능 저하 없이 더 작은 뷰포트에 완벽하게 재배치될 수 있는 것은 아니다. 앞서 언급했듯이 표 형식 데이터, 그래픽, 지도, 프레젠테이션, 사용을 위해 고정된 도구 모음이 필요한 인터페이스, 그리고 이해도, 기능성 또는 둘 다를 위해 관련 콘텐츠 섹션의 일관된 방향이 중요한 2차원 레이아웃 등이 이에 해당한다.
콘텐츠의 특정 부분이 2차원 스크롤링 예외 조건에 충족하더라도, 해당 예외 조건은 그 영역에만 적용된다. 콘텐츠의 특정 영역이 재배치 예외로 인정되더라도, 이해나 기능 구현에 2차원 스크롤링이 필요하지 않은 다른 콘텐츠까지 자동으로 예외 조건이 적용되는 것은 아니다.
그림 9. 부적합: 이 예제의 구현 방식 때문에 웹 페이지에 가로 및 세로 스크롤 막대가 모두 나타난다. 표 자체는 이해를 돕기 위한 2차원 레이아웃 예외를 충족하지만, 스크린샷에서 표 다음에 나오는 단락들은 그렇지 않다.
데이터 테이블은 이해를 위해 2차원 레이아웃에 의존하지만, 스크롤 가능한 컨테이너에 테이블을 표시하면 2차원 레이아웃 예외를 충족하지 않는 다른 콘텐츠도 포함하는 요소의 조정(예: 브라우저 크기 조정 또는 확대/축소)에 따라 재배치될 수 있다.
그림 10. 적합: 표 형식 데이터는 재배치 예외에 해당된다. 표를 포함하는 요소에 최소 높이, 너비 또는 둘 다를 지정하고, 해당 요소에 양방향 스크롤바를 제공하도록 스타일을 적용할 수 있다. 이렇게 하면 사용자는 표의 내용을 스크롤해서 볼 수 있고, 페이지 전체 수준에서 가로-세로 스크롤바가 생기는 문제를 완화할 수 있다. 왼쪽 그림은 기본 확대 상태의 웹페이지로 사용자가 접근할 수 있는 파일을 나타내는 4열짜리 표를 보여준다. 오른쪽 그림은 페이지를 확대했을 때 표가 별도의 포함 요소 안에서 자체 양방향 스크롤바를 가진 상태로 렌더링되는 모습을 보여준다.
예외가 인정되는 2차원 콘텐츠가 뷰포트를 넘어가는 경우가 있을 수 있으며, 이로 인해 페이지 전체에 스크롤이 생길 수 있다. 동시에 같은 페이지 내의 다른, 예외가 아닌 콘텐츠는 뷰포트 안에서 정상적으로 재배치될 수도 있다. 이전의 “표 아래 문단이 재배치되지 않았던 부적합 사례”와는 달리, 이러한 상황은 성공 기준에 적합하다. 재배치는 개별 콘텐츠 영역에서 가로·세로 양방향 스크롤바를 사용하는 것을 금지하지 않는다. 또한 예외 콘텐츠를 표시하기 위해 페이지(뷰포트) 수준에서 양방향 스크롤바를 사용하는 것도 금지하지 않는다. 단, 예외가 아닌 콘텐츠는 스크롤만 요구한다.
가능하다면, 양방향 스크롤은 해당 스크롤이 꼭 필요한 개별 콘텐츠 영역에만 제한하는 것이 사용자에게 가장 바람직하다. 페이지 전체가 양방향 스크롤되는 방식은 권장되지 않는다. 예를 들어, 불필요한 가로 스크롤바가 있으면 사용자는 화면 밖에 더 많은 콘텐츠가 있다고 오해할 수 있다. 하지만 실제로는 단 하나의 예외 콘텐츠 때문에 가로 스크롤이 생긴 것일 수 있으며, 사용자는 재배치되지 않은 다른 콘텐츠를 찾느라 불필요한 노력을 하게 된다.
그림 11. 적합: CSS 속성(max-width: 100%)이 적용되지 않은 비디오 플레이어는 화면이 작아지거나 확대된 뷰포트에서도 전체 크기를 유지한다. 페이지의 나머지 콘텐츠는 320 CSS 픽셀 너비 컨테이너 안에서 정상적으로 재배치된다. 따라서 페이지 수준에서 큰 가로 스크롤바가 존재하지만, 이는 재배치 예외 대상인 비디오 플레이어 때문에 발생한 것이다. 이전의 표 예시처럼 문단이 화면 밖으로 벗어나 읽기 위해 양방향 스크롤이 필요했던 경우와 달리, 이번 사례는 예외가 아닌 모든 콘텐츠가 정상적으로 재배치되므로 성공으로 간주된다. 하지만 이것이 최상의 사용자 경험을 제공하는 것은 아니다. 이상적으로는 비디오 플레이어의 스타일을 수정하여 불필요한 가로 스크롤바가 생기지 않도록 개선하는 것이 바람직하다.
그림 12. 적합: CSS 속성(max-width: 100%)이 적용된 비디오 플레이어는 영상이 컨테이너 요소의 너비 안에 맞춰서 표시된다. 그 결과 페이지에 가로 스크롤바가 더 이상 나타나지 않으며, 사용자가 비디오 외에 다른 콘텐츠가 화면 밖에 존재한다고 오해할 가능성도 줄어든다.
그래픽과 비디오는 본질적으로 2차원 콘텐츠이다. 그래픽(사진, 그림, 차트 등)을 잘게 나누어 세로로 쌓아 표시하면, 내용을 이해하기 어려워지거나 심한 경우 알아볼 수 없게 될 수 있다. 하지만 다른 콘텐츠가 400%까지 확대되더라도, 이러한 요소들을 뷰포트 범위 안에 유지되도록 만드는 것은 가능하다.
자세한 내용은 권고 기법 C37: Using CSS max-width and height to fit images를 참고하라.
데이터 테이블과 그리드는 열 헤더와 행 헤더, 그리고 데이터 셀 사이에 2차원적인 관계를 가진다. 따라서 이 성공 기준은 데이터 테이블과 그리드에 대해, 텍스트 방향으로 스크롤 없이 표시되어야 한다는 요구사항의 예외를 인정한다. 하지만 개별 셀은 여전히 재배치 기준을 충족해야 한다. 단, 해당 셀 안의 콘텐츠 자체가 사용이나 의미 전달을 위해 2차원 레이아웃이 필요한 경우는 예외가 될 수 있다.
표와 그리드에 대한 예외는 일반적으로 생각하는 “표 형식 데이터”를 넘어서는 콘텐츠에도 적용된다. 예를 들어, “전자 프로그램 가이드”는 온라인 스트리밍 미디어 프로그램을 표시하기 위해 사용되는 일종의 그리드이다. 이러한 프로그램 가이드는 그리드 기반 레이아웃 외의 다른 콘텐츠와 함께 제공될 수도 있다. 프로그램 가이드의 개별 셀 안에 포함된 시청 방법 정보나 포스터 이미지는 요구되는 너비 또는 높이 안에 맞도록 표시되어야 한다.
표나 그리드와 관련된 다른 콘텐츠들, 예를 들어 앞에 위치한 제목, 검색 필드, 또는 다른 데이터 집합을 불러오기 위한 페이지네이션은 재배치 예외 대상이 아니다. 예를 들어, 표 자체는 이해 가능성을 유지하기 위해 양방향 스크롤이 필요할 수 있다. 하지만 표를 소개하는 제목이나 문단, 또는 사용자가 다른 표 데이터를 검색하거나 페이지를 이동하기 위해 사용하는 검색 필드와 페이지네이션 컴포넌트에는 이러한 예외가 확장 적용되지 않는다. 이러한 요소들은 여전히 작은 뷰포트에 맞게 조정되어야 하며, 사용자가 예외가 아닌 콘텐츠를 찾거나 조작하기 위해 불필요하게 UI를 스크롤해야 하는 상황을 줄여야 한다.
그림 13. 부적합: 왼쪽의 표는 자체적인 스크롤 가능한 컨테이너 안에서 렌더링되지 않았다. 이 인터페이스 구현은 사용자가 내용을 읽기 위해 확대해야 하는 상황과, 그에 따른 작은 뷰포트 환경에 대한 적응을 고려하지 않았다. 그 결과, 전체 뷰포트를 이동하기 위한 양방향 스크롤바가 사용되었고, 일부 콘텐츠는 제대로 표시되지 않아 사용이 매우 어렵거나 사실상 불가능해졌다.
적합: 오른쪽의 표는 앞에 제목과 검색 입력이 있고, 표 아래에는 페이지네이션 컴포넌트가 있으며, 이들 모두는 보이는 뷰포트 안에 적절히 표시된다. 표는 재배치 예외 대상이며, 스크롤 가능한 컨테이너 안에서 렌더링된다. 반면 제목과 페이지네이션은 예외 대상이 아니므로, 확대된 뷰포트 안에서도 맞게 표시되도록 조정되었다.
콘텐츠를 편집하기 위한 툴바를 제공하는 인터페이스는, 콘텐츠와 툴바를 모두 뷰포트 안에서 보여줄 필요가 있다. 툴바 버튼의 수에 따라, 툴바는 텍스트 방향으로 스크롤이 필요할 수도 있으며, 경우에 따라서는 편집 대상인 리치 텍스트 콘텐츠 또는 편집 캔버스 영역과 함께 스크롤되면서 항상 완전히 보이는 상태를 유지해야 할 수도 있다.
그림 14. 적합: 사진 편집 인터페이스는 고정 크기의 캔버스 영역과, 편집 가능한 이미지 캔버스를 조작하기 위한 고정형 툴바, 패널, 그리고 대화상자를 제공한다. 패널과 대화상자는 크기 조절이 가능하며, 320 CSS 픽셀 너비의 뷰포트 안에 맞도록 조정할 수 있다.
복잡한 웹 애플리케이션 인터페이스는 사용자가 특정 크기에 맞춰 콘텐츠를 생성할 수 있도록 한다. 예를 들어 프레젠테이션이나 문서는 실제 인쇄 크기나 화면 표시 크기를 기준으로 만들어질 수 있다. 또한 복잡한 인터페이스는 사용자가 만든 주요 콘텐츠와 직접 관련되어 있지만, 그 자체는 주요 콘텐츠의 일부가 아닌 콘텐츠를 함께 제공하는 경우가 많다. 예를 들면 발표 노트, 문서 편집 댓글/제안, 채팅 인터페이스와 함께 표시되는 동적 메시지 등이 있다. 이러한 관련 콘텐츠 영역들은 서로 나란히 표시되어야 하는 경우가 많으며, 이들의 전체적인 위치 관계가 변경되면 이해 가능성이 저하될 수 있다.
그림 15. 서식 있는 텍스트 문서는 실제 인쇄 시 페이지 형식에 맞춰 높이와 너비로 표시된다. 일부 텍스트는 강조 표시되어 있으며, 해당 텍스트에는 주석이 연결되어 있음을 나타낸다. 이 댓글(관련 콘텐츠 영역)은 서식있는 텍스트 문서 옆의 별도 열에 위치한다. 이 댓글은 편집 인터페이스의 일부로만 존재하기 때문에, 특정 높이나 너비를 유지할 필요는 없다. 따라서 주석 영역은 320 CSS 픽셀 너비의 뷰포트 안에 맞도록 재배치되어야 하는 반면, 서식있는 텍스트 문서는 필요한 높이와 너비를 유지할 수 있다.
만약 댓글을 문서 텍스트 안에 인라인으로 렌더링한다면, 인쇄 크기를 기준으로 하는 레이아웃 표현 자체가 변경될 수 있다. 댓글은 문서 작성자를 위한 것이며, 실제 인쇄 대상은 아니기 때문이다.
사용자가 서식있는 텍스트 문서와 댓글 열 사이를 가로로 이동할 수 있도록 하기 위해서는 양방향 스크롤바가 필요하게 된다.
마지막으로, 사용자가 직접 만든 프레젠테이션의 생성 또는 표시를 다루는 인터페이스(예: 슬라이드 덱 작성 또는 발표 인터페이스)는 단순히 콘텐츠를 재배치할 수 없는 경우가 많다. 왜냐하면 그렇게 할 경우 작성자가 의도한 콘텐츠 표현 방식이 쉽게 깨질 수 있기 때문이다.
대신에, 이러한 인터페이스는 콘텐츠 작성자에게 이 성공 기준을 충족하는 대체 표현을 만들 수 있는 수단을 제공하는 것이 기대된다.
세로로 스크롤되는 콘텐츠에 대해 320 CSS 픽셀이라는 값이 선택된 이유는, 작성자들이 현실적으로 구현 가능한 합리적인 최소 크기라고 판단되었기 때문이다. 이 값은 해당 성공 기준이 처음 작성되던 당시 널리 사용되던 소형 모바일 기기들의 보고된 뷰포트 너비와도 일치했다. 320 CSS 픽셀은 일반적으로 너비가 1280 픽셀로 설정된 데스크톱 브라우저 창에서 뷰포트를 400% 확대했을 때와 같다. 여기서 400%는 면적이 아닌 크기를 나타내는 값이다. 즉, 기본 확대 수준의 뷰포트 너비와 높이의 네 배를 의미한다.
그림 16. 서로 다른 해상도를 가진 디스플레이에서 동일한 CSS 픽셀 크기의 문자
우리가 글을 읽을 때 중요한 것은 인쇄물의 실제 물리적 크기 자체가 아니라, 그것이 눈의 망막에 투사하는 이미지의 크기이다. 휴대전화는 가까운 거리에서 보기 위해 설계되고, 데스크톱은 더 먼 거리에서 보기 위해 설계된다. 그 결과, 휴대전화에서의 16 픽셀 글자는 데스크톱에서의 16 픽셀 글자보다 물리적으로 더 작다. 하지만 이는 일반적으로 문제가 되지 않는다. 왜냐하면 각각 의도된 거리에서 볼 경우, 두 글자는 우리의 망막에 거의 동일한 크기의 이미지를 투사하기 때문이다. 웹에서 사용하는 CSS 참조 픽셀, 즉 px 단위는 이러한 개념을 반영한다. CSS의 참조 단위는 길이 단위가 아니라 시야각(1.278 arc minutes) 기준이다. 많은 고령자나 일부 저시력 사용자는 일반적인 사용자보다 휴대전화를 더 가까이 들고 본다. 하지만 CSS 참조 픽셀을 사용함으로써 개발자(그리고 디자이너 및 콘텐츠 작성자)는 설계 선택에 대해 안정적인 기준(metric)을 가질 수 있다.
기술과 사용자들의 기술 사용 방식이 발전함에 따라, 재배치 준수 여부는 더 이상 이 성공 기준의 크기 요구사항과 정확히 일치하는 특정 해상도나 브라우저 확대 수준이 존재하는지에 관한 문제가 아니다. 오히려 중요한 것은, 콘텐츠 영역이 이 성공 기준의 크기 요구사항에 해당하는 수준의 뷰포트 안에서 표시될 수 있어야 한다는 점이다. 예를 들어, 어떤 사용자는 브라우저 창을 디스플레이의 절반 크기로 도킹하여 사용할 수 있으며, 이 경우 뷰포트 너비는 960 CSS 픽셀이 될 수 있다. 이 상태에서 사용자가 브라우저를 300% 확대하면, 결과적으로 너비 320 CSS 픽셀의 뷰포트를 얻게 된다.
또한 재배치의 혜택을 받을 수 있는 모든 사용자가, 재배치 성공 기준의 크기 요구사항(320 픽셀 또는 256 픽셀)에 정확히 맞아떨어지는 화면 해상도에서 웹페이지를 보는 것은 아니다. 실제로는 운영체제의 디스플레이 해상도와 브라우저의 뷰포트 크기가 정확히 일치하지 않는 경우가 일반적이다. 예를 들어, 데스크톱 컴퓨터의 화면 해상도를 1280×1024 픽셀로 설정하더라도, 운영체제 UI와 브라우저 UI가 화면 공간의 일부를 차지하기 때문에 실제 브라우저 뷰포트는 이보다 더 작아진다. 또한 일부 운영체제에서는 확대 수준과 관계없이 320 CSS 픽셀 또는 256 CSS 픽셀 크기로 정확하게 나누어 떨어지는 화면 해상도를 제공하지 않을 수도 있다.
그림 17. 1280×1024 픽셀 해상도의 노트북에서 브라우저 창이 표시되어 있다. 웹페이지는 400% 확대된 상태이다. 하지만 운영체제의 작업표시줄을 자동 숨김으로 설정하고, 브라우저 UI도 최소한만 표시하고 있음에도 불구하고, 뷰포트는 이 차이를 이해하지 못한 상태에서 예상하는 것보다 더 작다. 페이지의 세로 스크롤바를 표시해야 하기 때문에 뷰포트 너비는 318픽셀이다. 또한 브라우저의 탭과 주소창 UI가 자체적으로 세로 공간을 차지하기 때문에, 뷰포트 높이는 236픽셀이다.
재배치를 지원할 수 있게 하는 중요한 요소 중 하나는, 사용자 에이전트가 콘텐츠가 표시되는 특정 창 안에서 콘텐츠를 조정할 수 있도록 허용하는 것이다. 최소한 창 자체의 크기 조절이 가능하지 않더라도 말이다. 재배치가 처음 작성되었을 당시에는, 대부분의 모바일 운영체제 브라우저가 콘텐츠 확대와 재배치를 전통적인 데스크톱 브라우저와는 다르게 처리했다. 예를 들어, 모바일 기기의 화면 방향이 변경될 때에만 웹페이지 콘텐츠가 재배치되는 경우가 있었다. 이는 당시 많은 모바일 브라우저에서 웹페이지 확대가 사실상 확대경 기능에 가까웠기 때문이다. 즉, “핀치 줌” 제스처나 더블 탭 확대는 웹페이지 콘텐츠 자체를 재배치하는 것이 아니라 단순히 확대했으며, 사용자는 확대된 화면 위를 스와이프하거나 드래그하여 일부 영역만 볼 수 있었다.
오늘날에는, 모바일 기기나 사용자가 애플리케이션을 고정된 크기(예: 전체 화면 또는 분할 화면)로 열 수 있는 다른 기기들의 브라우저들이, 전통적인 데스크톱 브라우저 확대 방식과 더 유사한 배율 조정 기능을 제공하는 경우가 많아졌다. 또는 이러한 기기들은 운영체제 수준에서 확대 기능을 제공하여, 최소한 어느 정도는 웹페이지 콘텐츠가 재배치될 수 있도록 지원하기도 한다. 하지만 이러한 기능들 중 상당수는 일반적으로 세로 스크롤 콘텐츠에 대해 320 CSS 픽셀 너비, 가로 스크롤 콘텐츠에 대해 256 CSS 픽셀 높이까지 브라우저 뷰포트를 조정하지는 않는다.
고정 크기 브라우저를 이 성공 기준에서 사용하는 320 CSS 픽셀 또는 256 CSS 픽셀 크기로 조정할 수 없는 상황을 사용자 에이전트 지원 문제로 볼 수도 있다. 하지만 이 성공 기준의 의도는 기기들이 반드시 이러한 특정 크기를 지원하도록 요구하는 것도 아니다. 특정 기기에서 콘텐츠를 이러한 크기로 표시할 수 없다는 이유만으로 웹페이지가 재배치를 통과하거나 실패한다고 판단하는 것도 아니다. 만약 어떤 웹페이지가 이 성공 기준의 크기 요구사항을 정확하게 테스트할 수 있는 기기에서 열람 가능하다면, 그와 같은 기기에서 해당 웹페이지가 재배치를 충족하는지를 판단하는 것이 가장 적절하다.
웹페이지의 재배치를 검토하는 과정에서 다른 WCAG 성공 기준과 관련된 문제가 발견될 수 있다. 다음은 다른 성공 기준과의 잠재적 중복 사례이며, 모든 중복 기준이 나열된 것은 아니다.
재배치 성공 기준의 목적은, 사용자가 웹 페이지의 크기를 조정하거나 확대할 수 있도록 하고 콘텐츠 섹션 내의 텍스트를 양방향 스크롤 없이 읽을 수 있도록 보장하는 데 있다. 성공 기준 1.4.4 텍스트 크기 조정은 이러한 목표와 겹치는 부분이 있다. 왜냐하면 모든 텍스트를 최소 200%까지 확대하더라도 동시에 재배치를 충족할 수 있어야 하기 때문이다.
참고
웹 페이지를 200% 확대했을 때 뷰포트 크기가 재배치의 크기 요구 사항보다 작아지면 2차원 스크롤이 발생할 수 있다. 이는 뷰포트 크기가 재배치에서 요구하는 크기보다 작기 때문에 발생하는 현상으로, 재배치 자체의 오류는 아니다.
많은 웹페이지에서는 브라우저 확대가 증가함에 따라 페이지의 텍스트도 계속 커지는 것이 기대된다. 따라서 사용자는 텍스트를 400% 이상까지 확대할 수 있어야 한다. 하지만 어떤 구현에서는, 작은 화면에 적응하기 위해 미디어 쿼리를 사용하면서 사용자가 확대하더라도 텍스트 크기가 계속 비례해서 증가하지 않을 수 있다. 이러한 경우에도 텍스트 크기 조정 성공 기준을 충족하려면, 최소한 200% 확대는 가능해야 한다. 중요한 점은, 재배치의 의도가 일반적으로 텍스트 확대를 수반하기는 하지만, 재배치 자체가 특정 텍스트 크기 확대 수준에 도달해야 한다고 요구하는 것은 아니라는 점이다. 심지어 어떤 경우에는 일부 텍스트가 지나치게 커지는 것을 방지해야 할 수도 있다. 그렇게 함으로써 원하지 않는 2차원 스크롤이 발생하는 것을 줄일 수 있다.
예를 들어, 기본 브라우저 확대 수준에서 창 너비가 1280 CSS 픽셀일 때 텍스트 크기가 20 픽셀로 설정되어 있다고 가정하자. 이 상태에서 200% 확대를 하면, 텍스트는 시각적으로 두 배 크기로 보이게 된다. 그 후 400% 확대를 하여 페이지가 320 CSS 픽셀 뷰포트 안에 맞게 재배치되었을 때, 작성자는 페이지의 텍스트 크기를 10 픽셀로 설정하기로 결정할 수 있다. 이 경우 텍스트는 CSS 픽셀 기준으로는 원래 크기의 절반이 되었지만, 페이지 자체가 400% 확대된 상태이므로 결과적으로는 여전히 기본 100% 확대 상태와 비교했을 때 두 배 크기로 표시된다. 특정 중단점(breakpoint) 안에 머무르면서 반드시 200% 텍스트 확대를 달성해야 하는 것은 아니다. 왜냐하면 확대 과정에서 새로운 중단점(breakpoint)용 레이아웃 변형이 활성화될 수 있기 때문이다. 하지만 어떤 방식으로든 기본 100% 확대 상태와 비교하여 200% 텍스트 확대는 가능해야 한다.
콘텐츠 영역이 큰 뷰포트에서는 고정 위치(fixed position) 또는 스티키(sticky) 방식으로 설계되어 있는 경우, 작성자는 이러한 스티키 콘텐츠가 키보드 포커스를 가진 요소를 완전히 가리지 않도록 해야 한다. 또는 작성자가 만든 콘텐츠가 다른 콘텐츠를 가리는 경우에는, 사용자가 키보드 포커스를 이동시키지 않고도 해당 가림 요소를 닫거나 해제할 수 있는 방법이 있어야 한다. 이러한 스티키 또는 고정 콘텐츠는 재배치의 혜택을 필요로 하는 사용자들에게 심각한 문제를 일으킬 수 있다. 왜냐하면 이러한 요소들은 키보드 포커스를 가리는 것뿐만 아니라, 콘텐츠 읽기 자체를 어렵게 만들거나 심지어 불가능하게 만들 수도 있기 때문이다.
예를 들어, 어떤 웹사이트의 콘텐츠는 320 CSS 픽셀 너비의 뷰포트 안에 맞게 정상적으로 재배치된다. 하지만 해당 웹사이트는 고정 위치 광고도 함께 표시한다. 이 광고들은 큰 뷰포트에서는 일반적으로 웹페이지의 하단 구석에 표시된다. 그러나 페이지를 확대하려고 하면, 광고는 계속 고정된 위치에 남아 있게 된다. 이로 인해 페이지에서 초점을 받아야 하는 요소들이 가려져 광고 닫기 버튼을 찾거나 키보드로 이동하지 않고는 광고를 닫을 수 없을 뿐만 아니라, 읽을 수 있는 공간도 크게 줄어든다.
그림 18. 고정 위치의 광고는 키보드 초점을 가진 링크를 가릴 뿐만 아니라, 웹페이지 콘텐츠를 읽을 수 있는 공간 자체를 크게 제한한다.
그림 19. 광고를 정적인 위치로 변경함으로써, 재배치된 웹페이지 콘텐츠를 정상적으로 읽을 수 있게 되었다. 또한 광고는(이 스크린샷에는 보이지 않지만) 페이지를 스크롤할 때 여전히 볼 수 있다.
참고
이 스티키 방식 광고 예시 외에도, 툴바, 메뉴바, 내비게이션, 그리고 기타 “사이드바” 콘텐츠는 큰 뷰포트에서는 스티키 또는 고정 위치로 표시되는 경우가 흔하다. 작은 뷰포트에서는 이러한 컴포넌트들을 정적인 위치로 변경하거나, 사용자가 표시 여부를 토글할 수 있도록 만드는 것이 강력히 권장된다. 이렇게 하면 확대된 콘텐츠를 사용자가 읽을 수 있도록 도와줄 수 있다. 왜냐하면 스티키 방식 컴포넌트가 더 이상 웹페이지 콘텐츠를 가리지 않게 되기 때문이다.
반응형 디자인에서의 단일 컬럼 뷰
확대 비율이 증가함에 따라, 내비게이션은 먼저 일부 옵션들을 “더보기” 드롭다운 메뉴 안으로 숨기도록 변경된다. 확대가 계속 진행되면, 대부분의 내비게이션 옵션은 결국 “햄버거” 메뉴 버튼 안으로 들어가게 된다. 하지만 이 웹페이지의 모든 정보와 기능은 여전히 접근 가능하다. 그리고 가로 스크롤은 발생하지 않는다.
재배치를 제공하는 PDF
PDF/Universal Accessibility(ISO 14289)를 준수하도록 제작된 PDF에서는, 콘텐츠를 재배치하고 확대할 수 있어서 저시력 사용자가 읽을 수 있도록 할 수 있다.
콘텐츠 잘림 대신 사용할 수 있는 대안적인 표현 방식
어떤 웹페이지는 공간을 절약하기 위해 긴 문자열을 잘라서 표시할 수 있다. 예를 들면 인터페이스 디자인에서 할당된 공간 안에 맞지 않는 사용자 생성 콘텐츠, 줄바꿈되지 않는 인증키, 기타 매우 긴 문자열 등이 있다. 이러한 콘텐츠는 잘린 상태로 표시될 수 있지만, 잘리지 않은 전체 콘텐츠를 볼 수 있는 별도의 웹페이지로 연결되는 링크를 제공하거나, 현재 웹페이지 안에서 잘린 콘텐츠를 펼쳐서 볼 수 있는 메커니즘이 제공되어야 한다.
의미를 가지고 있는 형태의 텍스트
레이아웃 자체가 특정 의미를 가지는 텍스트 표현 방식이 있다. 예를 들어 Python 코드의 들여쓰기, ASCII 아트 등이 있다. 이러한 경우에는 레이아웃이 올바르게 표현되지 않으면 의미 자체가 사라질 수 있다. 따라서 이 성공 기준은 그러한 의미가 손실되는 경우에는 적용되지 않는다. 하지만 대부분의 일반 텍스트는 줄바꿈을 적용하더라도 의미 손실 없이 표현될 수 있다. 또한 의미를 전달하는 들여쓰기의 경우에는, 확대된 상태에서는 들여쓰기 크기를 줄이는 것도 고려할 수 있다. 텍스트 자체가 더 커져 있기 때문에, 들여쓰기 폭이 줄어들더라도 충분히 구분되어 보일 수 있기 때문이다.
자료는 정보 제공 목적으로만 제공되며 보증을 암시하지 않는다.
이 섹션의 각 번호가 매겨진 항목은 접근성 지침 실무 그룹이 이 성공 기준을 충족하기에 충분하다고 판단하는 기법 또는 기법의 조합을 나타낸다. 기법은 기준의 최소 요구 사항을 넘어설 수 있다. 이러한 기법에서 포괄하지 않은 기준 충족의 다른 방법이 있을 수 있다. 다른 기법 사용에 대한 정보는 WCAG 성공 기준에 대한 기법 이해, 특히 “기타 기법” 섹션을 참조하라.
준수를 위해 필수는 아니지만 콘텐츠에 더 쉽게 접근할 수 있도록 다음과 같은 추가 기법을 고려해야 한다. 모든 기법을 사용할 수 없거나 모든 상황에서 효과적인 것은 아니다.
다음은 접근성 지침 실무 그룹에서 이 성공 기준의 실패로 간주하는 일반적인 실수이다.
다음은 이 성공 기준의 특정 측면에 대한 점검 규칙이다. WCAG 준수 여부를 확인하기 위해 이러한 특정 점검 규칙을 사용할 필요는 없지만 이것은 정의되고 승인된 검사 방법이다. 점검 규칙 사용에 대한 자세한 내용은 WCAG 성공 기준에 대한 점검 규칙 이해를 참고하라.
