정적 사이트 접근성 점검: 키보드·모바일·다크 모드

브라우저와 이 페이지부터 준비합니다

쭈니박스는 HTML 문서와 공용 스타일시트로 구성되어 있습니다. 다음 예제는 이 사이트의 코드를 바탕으로 합니다. 별도 라이브러리를 설치하지 않고도 문서의 순서와 CSS만으로 적용할 수 있는 부분입니다.

먼저 이 글을 새 탭으로 열고 브라우저 확대를 100%로 맞춥니다. 키보드 점검 때는 개발자 도구를 닫아 페이지와 도구 사이의 포커스 이동이 섞이지 않게 합니다. 아래 단계에서 말하는 “기대 결과”는 직접 비교할 기준이며, 모든 브라우저와 보조 기술에서의 동작이나 접근성 인증을 뜻하지 않습니다.

1. Tab을 눌렀을 때 현재 위치가 보이나요?

마우스를 올렸을 때 색이 변하는 것만으로는 키보드 이용자가 다음에 어느 링크를 열게 될지 알 수 없습니다. 이 사이트는 링크와 입력 요소에 포커스가 표시될 때 3px 윤곽선을 그립니다. 다음은 공용 CSS에 있는 규칙입니다.

:where(a, button, input, textarea, select, summary, pre, [tabindex]):focus-visible {
  outline: 3px solid var(--focus-ring);
  outline-offset: 3px;
}

윤곽선 색은 테마별 --focus-ring 변수에서 가져옵니다. 테두리와 달리 outline은 요소의 크기를 늘리지 않아 이동할 때 배치가 흔들리지 않습니다. 다만 부모 요소가 넘치는 부분을 숨기면 윤곽선도 잘릴 수 있으므로 규칙의 존재와 화면에서 보이는 결과를 함께 확인합니다. 포커스 위치가 계속 보여야 한다는 기준은 W3C의 Focus Visible 해설에서 확인할 수 있습니다.

이 페이지에서 확인하는 순서

주소창에 이 페이지 주소를 입력해 다시 연 뒤 Tab을 누릅니다. 페이지 안에 처음 들어온 포커스는 “본문 바로가기” 링크에 보여야 합니다.
계속 Tab을 눌러 브랜드, 주요 메뉴, 작성자 링크와 목차로 이동합니다. 현재 링크를 눈으로 찾을 수 있어야 합니다.
목차의 “320px 화면과 확대 상태에서 읽기”에서 Enter를 누릅니다. 해당 제목으로 이동해야 합니다.
Shift+Tab으로 반대 방향으로도 이동합니다. 어느 지점에서도 키보드로 빠져나오지 못하는 상태가 없어야 합니다.

실패한다면 먼저 outline: none 같은 덮어쓰기, 잘리는 윤곽선, 클릭만 처리하는 일반 요소를 찾습니다. 이동은 a href, 동작은 button으로 구현하면 브라우저가 기본 키보드 동작을 제공합니다. 양수 tabindex로 순서를 억지로 조정하기보다 HTML의 읽는 순서를 화면의 순서와 맞추는 편이 유지하기 쉽습니다.

여러 글을 읽을 때마다 홈·프로젝트·제작 노트 메뉴를 모두 통과하는 일은 불편합니다. 페이지 앞의 본문 바로가기 링크와 본문의 id를 연결하면 이 반복을 줄일 수 있습니다. 이 페이지도 다음처럼 연결되어 있습니다.

<a class="skip-link" href="#main-content">본문 바로가기</a>
<!-- 공통 헤더와 메뉴 -->
<main id="main-content" class="page-shell">
  <!-- 해당 페이지 본문 -->
</main>

공용 CSS는 이 링크를 평소에는 위로 올려 두고 포커스를 받으면 나타나게 합니다. display: none으로 없애면 키보드로도 도달하지 못하므로 다른 방식이 필요합니다. 여기서 선택한 부분만 추리면 다음과 같습니다.

.skip-link {
  position: absolute;
  transform: translateY(-110%);
}
.skip-link:focus-visible {
  transform: translateY(0);
}

새로 연 페이지에서 첫 링크에 도달한 뒤 Enter를 누르고 다시 Tab을 눌러 보세요. 화면은 본문 시작으로 이동하고 다음 탐색은 본문 안에서 이어져야 합니다. 스크롤만 내려가고 Tab이 다시 상단 메뉴로 돌아간다면 링크의 대상 id와 실제 포커스 이동을 점검합니다. 스크린 리더에서는 main 같은 문서 영역과 제목 계층도 별도로 살펴볼 수 있습니다. W3C의 Bypass Blocks 해설은 반복되는 내용을 건너뛸 수단이 필요한 이유를 설명합니다.

3. 320px 화면에서도 문장이 끝까지 읽히나요?

넓은 모니터에서 보이는 작은 글씨를 키우면, 메뉴가 겹치거나 긴 URL 하나가 페이지 전체를 옆으로 밀어낼 수 있습니다. 작은 화면 점검과 확대 점검을 함께 해야 하는 이유입니다. 쭈니박스는 760px 이하에서 카드들을 한 열로 바꾸고 주요 메뉴가 다음 줄로 흐르도록 합니다. 공용 CSS의 관련 선언을 추렸습니다.

@media (max-width: 760px) {
  .site-nav {
    flex-wrap: wrap;
    max-width: 100%;
    overflow: visible;
  }
  .content-grid,
  .grid,
  .contact-grid {
    grid-template-columns: 1fr;
  }
}

화면 폭과 확대를 따로 확인합니다

Windows Chrome에서 F12로 개발자 도구를 열고 상단의 Toggle device toolbar(기기 툴바 전환) 버튼을 누릅니다. Responsive를 선택하고 너비를 320으로 설정합니다.
제목, 목차, 마지막 문단까지 읽습니다. 본문 줄의 끝을 보기 위해 페이지 전체를 좌우로 끌어야 하거나, 메뉴의 글자가 서로 겹치면 실패입니다.
기기 툴바와 개발자 도구를 닫고, 브라우저 오른쪽 위 메뉴의 확대/축소를 200%로 올립니다. 메뉴를 열고 글을 읽는 데 필요한 내용이 사라지지 않는지 확인합니다.
더 좁아진 배치도 확인하려면 400%까지 확대합니다. 1280 CSS px의 표시 영역을 400%로 확대하면 320 CSS px에 해당합니다. 점검 후 확대를 100%로 돌립니다.

W3C의 Reflow 해설은 세로로 읽는 콘텐츠의 320 CSS px 조건과 지도·일부 표처럼 2차원 배치가 필요한 부분의 예외를 구분합니다. 코드 블록 등 개별 영역의 가로 스크롤과 페이지 전체의 가로 밀림도 구분해서 보세요. 전체에 overflow-x: hidden을 붙이면 잘린 내용을 숨긴 채 문제를 놓칠 수 있습니다.

이 사이트의 주요 메뉴와 독립된 이동 링크는 최소 높이 44px을 사용합니다. 이것은 누르기 쉽게 하기 위한 자체 설계값입니다. 본문 속 모든 링크의 크기나 모든 터치 대상 기준을 한 번에 충족한다는 뜻은 아닙니다. 실제 휴대전화에서는 줄이 바뀐 링크를 눌렀을 때 옆 링크가 잘못 열리지 않는지도 확인합니다.

수정 사례: 화면 밖으로 안 나가도 표를 읽을 수 없었습니다

2026년 9월 22일 이전 가이드의 인수인계 표를 390px 폭으로 확인하면서, 표가 화면 안에 들어가는데도 첫 열의 한글이 한 글자씩 세로로 쌓이는 문제를 발견했습니다. 페이지 전체의 가로 넘침 수치만 보면 놓칠 수 있는 문제입니다. 네 열을 모두 좁은 화면에 욱여넣은 결과, 어떤 항목의 상태와 근거인지 읽기 어려웠습니다.

세 가지 수정 중 표 안의 스크롤을 택한 이유

글씨를 더 작게 만들기: 화면에는 들어가지만 이미 좁은 열을 읽는 부담을 키웁니다.
행을 카드로 바꾸기: 각 항목을 읽기는 편해지지만, 상태·근거·미확인 사항을 열로 비교하기 어려워집니다. 같은 데이터를 두 벌 만들면 갱신 누락도 생길 수 있습니다.
표의 폭을 유지하고 그 부분만 스크롤: 비교 관계를 보존할 수 있습니다. 대신 스크롤 가능성을 알리고 키보드로도 접근할 수 있게 해야 합니다.

이 표는 항목별 상태를 가로로 비교하는 성격이라 마지막을 선택했습니다. 해당 글의 표에 최소 폭 620px을 두고, 감싼 영역에 포커스와 이름을 줬습니다. 620px은 이 표를 읽으며 고른 값이지 접근성 표준의 필수 숫자가 아닙니다.

<!-- 공용 스타일의 overflow-x: auto와 함께 사용 -->
<div class="table-wrap" tabindex="0" role="region"
     aria-label="인수인계 표: 좌우로 스크롤할 수 있습니다">
  <table>…</table>
</div>

/* 이 표의 내용에 맞춘 페이지 전용 설정 */
.article-body table { min-width: 620px; }

수정 뒤 확인한 것과 아직 별개인 것

로컬 미리보기의 320·390·768·1280px 폭과 밝고 어두운 테마에서 페이지 전체가 옆으로 밀리지 않는지 확인했습니다. 좁은 화면에서 표 영역에 키보드 포커스를 둔 뒤 오른쪽 화살표로 표의 스크롤 위치가 변하는 것도 확인했습니다. 표 위에는 좌우로 움직일 수 있다는 안내를 뒀습니다.

이 검사는 화면 낭독기 전체 점검이나 모든 모바일 브라우저의 호환성 인증이 아닙니다. 실제 확인에서는 F12 → 기기 툴바 → Responsive → 너비 390으로 이동한 뒤 표의 첫 열과 마지막 열을 모두 읽어 보세요. 이어 개발자 도구 밖의 페이지에서 Tab으로 영역을 찾아 화살표로 움직입니다. 스크롤바가 보이는지만 확인하지 않고 같은 행의 값들을 비교할 수 있는지 읽는 것이 핵심입니다.

4. 다크 모드는 배경색 하나만 바꾸는 작업이 아닙니다

배경을 어둡게 바꾸고 본문이나 링크 색을 그대로 두면 읽기 어려워집니다. 쭈니박스는 :root와 @media (prefers-color-scheme: dark) 안에서 배경, 본문, 보조 본문, 링크와 포커스 색을 함께 바꿉니다. 다음 수치는 2026년 9월 10일 공용 CSS의 불투명한 본문 색과 기본 배경색을 sRGB 상대 휘도로 계산한 예입니다.

밝은 테마의 본문

--ink-soft: #6f6657
--paper: #fbf7ee

계산된 대비는 약 5.29:1입니다.

어두운 테마의 본문

--ink-soft: #a99f8c
--paper: #171b22

계산된 대비는 약 6.60:1입니다.

W3C의 Contrast (Minimum) 해설은 일반 텍스트의 최소 대비를 4.5:1로 설명합니다. 위 두 조합은 이 값보다 높지만 카드 배경, 버튼, 흐린 글자와 포커스 윤곽선까지 검증한 결과는 아닙니다. 색의 투명도나 겹친 배경이 있다면 실제 합성된 색을 기준으로 따로 확인해야 합니다.

운영체제 설정을 바꾸지 않고 비교하는 경로

Windows Chrome에서 F12 → 개발자 도구 안에서 Ctrl+Shift+P → Show Rendering 검색 후 Enter로 Rendering 패널을 엽니다. Emulate CSS media feature prefers-color-scheme에서 light와 dark를 번갈아 선택하고 페이지를 새로고침합니다. Chrome의 CSS 미디어 기능 에뮬레이션 안내에도 같은 설정이 설명되어 있습니다.

두 설정 모두에서 본문, 날짜, 링크와 코드가 읽혀야 합니다. 이어서 Tab을 눌러 윤곽선이 배경에 묻히지 않는지 봅니다. 마우스를 올리지 않아도 본문 링크를 식별할 수 있어야 하므로 이 글의 링크에는 밑줄도 사용합니다. 점검이 끝나면 No emulation을 선택해 실제 시스템 설정을 따르게 합니다.

5. 움직임 감소 요청이 실제 동작을 바꾸나요?

부드러운 스크롤이나 버튼 이동이 모든 사람에게 편한 것은 아닙니다. MDN의 prefers-reduced-motion 설명처럼 이 미디어 기능은 불필요한 움직임을 줄이려는 사용자 설정을 전달합니다. 이 사이트의 CSS 마지막 부분에는 다음 규칙이 있습니다.

@media (prefers-reduced-motion: reduce) {
  html {
    scroll-behavior: auto;
  }
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
  .cta:hover {
    transform: none;
  }
}

앞에서 연 Chrome Rendering 패널의 Emulate CSS media feature prefers-reduced-motion에서 reduce를 선택합니다.
이 글의 목차 링크를 누릅니다. 긴 부드러운 스크롤 대신 해당 위치로 바로 이동해야 합니다.
홈의 주요 이동 버튼에 마우스를 올립니다. reduce 설정에서는 버튼이 위로 들리는 효과가 없어야 합니다.
본문과 링크는 그대로 이용할 수 있어야 합니다. 동작을 줄였다는 이유로 내용이 사라지면 안 됩니다. 비교 후 No emulation으로 되돌립니다.

운영체제에서도 확인하려면 Windows 11의 시작 → 설정 → 접근성 → 시각 효과 → 애니메이션 효과를 끈 뒤 페이지를 다시 엽니다. 이 CSS는 전환 시간을 아주 짧게 만들지만 모든 transform을 없애거나 JavaScript 애니메이션을 자동으로 중지하지는 않습니다. 움직임이 기능의 일부인 앱에 그대로 복사할 때는 구성요소별 대체 표현과 기능 유지 여부까지 확인해야 합니다.

6. “깨져요” 대신 다시 따라 할 수 있게 남깁니다

문제를 발견하면 주소, 브라우저와 설정, 조작 순서, 기대한 결과, 실제 결과를 함께 기록합니다. 예를 들어 “320px, 100% 확대, 목차의 세 번째 링크에 Tab으로 도달하면 오른쪽 윤곽선이 잘림”은 고칠 위치를 찾기 쉽습니다. 이것은 기록 형식의 예시이며 이 페이지에서 실제로 발견된 결함을 뜻하지 않습니다.

키보드: 포커스가 처음 사라진 요소와 직전 키 입력을 적습니다.
작은 화면: 화면 너비와 확대 비율을 구분하고, 잘린 문구를 적습니다.
색상: 테마와 글자·배경 조합을 함께 남깁니다.
움직임: 운영체제 설정인지 개발자 도구 에뮬레이션인지 적습니다.

이 절차는 정적 글 페이지의 기본 사용성을 살펴보는 출발점입니다. 입력 오류, 영상 자막, 스크린 리더의 읽기 흐름처럼 콘텐츠와 기능에 따라 필요한 점검은 더 있습니다. 이 사이트에서 읽거나 이동하기 어려운 부분은 문의 페이지로 알려 주세요.

예제 코드와 참고 자료

예제 코드와 색상은 쭈니박스 공용 CSS에서 확인할 수 있습니다. 일부 예제는 설명하는 선언만 발췌했습니다. 기준과 도구의 동작은 다음 공식 문서를 2026년 9월 10일 확인했습니다.

접근 가능한 구조가 초기 응답에 포함되어야 하는 이유는 초기 HTML에 본문을 담는 이유에서, 이 기준을 적용한 프로젝트 진입 경로는 프로젝트 목록에서 확인할 수 있습니다.

제작 노트 목록으로 돌아가기

정적 사이트의 접근성 기준

브라우저와 이 페이지부터 준비합니다

1. Tab을 눌렀을 때 현재 위치가 보이나요?

이 페이지에서 확인하는 순서

2. 같은 메뉴를 매번 지나가지 않아도 되나요?

3. 320px 화면에서도 문장이 끝까지 읽히나요?

화면 폭과 확대를 따로 확인합니다

수정 사례: 화면 밖으로 안 나가도 표를 읽을 수 없었습니다

세 가지 수정 중 표 안의 스크롤을 택한 이유

수정 뒤 확인한 것과 아직 별개인 것

4. 다크 모드는 배경색 하나만 바꾸는 작업이 아닙니다

밝은 테마의 본문

어두운 테마의 본문

운영체제 설정을 바꾸지 않고 비교하는 경로

5. 움직임 감소 요청이 실제 동작을 바꾸나요?

6. “깨져요” 대신 다시 따라 할 수 있게 남깁니다

예제 코드와 참고 자료

브라우저와 이 페이지부터 준비합니다

1. Tab을 눌렀을 때 현재 위치가 보이나요?

이 페이지에서 확인하는 순서

2. 같은 메뉴를 매번 지나가지 않아도 되나요?

3. 320px 화면에서도 문장이 끝까지 읽히나요?

화면 폭과 확대를 따로 확인합니다

수정 사례: 화면 밖으로 안 나가도 표를 읽을 수 없었습니다

세 가지 수정 중 표 안의 스크롤을 택한 이유

수정 뒤 확인한 것과 아직 별개인 것

4. 다크 모드는 배경색 하나만 바꾸는 작업이 아닙니다

밝은 테마의 본문

어두운 테마의 본문

운영체제 설정을 바꾸지 않고 비교하는 경로

5. 움직임 감소 요청이 실제 동작을 바꾸나요?

6. “깨져요” 대신 다시 따라 할 수 있게 남깁니다

예제 코드와 참고 자료

관련 글