그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Browser
Browser

웹 접근성의 개념과 개선 방법에 대해 설명해주세요

실무4/5
설계4/5
인간4/5
기초2/5

면접관의 질문 의도

WCAG 항목을 외운 사람인지, 컴포넌트 설계 단계에서 접근성을 어떻게 묶어 보는지 우선순위로 설명하는 사람인지를 가른다.

큐레이션 답변

학습 자료

웹 접근성은 장애 여부와 무관하게 모든 사용자가 정보를 인지·조작할 수 있게 만드는 품질 기준이다. 실무 개선은 시맨틱 마크업, 올바른 레이블링, 키보드 포커스 순서, 충분한 명도 대비, 스크린리더 친화 구조를 기본으로 잡는다. ARIA는 시맨틱 HTML로 풀리지 않는 경우에만 _최소한_으로 쓰고, 자동 점검 도구 결과와 실제 키보드/보조기기 테스트를 함께 본다. 결국 접근성은 "나중에 붙이는 옵션"이 아니라 컴포넌트 설계 단계에서 잡아야 비용이 가장 낮다.

좋은 답변 구조

  1. 01접근성을 "모든 사용자의 인지·조작" 품질 기준으로 정의한다
  2. 02시맨틱 마크업·레이블·키보드 포커스·대비·스크린리더 같은 축별 개선안을 균형 있게 정리한다
  3. 03자동 점검 도구·실 보조기기 테스트가 어디까지 잡고 어디부터 사람이 봐야 하는지 조건을 짚는다
  4. 04ARIA는 _최후 수단_, 컴포넌트 설계 단계 통합 같은 팀 운영 기준으로 마무리한다

자주 실수하는 포인트

div+role="button"으로 버튼을 흉내내고 키보드 동작을 빠뜨린다
ARIA를 마구 붙여 시맨틱 정보를 _덮어쓰는_ 오용을 한다
자동 검사 통과를 "접근성 완료"로 잘못 본다
키보드 포커스 순서·visible focus 같은 항목을 디자인 단계에서 빠뜨린다

실무 맥락

  • 디자인 시스템 컴포넌트(드롭다운·모달·탭)를 접근성 포함해 다시 설계하는 작업
  • WCAG 명도 대비 기준이 떨어지는 브랜드 컬러를 운영하는 서비스
  • 스크린리더 사용자 신고가 들어와 실제 보조기기로 흐름을 점검해야 하는 상황

본인 경험에 녹이는 힌트

div 버튼을 button/role+키보드 핸들러로 정리해본 적이 있다면 시맨틱과 키보드 흐름이 묶이는 이야기로 자연스럽게 풀 수 있다

스크린리더로 직접 페이지를 들어본 경험이 있다면 자동 검사가 못 잡는 부분을 답변 후크로 쓸 수 있다

컴포넌트 라이브러리에 visible focus·aria-label 규칙을 표준화한 적이 있다면 그 기준이 그대로 답이 된다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1시맨틱 태그만 쓰면 접근성 문제가 모두 해결되나요
Q2ARIA는 언제 추가하고 언제 피해야 하나요
Q3접근성 개선 우선순위는 어떤 기준으로 정하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문