웹 기초 ·

글자가 흐리고 키보드 위치가 안 보일 때

먼저 답부터

글자가 흐리면 글자와 배경의 밝기 차이인 색 대비를 확인하고, Tab 키로 이동할 때 현재 링크나 버튼에 표시가 보이는지 확인하세요. 일반 글자는 W3C의 4.5대 1 기준을 출발점으로 삼고, 키보드 초점 표시를 지우지 않은 채 실제 화면에서 이동 경로를 살펴봐야 합니다.

글자가 흐리고 키보드 위치가 안 보일 때 대표 이미지

웹페이지를 읽는데 회색 글자가 배경에 묻히면 내용을 알아보는 데 힘이 듭니다. 마우스를 쓰지 않고 Tab 키로 링크를 옮겨 보았는데 현재 어디에 있는지 보이지 않는다면, 다음 행동도 어렵습니다. 이 두 문제는 모두 화면에서 정보를 구별하기 어려운 상태지만 확인할 곳은 다릅니다.

밝은 종이에 아주 연한 연필로 쓴 메모는 가까이 가야 읽힙니다. 또 여러 장의 메모 중 지금 읽는 장에 손가락이나 책갈피가 없으면 순서를 잃기 쉽습니다. 웹에서는 글자와 배경의 차이가 첫 문제를, 키보드로 선택한 위치를 보여 주는 표시가 둘째 문제를 맡습니다.

색 대비는 글자와 배경의 밝기 차이다

색 대비는 앞에 놓인 글자와 뒤의 바탕이 얼마나 구별되는지를 수치로 나타낸 것입니다. 파란색과 빨간색처럼 색 이름이 다른지만 보는 값은 아닙니다. 같은 회색이라도 글자와 바탕의 밝기가 비슷하면 작은 글자는 읽기 어렵습니다. W3C의 WCAG는 웹 콘텐츠 접근성 지침, 즉 다양한 사람이 웹을 읽고 사용할 수 있도록 정한 기준입니다.

W3C의 일반 텍스트 기준은 글자와 배경의 대비율이 4.5대 1 이상이어야 한다고 설명합니다. 큰 글자는 3대 1 기준을 적용하지만, 눈으로 커 보인다는 느낌만으로 큰 글자라고 정하지 않습니다. 실제 글자 크기와 굵기를 따져야 하므로 처음에는 본문과 버튼 문구를 일반 글자 기준으로 확인하는 편이 안전합니다. 기준값을 반올림해서 간신히 통과시켜서도 안 됩니다.

배경이 단색이 아니라 사진이라면 글자가 놓인 실제 부분을 봐야 합니다. 흰 글자 아래가 밝은 구름으로 바뀌는 지점에서는 다른 부분이 읽혀도 그 지점만 흐려질 수 있습니다. 글자 색을 바꿀 때는 바탕색과 화면 상태도 함께 확인합니다.

흐린 글자는 색을 진하게 하거나 바탕을 바꾼다

문제 문구 하나를 고르고 현재 글자색과 바탕색을 확인해 보세요. 대비 측정 도구에 두 색을 넣으면 비율을 볼 수 있습니다. 다만 측정값은 출발점입니다. 글꼴이 아주 얇거나 화면이 햇빛을 받으면 숫자가 기준을 넘어도 읽기 불편할 수 있으므로 실제 작은 화면에서 다시 읽어야 합니다.

예를 들어 연한 회색 설명을 흰 바탕에 놓고 눈으로만 “깔끔하다”고 판단하면 중요한 입력 안내가 사라질 수 있습니다. 색을 진하게 하거나 바탕을 조정한 뒤 본문, 링크, 오류 문구를 각각 읽어 봅니다. 링크가 단지 다른 색이라는 이유로 구분되는지도 살펴보고, 현재 읽는 문장의 의미를 색만으로 전달하지 않습니다.

예외도 구분해야 합니다. W3C 문서에는 비활성 상태의 조작 요소나 순수 장식처럼 일반 글자 대비 기준의 예외가 있습니다. 하지만 실제로 읽고 눌러야 하는 안내를 “장식”이라고 이름 붙여 피할 수는 없습니다. 독자에게 필요한 정보라면 흐리지 않게 만드는 것이 먼저입니다.

초점은 키보드가 지금 가리키는 자리다

키보드 초점은 Tab 키를 눌렀을 때 다음 Enter 키 입력을 받을 링크, 버튼, 입력칸 같은 현재 자리입니다. 마우스 포인터를 보며 이동할 때와 달리 키보드 이용자는 이 자리를 화면에서 따라가야 합니다. 책갈피가 다음 쪽으로 움직이는 모습을 보는 것과 비슷합니다.

W3C의 초점 표시 기준은 키보드로 조작할 수 있는 화면에서 현재 초점이 보이는 방식을 요구합니다. 브라우저가 기본으로 그리는 테두리도 표시가 될 수 있습니다. Tab을 누를 때 한 요소에서 다른 요소로 표시가 옮겨 가는지, 메뉴나 카드 안으로 들어갔을 때 갑자기 사라지지 않는지 봅니다. 화면 밖에 가려져 실제로 보이지 않는 표시라면 사용자는 여전히 길을 잃습니다.

Tab은 보통 다음 조작 대상으로 이동하고 Shift와 Tab을 함께 누르면 이전 대상으로 돌아갑니다. Enter는 현재 링크나 버튼을 실행할 수 있으니, 확인 실습에서는 예상하지 못한 결제·삭제 버튼을 실행하지 않습니다. 위치만 확인할 때는 Tab과 Shift+Tab으로 충분합니다.

기본 테두리를 지우기 전에 새 표시를 준비한다

CSS는 글자색과 테두리 같은 화면 모양을 정하는 규칙입니다. CSS에서 :focus-visible은 브라우저가 초점 위치를 보여 줄 필요가 있다고 판단한 요소에 스타일을 적용하는 선택자입니다. 키보드로 이동할 때 분명한 테두리를 추가하는 데 쓸 수 있습니다. 아래는 연습용 버튼에 초점 표시를 주는 짧은 예시입니다.

button:focus-visible {
  outline: 3px solid #1d3557;
  outline-offset: 3px;
}

Tab으로 이 버튼에 도착하면 바깥쪽에 선이 보이도록 의도한 코드입니다. 색과 두께는 실제 주변 색, 버튼 크기, 잘림 여부를 보고 조정해야 합니다. 이 예시 색이 모든 화면에서 자동으로 충분하다고 주장하는 것은 아닙니다. MDN은 :focus-visible을 이용해 필요한 순간의 초점 표시를 꾸밀 수 있다고 설명합니다.

기존 코드에 outline: none이 있다면 표시를 없애는 효과가 있는지 먼저 확인합니다. 새 표시 없이 기본 테두리만 지우면 키보드 이동 위치를 잃을 수 있습니다. 보이는 테두리 하나를 넣어도 링크 순서가 엉키거나 버튼이 키보드로 눌리지 않는 문제까지 해결되지는 않습니다.

글자와 초점은 다른 화면 상태에서 다시 본다

색 대비와 초점은 한 장의 정지 화면만 보고 끝낼 수 없습니다. 버튼을 누르기 전과 누를 수 없는 상태, 메뉴가 열린 상태, 오류가 뜬 상태에서 글자와 표시가 어떻게 달라지는지 확인합니다. 특히 초점 테두리가 카드 가장자리에서 잘리거나 다른 요소 뒤에 가려질 수 있습니다.

휴대전화 폭에서는 줄바꿈 때문에 글자 뒤의 바탕이 달라질 수 있습니다. 키보드가 연결된 작은 화면에서도 초점 위치가 보이는지 확인할 수 있으면 좋습니다. 자동 검사 결과가 좋아도 실제 Tab 이동과 읽기 확인을 함께 해야 하는 이유입니다. 이전 50강에서 입력칸의 이름표를 연결했다면, 이번에는 그 칸에 도착한 사람이 이름을 읽고 현재 위치를 볼 수 있는지 이어서 살펴봅니다.

오늘 바로 해볼 작은 실습

개인 계정이나 운영 화면을 바꾸지 않고, 공개된 연습 페이지 하나에서 10분 동안 읽기와 이동을 확인합니다.

  1. 짧은 안내 문구 하나와 그 뒤의 바탕색을 고릅니다.
  2. 눈으로 읽기 어려운 부분이 있는지 작은 화면에서도 봅니다.
  3. 두 색의 대비를 측정할 방법을 찾고 일반 글자라면 4.5대 1 기준과 비교합니다.
  4. Tab 키를 한 번씩 눌러 현재 자리의 테두리나 강조 표시가 보이는지 기록합니다.
  5. 표시가 카드나 메뉴에 가려지거나 화면 밖으로 나가는 곳을 적습니다.
  6. Shift+Tab으로 돌아올 때도 같은 자리가 보이는지 확인합니다.
  7. 링크 문구와 버튼 문구가 초점 표시 없이도 읽히는지 다시 봅니다.
  8. 수정이 필요하다면 실제 서비스 대신 연습 사본에서 색이나 테두리 한 가지를 바꿔 비교합니다.

모르는 명령이나 외부 스크립트는 이 실습에 필요하지 않습니다. 비밀번호, API 비밀키, 카드 번호를 연습 화면이나 캡처에 넣지 마세요. 결제, 삭제, 계정 설정 화면에서는 Tab으로 위치만 살피고 Enter나 Space를 눌러 실행하지 않습니다. 실제 서비스를 수정해야 한다면 담당자와 시험 환경, 되돌릴 방법을 확인한 뒤 진행합니다. 글자가 읽히고 현재 자리가 보이는지 두 질문에 모두 답할 수 있어야 화면 점검이 끝납니다.

확인한 자료

함께 읽기

  • 주소를 입력하면 웹페이지가 열리는 과정을 주문 배달처럼 이해하기

    웹 주소를 입력하면 브라우저는 DNS로 서버 주소를 찾고 HTTP 요청을 보냅니다. 서버가 돌려준 HTML, CSS, JavaScript와 이미지를 조합해 화면을 그리며, 404나 500 오류가 보이면 이 요청과 응답 중 실패한 구간을 확인하면 됩니다.

  • 프론트엔드와 백엔드와 데이터베이스를 식당 역할로 구분하기

    프론트엔드는 사용자가 보고 누르는 화면, 백엔드는 요청과 규칙을 처리하는 보이지 않는 부분, 데이터베이스는 회원과 주문 같은 기록을 보관하는 곳입니다. 식당으로 비유하면 각각 홀, 주방, 장부에 해당하며 세 역할이 연결돼 하나의 기능이 완성됩니다.

  • API와 JSON을 메뉴판과 주문서처럼 읽는 첫 연습

    API는 다른 서비스에 정해진 방식으로 기능이나 데이터를 요청하는 연결 창구이고, JSON은 그 요청과 답을 이름과 값의 묶음으로 적는 형식입니다. 메뉴판에서 가능한 주문을 확인하고 주문서에 항목을 적는 과정으로 생각하면 두 개념을 함께 이해하기 쉽습니다.