웹 접근성(a11y) 정리

핵심 요약

• 웹 접근성은 장애 유무나 입력 방식과 관계없이 누구나 웹 서비스를 사용할 수 있게 만드는 원칙이다.
• 면접에서는 "착한 일"로만 설명하기보다, 키보드 사용성, 스크린 리더 대응, 명확한 구조 같은 구체 항목으로 말하는 게 좋다.
• 시맨틱 태그, 적절한 label, 포커스 관리, 대비, 대체 텍스트가 기본이다.
• 접근성은 나중에 덧붙이는 옵션이 아니라 UI 설계와 구현 과정에 같이 들어가야 비용이 덜 든다.

웹 접근성이란?

웹 접근성은 사용자가 마우스를 쓰지 못하더라도, 화면을 보지 못하더라도, 혹은 일시적으로 손이 불편하거나 밝은 야외에서 화면을 보더라도 서비스를 이용할 수 있게 만드는 기준이다.

실무에서는 보통 다음 질문으로 풀어 설명하면 자연스럽다.

• 키보드만으로도 주요 기능을 사용할 수 있는가?
• 스크린 리더가 화면 구조를 이해할 수 있는가?
• 색만으로 정보를 전달하고 있지는 않은가?
• 버튼, 링크, 입력창의 역할이 코드상으로도 드러나는가?

왜 중요한가?

접근성은 일부 사용자만 위한 특수 요구사항이 아니다. 회원가입, 결제, 검색 같은 핵심 플로우가 더 분명해지고, 구조가 좋아지면서 전반적인 UX도 같이 좋아지는 경우가 많다.

또 시맨틱 마크업이 잘 되어 있으면 유지보수나 자동화 테스트, SEO에도 도움이 된다. 그래서 면접에서는 "접근성을 챙기면 사용자 범위가 넓어지고, 구조가 좋아져서 제품 품질 전체가 올라간다" 정도로 연결하면 좋다.

프론트엔드에서 자주 보는 핵심 항목

1. 시맨틱 태그 사용

div만으로 화면을 만들기보다 button, nav, main, header, label 같은 태그를 맞게 써야 한다.

예를 들어 클릭 가능한 요소를 div로 만들면 키보드 포커스나 역할 정보가 부족해진다. 반대로 button을 쓰면 기본 키보드 조작과 역할 정보가 같이 따라온다.

2. 폼 접근성

입력창에는 눈에 보이는 텍스트뿐 아니라 코드상 연결된 label이 있어야 한다.

<label for="email">이메일</label>
<input id="email" type="email" />

placeholder만 넣고 label을 생략하면 스크린 리더 사용성이 떨어지고, 입력 목적도 덜 분명해질 수 있다.

3. 키보드 사용성

탭으로 이동이 자연스러워야 하고, 모달이 열렸을 때 포커스가 모달 안에 머물러야 하며, 닫힐 때는 원래 버튼으로 돌아가는 식의 포커스 관리가 필요하다.

이 부분은 실무에서 자주 놓치는데, 면접에서는 "마우스 없이 써본다"는 식으로 검증 습관까지 말하면 좋다.

4. 대체 텍스트와 이름

이미지에는 의미가 있을 때 적절한 alt가 필요하다. 장식용 이미지는 빈 alt로 처리하는 게 오히려 맞을 수 있다.

버튼도 아이콘만 넣지 말고 접근 가능한 이름이 있어야 한다.

예를 들어 돋보기 아이콘 버튼은 화면에는 아이콘만 보여도, 코드상으로는 aria-label="검색" 같은 정보가 필요할 수 있다.

5. 색 대비와 정보 전달 방식

에러를 빨간색으로만 보여주거나, 선택 상태를 색 차이만으로 구분하면 일부 사용자는 알아보기 어렵다.

색 외에 텍스트, 아이콘, 밑줄, 상태 문구를 같이 써야 한다.

실무 예시

예를 들어 커스텀 드롭다운을 직접 만들었다고 해보자. 겉보기에는 잘 동작해도 다음 문제가 자주 생긴다.

• 탭으로 항목 이동이 안 된다.
• 현재 열린 상태인지 스크린 리더가 모른다.
• ESC로 닫히지 않는다.
• 선택 후 포커스 위치가 어색하다.

이럴 때는 직접 모든 상호작용을 구현하기보다, 가능한 경우 네이티브 요소를 우선 쓰거나 검증된 접근성 패턴을 따라가는 게 안전하다.

면접 답변 예시

웹 접근성은 장애가 있는 사용자만 위한 별도 기능이라기보다, 누구나 서비스의 핵심 기능을 사용할 수 있게 만드는 기본 품질이라고 생각합니다. 프론트엔드에서는 시맨틱 태그를 맞게 쓰고, 입력창에 label을 연결하고, 키보드만으로 조작 가능한지와 포커스 흐름이 자연스러운지를 먼저 봅니다. 또 이미지 대체 텍스트, 아이콘 버튼의 접근 가능한 이름, 색 대비도 기본적으로 확인합니다. 실무에서는 커스텀 UI를 만들수록 접근성이 깨지기 쉬워서, 가능하면 네이티브 요소를 우선 활용하고 직접 만든 컴포넌트는 키보드와 스크린 리더 기준으로 꼭 점검합니다.

장점

• 더 많은 사용자가 서비스를 문제없이 사용할 수 있다.
• UI 구조가 명확해져서 유지보수와 테스트가 쉬워진다.
• 시맨틱 마크업이 좋아지면서 SEO에도 도움이 될 수 있다.
• "동작은 되는데 쓰기 불편한 화면"을 줄이는 데 효과적이다.

단점

• 초기에 설계와 검증에 추가 시간이 든다.
• 커스텀 컴포넌트가 많을수록 구현 난도가 올라간다.
• 팀에 기준이 없으면 화면마다 품질 편차가 커질 수 있다.

주의사항 / 실무 팁

• 클릭 가능한 요소는 가능하면 div 대신 button, a 같은 네이티브 요소를 우선 쓴다.
• placeholder를 label 대체재로 생각하면 안 된다.
• 모달, 드롭다운, 탭처럼 상호작용이 복잡한 UI는 키보드로 직접 끝까지 사용해 본다.
• 색만으로 상태를 전달하지 말고 텍스트나 아이콘을 같이 둔다.
• 접근성은 QA 마지막 단계에서 한 번 보는 게 아니라 컴포넌트 설계 단계부터 같이 들어가야 비용이 덜 든다.