모바일 반응형 화면과 키보드 접근성을 함께 점검하는 첫 순서

컴퓨터에서는 멀쩡한 화면이 휴대전화에서 옆으로 밀리거나 버튼이 화면 밖으로 나갈 때가 있습니다. 마우스로는 누를 수 있는데 Tab 키로는 버튼에 갈 수 없는 화면도 있습니다. 둘 다 사용하기 어렵다는 결과를 만들지만 원인과 점검 방법은 다릅니다.

반응형 디자인은 화면 크기에 맞춰 배치를 바꾸는 방법이고, 웹 접근성은 신체 조건이나 입력 방식이 달라도 내용과 기능을 사용할 수 있게 만드는 기준입니다. 옷을 몸에 맞게 고르는 일이 반응형이라면, 단추와 지퍼를 여러 방식으로 열 수 있게 만드는 일은 접근성에 가깝습니다.

반응형 디자인은 화면이 아니라 내용에서 출발한다

반응형 웹 디자인은 하나의 웹페이지가 여러 화면 크기와 해상도에서 잘 보이고 쓰이도록 만드는 접근법입니다. 똑같은 데스크톱 화면을 작게 축소하는 것이 아니라, 좁아지면 두 열을 한 열로 바꾸고 이미지와 글이 컨테이너 안에 머물게 합니다.

MDN은 유연한 격자, 상대 단위, 미디어 쿼리 같은 방법을 설명합니다. 미디어 쿼리는 화면 조건이 맞을 때만 특정 CSS를 적용하는 규칙입니다. 다만 특정 휴대전화 모델의 숫자를 외우기보다 내용이 눌리거나 읽기 어려워지는 지점에서 배치를 바꾸는 편이 오래 갑니다.

• 좁은 화면에서는 먼저 한 열로 읽히게 합니다.
• 고정 너비보다 컨테이너에 맞는 너비를 사용합니다.
• 이미지가 부모 영역보다 넓어지지 않게 합니다.
• 긴 주소와 코드가 전체 페이지를 밀지 확인합니다.
• 글자와 버튼이 확대돼도 겹치지 않는지 봅니다.

뷰포트와 미디어 쿼리는 서로 다른 일을 한다

뷰포트는 브라우저에서 페이지가 실제로 그려지는 보이는 영역입니다. 모바일 문서의 <meta name="viewport" content="width=device-width">는 브라우저가 장치 너비를 기준으로 페이지를 표시하도록 알려 줍니다. 이것이 빠지면 모바일 브라우저가 넓은 데스크톱 화면처럼 계산해 CSS 조건이 예상과 다르게 적용될 수 있습니다.

미디어 쿼리는 뷰포트 너비 같은 조건에 따라 스타일을 바꿉니다. 다음 예시는 좁을 때 한 열이던 카드가 48rem 이상에서 두 열로 바뀌는 흐름입니다.

.cards { display: grid; grid-template-columns: 1fr; gap: 16px; }
img { max-width: 100%; height: auto; }
@media (min-width: 48rem) {
  .cards { grid-template-columns: 1fr 1fr; }
}

미디어 쿼리가 있다고 반응형이 자동으로 완성되지는 않습니다. 카드 안의 긴 코드, 최소 너비가 큰 입력창, 고정된 광고 영역 하나가 여전히 가로 넘침을 만들 수 있습니다. 실제 내용과 실제 브라우저 크기로 확인해야 합니다.

접근성은 마우스 없이도 같은 목적에 도달하게 한다

웹 접근성은 장애가 있는 사람을 포함해 다양한 사용자가 웹을 이용할 수 있게 설계하는 일입니다. W3C WAI는 모든 기능을 키보드로 사용할 수 있어야 한다고 설명합니다. 키보드 접근은 마우스를 쓰기 어려운 사람뿐 아니라 화면 읽기 도구, 음성 입력, 고장 난 마우스를 쓰는 상황에도 도움이 됩니다.

기본 HTML의 링크, 버튼, 입력 요소는 브라우저가 키보드 동작을 이미 제공합니다. 클릭 가능한 <div>를 새로 만드는 것보다 목적에 맞는 <button>을 쓰면 Tab 이동과 Enter 또는 Space 실행을 기본으로 얻습니다. CSS로 초점 표시를 없애면 현재 어디에 있는지 보이지 않으므로 눈에 띄는 테두리나 배경을 유지해야 합니다.

390픽셀과 Tab 키로 각각 검사한다

모바일 검사는 개발자 도구에서 화면 너비를 390픽셀로 두고 시작할 수 있습니다. 페이지 전체 폭보다 튀어나온 요소가 있는지, 글과 이미지가 잘리지 않는지, 버튼이 손가락으로 누르기 어려울 만큼 작지 않은지 봅니다. 화면을 끝까지 내려 실제 카드와 본문을 모두 확인합니다.

키보드 검사는 주소창에서 페이지로 이동한 뒤 Tab 키를 반복해 봅니다. 초점이 보이는지, 화면 순서와 이동 순서가 자연스러운지, 모든 버튼과 링크를 실행할 수 있는지, 팝업에 갇히지 않고 나올 수 있는지 봅니다. 반응형 검사를 통과해도 키보드 검사는 별도입니다.

흔한 수정이 새 문제를 만들지 확인한다

가로 넘침을 숨기려고 페이지 전체에 overflow-x: hidden만 넣으면 잘린 내용을 발견하기 어려워집니다. 원인이 되는 요소의 고정 너비와 긴 내용을 먼저 고칩니다. 키보드 이동을 맞추려고 큰 tabindex 숫자를 붙이면 화면 구조와 이동 순서가 더 어긋날 수 있어 자연스러운 HTML 순서를 우선합니다.

자동 검사 도구는 빠진 대체 텍스트나 명확한 규칙을 찾는 데 도움이 되지만 실제 사용성을 전부 보장하지 않습니다. 브라우저 크기를 줄여 보고 키보드만으로 핵심 행동을 끝내 보는 수동 검사가 함께 필요합니다.

오늘 바로 해볼 작은 실습

1. 자주 쓰는 사이트 한 곳을 열고 개발자 도구의 모바일 보기를 켭니다.
2. 너비를 390픽셀로 두고 페이지를 위에서 아래까지 천천히 내립니다.
3. 좌우 스크롤이 생기거나 잘린 글, 이미지, 버튼을 한 곳 찾습니다.
4. 마우스를 놓고 Tab 키로 첫 링크부터 핵심 버튼까지 이동합니다.
5. 현재 초점이 눈에 보이는지와 이동 순서를 적습니다.
6. Enter 또는 Space로 버튼 하나를 실행한 뒤 원래 화면으로 돌아옵니다.

검사 중 결제나 삭제 버튼에는 실제로 확인 동작을 하지 마세요. 운영 사이트에서는 테스트 계정과 취소 가능한 데이터만 사용합니다. 의미를 모르는 접근성 속성이나 JavaScript 키보드 코드를 복사해 넣지 말고, 먼저 기본 HTML 요소로 해결되는지 확인하는 것이 안전합니다.