디자인 시스템 접근성 통합 가이드: 색 대비·키보드·포커스·스크린리더 컴포넌트 기준 > 인사이트

본문 바로가기

인사이트

#프론트엔드

디자인 시스템 접근성 통합 가이드: 색 대비·키보드·포커스·스크린리더 컴포넌트 기준

노트북 화면의 디자인 시스템 컴포넌트와 접근성 기준을 함께 검토하는 작업 장면
접근성은 출시 직전 점검표가 아니라 디자인 시스템 안에 들어가야 하는 화면 품질 기준이다.

디자인 시스템 접근성 통합 가이드: 신뢰를 만드는 컴포넌트 설계 기준

답부터 말하면, 접근성은 출시 직전 QA 체크리스트가 아니라 디자인 토큰, 컴포넌트 API, 문서화, 자동 테스트, 수동 검수 기준에 나누어 심어야 합니다. 기업 홈페이지나 SaaS 화면에서 버튼 포커스, 폼 오류, 색 대비, 키보드 이동, 스크린리더 라벨이 페이지마다 다르다면 문제는 개별 화면이 아니라 디자인 시스템 운영 방식에 있을 가능성이 큽니다.

특히 B2B 서비스는 사용자가 긴 신청서, 관리자 승인, 결제·계약 정보 입력, 검색 필터, 데이터 테이블을 반복해서 사용합니다. 이때 접근성은 장애인 사용자만을 위한 별도 장식이 아니라, 실수 방지와 신뢰 형성, 화면 품질 유지에 직접 연결됩니다. 접근성 기준이 컴포넌트에 들어가면 새 랜딩 페이지, 관리자 화면, 고객 포털을 만들 때 같은 결함이 반복되지 않습니다.

실무 원칙은 단순합니다. 페이지를 고치는 것이 아니라 버튼·폼·모달·네비게이션·테이블을 고쳐서 같은 문제가 다시 생기지 않게 만드는 것입니다.

왜 페이지 단위 접근성 점검만으로는 부족한가

많은 조직이 접근성을 출시 직전 점검 항목으로 다룹니다. 이 방식은 단기적으로는 빠르지만, 운영 화면이 늘어날수록 수정 비용이 커집니다. 예를 들어 랜딩 페이지의 CTA 버튼은 포커스 링이 보이지만, SaaS 관리자 화면의 저장 버튼은 outline이 제거되어 있을 수 있습니다. 회원가입 화면은 오류 메시지를 텍스트로 보여주지만, 결제 정보 입력 화면은 빨간 테두리만 표시할 수 있습니다. 사용자는 같은 서비스 안에서 매번 다른 규칙을 배워야 합니다.

접근성 표준 자체는 보통 페이지와 사용자 흐름 단위로 평가됩니다. 하지만 제품 조직이 품질을 반복적으로 관리하려면 컴포넌트 단위의 기준이 필요합니다. VA.gov 디자인 시스템도 컴포넌트 단위 테스트가 이슈를 일찍 잡는 데 도움을 주지만, 전체 페이지 구조와 사용자 흐름에서만 확인 가능한 접근성 항목이 남는다고 설명합니다. 즉, 컴포넌트 기준과 제품 맥락 검수는 둘 중 하나를 고르는 문제가 아니라 역할을 나누어 함께 운영해야 합니다. ([design.va.gov](https://design.va.gov/accessibility/accessibility-testing-for-design-system-components))

  • 디자이너: 색상, 상태, 포커스, 오류, 터치 영역을 토큰과 컴포넌트 명세로 정의합니다.
  • 개발자: 네이티브 HTML, ARIA, 키보드 이벤트, 테스트 코드를 컴포넌트에 내장합니다.
  • PM·마케터: 페이지 목표, 문구, 폼 단계, 법적 고지, 전환 흐름에서 사용자가 막히지 않는지 확인합니다.
  • 운영 담당자: 새 배너, 팝업, 이벤트 페이지, 관리자 기능 추가 시 같은 기준을 재사용합니다.

기준선: WCAG 2.2와 KWCAG 2.2를 컴포넌트 언어로 번역하기

WCAG 2.2는 2023년 10월 5일 W3C 권고안으로 발행되었고, WCAG 2.1에 신규 성공 기준을 더한 방식입니다. W3C는 정책상 이전 버전을 요구받더라도 향후 변경에 대비하고 더 나은 접근성을 위해 WCAG 2.2를 새 적합성 목표로 채택할 것을 권고합니다. 국내에서 공공·금융·교육·대기업 납품 사이트나 공식 웹접근성 인증을 염두에 둔다면 한국형 웹 콘텐츠 접근성 지침 KWCAG 2.2와 인증기관 기준도 함께 확인해야 합니다. ([w3.org](https://www.w3.org/TR/WCAG22/))

화면 문제관련 기준디자인 시스템에 넣을 기준주 담당
본문·버튼·아이콘 대비 부족텍스트 1.4.3, 비텍스트 1.4.11텍스트, 배경, 경계, 아이콘, 상태 색상을 의미 토큰으로 정의하고 조합별 대비를 검증디자인 리드
키보드 포커스가 안 보이거나 헤더에 가려짐2.4.7, 2.4.11, 2.4.13포커스 링 토큰, overlay z-index, sticky header 여백, :focus-visible 스타일을 공통화프론트엔드
드롭다운·모달·캘린더가 키보드로 막힘2.1.1, 2.1.2, APG 패턴열기, 이동, 선택, 닫기, 포커스 복귀 규칙을 컴포넌트 문서에 명시프론트엔드
모바일에서 작은 아이콘 버튼 오작동2.5.8 Target Size클릭·탭 타깃 최소 크기와 인접 간격을 토큰으로 관리디자인·개발
폼 오류가 색으로만 표시됨3.3.1, 3.3.2, 3.3.3라벨, 도움말, 오류 문구, aria-describedby 연결을 컴포넌트 기본값으로 제공PM·디자인·개발
스크린리더가 아이콘 버튼 목적을 읽지 못함4.1.2 Name, Role, Value접근성 이름, 역할, 상태, 값이 프로그램적으로 결정되도록 컴포넌트 API 설계개발

1. 디자인 토큰: 색상 이름보다 의미와 상태를 먼저 정한다

접근성 있는 디자인 시스템은 파란색, 회색, 빨간색 같은 색상 이름으로 운영되지 않습니다. 의미, 용도, 상태가 토큰 이름에 들어가야 합니다. Atlassian 디자인 시스템은 대부분의 앱 경험에서 색상을 디자인 토큰으로 적용하고, 토큰 이름에 배경·테두리·아이콘 같은 속성, 역할, 강조도, 상호작용 상태가 포함될 수 있다고 설명합니다. 이런 방식은 브랜드 색을 무작정 고정하는 대신, 라이트 모드와 다크 모드, hover와 pressed, danger와 warning의 대비를 체계적으로 관리하게 합니다. ([atlassian.design](https://atlassian.design/foundations/color/))

토큰 범주예시접근성 관점의 결정 기준
텍스트color.text.primary, color.text.subtle일반 텍스트 4.5:1 이상, 보조 텍스트도 실제 배경 조합에서 검증
인터랙션 배경color.bg.action.primary, color.bg.action.hover기본, hover, pressed, selected가 색만으로 구분되지 않도록 명도·테두리·아이콘 병행
상태color.border.error, color.text.success성공·경고·오류를 색만으로 전달하지 않고 텍스트와 아이콘을 함께 제공
포커스color.border.focus, shadow.focus배경과 버튼 색이 달라도 포커스가 보이도록 별도 토큰으로 분리
터치 영역size.target.minimum, space.control.gap아이콘 버튼, pagination, 칩, 필터 삭제 버튼의 최소 타깃과 간격을 보장
모션motion.duration.fast, motion.reduced애니메이션이 정보 이해나 조작을 방해하지 않도록 축소 모션 대응값 제공

색 대비 기준은 컴포넌트별로 따로 기억하게 만들지 말고 토큰 조합에서 통과하도록 설계해야 합니다. WCAG 2.2 AA 기준에서 일반 텍스트와 이미지 텍스트는 4.5:1 이상, 큰 텍스트는 3:1 이상이 요구됩니다. 사용자 인터페이스 컴포넌트와 상태를 식별하는 데 필요한 시각 정보, 그래픽 객체는 인접 색상 대비 3:1 이상이 요구됩니다. ([w3.org](https://www.w3.org/TR/WCAG22/))

2. 버튼·링크: 클릭 가능함을 눈과 키보드 모두에게 보여주기

버튼과 링크는 디자인 시스템에서 가장 많이 재사용되는 컴포넌트입니다. 그래서 여기서 접근성 기준이 흔들리면 전체 서비스가 흔들립니다. 기본 원칙은 네이티브 HTML을 먼저 쓰는 것입니다. W3C의 Using ARIA 문서는 비상호작용 요소를 상호작용 요소처럼 만들면 개발자가 의미와 키보드 동작을 직접 추가해야 하며, 버튼의 경우 네이티브 button을 쓰는 편이 더 쉽고 좋다고 설명합니다. 또한 ARIA로 만든 모든 상호작용 컨트롤은 키보드로 사용할 수 있어야 합니다. ([w3c.github.io](https://w3c.github.io/using-aria/))

  • 클릭 이벤트가 필요한 액션은 <button>, 페이지 이동은 <a>를 기본으로 사용합니다.
  • 아이콘만 있는 버튼은 보이는 텍스트가 없으므로 접근성 이름을 제공하되, 불필요한 중복 라벨은 피합니다.
  • 시각 라벨과 접근성 이름이 달라지지 않게 합니다. 예를 들어 버튼에는 가입하기가 보이는데 스크린리더에는 신청이라고 읽히면 음성 입력 사용자에게 문제가 됩니다.
  • loading 상태는 버튼 텍스트, disabled 처리, aria-busy 또는 상태 메시지 정책을 함께 정의합니다.
  • disabled 버튼은 너무 흐리게 만들어 인식이 안 되는 상태와 구분해야 합니다. 클릭 불가 사유가 필요하면 도움말이나 보조 문구를 제공합니다.
  • 포커스 스타일은 hover 스타일과 달라야 하며, outline 제거는 금지에 가깝게 관리합니다.

WCAG 2.2는 키보드로 조작 가능한 인터페이스에서 포커스 표시가 보여야 한다고 규정합니다. 또한 WCAG 2.2의 신규 AA 기준은 키보드 포커스를 받은 컴포넌트가 작성자가 만든 콘텐츠에 의해 완전히 가려지지 않아야 한다고 명시합니다. sticky header, 쿠키 배너, 채팅 위젯, 하단 고정 CTA가 많은 기업 홈페이지에서는 이 항목이 실제 결함으로 자주 드러납니다. ([w3.org](https://www.w3.org/TR/WCAG22/))

3. 폼: 라벨, 도움말, 오류 메시지를 한 묶음으로 설계

폼은 접근성 문제가 전환율 문제로 바로 연결되는 영역입니다. 문의, 회원가입, 견적 요청, 결제, 관리자 승인 화면은 모두 사용자가 정확한 정보를 입력해야 하는 흐름입니다. 폼 UX 자체의 이탈 원인과 구조 개선은 폼 UX 최적화 가이드에서 별도로 다루었지만, 디자인 시스템 관점에서는 라벨·도움말·오류·성공 상태를 컴포넌트의 기본 계약으로 만들어야 합니다.

상태화면 기준개발 기준운영 문구 기준
기본라벨은 placeholder가 아니라 입력 필드 밖 또는 명확한 위치에 유지labelinput을 명시적으로 연결무엇을 입력해야 하는지 짧게 표현
도움말예시, 형식, 제한 조건을 입력 전 제공aria-describedby로 도움말 ID 연결사업자등록번호 10자리처럼 조건을 구체화
오류빨간 테두리만 쓰지 않고 텍스트 오류 제공aria-invalid, 오류 문구 연결, 필요 시 상태 메시지잘못됐습니다가 아니라 수정 방법을 제시
성공입력 완료를 색만으로 표시하지 않음자동 포커스 이동은 신중히 사용다음 단계가 있으면 명확히 안내
그룹라디오·체크박스 묶음의 질문을 보이게 제공fieldset, legend 또는 동등한 구조 적용동의 항목과 선택 항목을 분리

WCAG는 사용자 입력이 필요한 콘텐츠에 라벨이나 지시사항을 제공해야 하며, 자동 감지된 입력 오류는 오류 항목을 식별하고 텍스트로 설명해야 한다고 규정합니다. 오류 수정 제안이 알려져 있다면 사용자에게 제안도 제공해야 합니다. 이 기준은 접근성 문서에만 남겨둘 것이 아니라 Input, Select, CheckboxGroup, FileUpload, DatePicker 컴포넌트의 기본 명세에 들어가야 합니다. ([w3.org](https://www.w3.org/TR/WCAG22/))

4. 모달·드롭다운·네비게이션: 포커스 이동 규칙을 문서화한다

모달, 드롭다운, 콤보박스, 날짜 선택기, 사이드 네비게이션은 시각적으로는 익숙하지만 접근성 구현 난도가 높은 컴포넌트입니다. WAI-ARIA Authoring Practices Guide는 콤보박스, 메뉴 버튼, 모달 다이얼로그 같은 패턴별 역할, 상태, 키보드 상호작용을 상세히 다룹니다. 복잡한 커스텀 위젯을 만들 때는 디자인 레퍼런스보다 먼저 APG 패턴을 확인하는 습관이 필요합니다. ([wai-aria-practices.netlify.app](https://wai-aria-practices.netlify.app/aria-practices/))

  • 모달 열기: 트리거 버튼을 누르면 포커스가 모달 내부의 제목 또는 첫 조작 요소로 이동해야 합니다.
  • 모달 내부 이동: Tab과 Shift+Tab으로 모달 내부를 순환하고, 배경 페이지로 초점이 새지 않게 합니다.
  • 모달 닫기: Esc, 닫기 버튼, 취소 버튼의 동작을 정의하고 닫은 뒤 포커스는 보통 모달을 연 버튼으로 돌아갑니다.
  • 드롭다운: 단순 링크 목록인지, 애플리케이션 메뉴인지에 따라 Tab, 방향키, Enter, Space, Esc 규칙을 구분합니다.
  • 캘린더: 포커스만 받았는데 달력이 자동으로 열리면 스크린리더와 키보드 사용자에게 혼란을 줄 수 있으므로 열기 조건을 명확히 정합니다.
  • 네비게이션: 반복되는 헤더·푸터·사이드바의 순서와 명칭을 페이지마다 일관되게 유지합니다.

포커스가 보이는 것과 포커스가 예상 가능한 위치로 이동하는 것은 다릅니다. 예를 들어 삭제 확인 모달에서 삭제 버튼을 누른 뒤 포커스가 페이지 맨 위로 튀면 키보드 사용자는 자신의 위치를 잃습니다. 반대로 삭제된 행 근처의 다음 행 또는 결과 요약으로 이동하면 작업 맥락을 유지할 수 있습니다. 이런 판단은 컴포넌트 라이브러리와 제품 정책이 함께 정해야 합니다.

5. 모바일 터치 영역과 드래그 대체 동작

WCAG 2.2에서 실무적으로 체감이 큰 변화 중 하나는 드래그 동작과 타깃 크기입니다. 드래그로만 조작하는 정렬, 슬라이더, 지도, 파일 업로드 영역은 마우스 정밀 조작이 어려운 사용자에게 장벽이 됩니다. WCAG 2.2 AA 기준은 드래그를 사용하는 기능도 드래그 없이 단일 포인터로 수행할 수 있어야 한다고 규정합니다. 또 포인터 입력 타깃은 예외를 제외하고 최소 24 by 24 CSS 픽셀을 요구합니다. AAA 기준에는 44 by 44 CSS 픽셀의 강화된 타깃 크기도 있습니다. ([w3.org](https://www.w3.org/TR/WCAG22/))

실무에서는 법적 최소값만 보지 말고 화면 밀도와 오류 비용을 함께 봐야 합니다. 관리자 테이블의 행별 더보기 버튼, 모바일 하단 탭, 필터 칩 삭제 버튼, 페이지네이션 숫자, 캘린더 날짜는 모두 인접 오작동이 잦은 컴포넌트입니다. B2B SaaS라면 최소 기준과 별개로 주요 액션 버튼은 더 넉넉한 터치 영역을 잡는 편이 운영 문의와 입력 실수를 줄이는 데 유리합니다.

컴포넌트 문서에 꼭 들어갈 접근성 표준

접근성 기준이 없는 컴포넌트 명세와 포함된 컴포넌트 명세 비교 화면
컴포넌트 문서에는 색상과 크기뿐 아니라 키보드, 포커스, 오류, 스크린리더 기준이 함께 있어야 한다.

디자인 시스템 문서가 색상, 크기, 예시 화면만 담고 있다면 접근성은 구현자의 기억에 의존하게 됩니다. 컴포넌트 문서에는 상태, 키보드, 스크린리더, 오류, 제한 사항, 페이지 맥락에서 다시 확인할 항목이 들어가야 합니다.

컴포넌트문서에 넣을 접근성 기준페이지에서 다시 확인할 것
Button시각 라벨, accessible name, loading·disabled 정책, Enter·Space 동작, focus-visible 스타일버튼 문구가 현재 흐름에서 구체적인지
TextFieldlabel 필수 여부, help text, error message, aria-describedby 연결, 자동완성 정책오류 문구가 실제 입력 규칙과 맞는지
Select·Combobox열기·검색·선택·닫기 키보드 규칙, 옵션 로딩 상태, 선택값 읽힘옵션 수가 많을 때 검색·필터가 필요한지
Modal초기 포커스, 포커스 트랩, Esc 닫기, 배경 비활성, 닫힌 뒤 포커스 복귀중요 고지나 파괴적 액션에서 확인 단계가 충분한지
Toast·Alertrole, live region, 자동 사라짐 시간, 사용자가 다시 확인할 방법성공·실패 메시지가 업무 로그에 남아야 하는지
DataTable헤더 구조, 정렬 상태, 행 액션 접근성 이름, 빈 상태, pagination 타깃테이블 제목과 필터 조건이 전체 페이지 구조에서 명확한지

여기서 중요한 점은 컴포넌트가 모든 것을 해결하지 못한다는 사실입니다. 예를 들어 Button 컴포넌트는 포커스와 키보드 조작을 보장할 수 있지만, 버튼 문구가 자세히 보기만 반복되는 문제는 페이지 문맥에서 해결해야 합니다. Input 컴포넌트가 label 연결을 제공해도, PM이 라벨을 생략하는 옵션을 허용하면 사용자 흐름은 깨집니다.

개발 파이프라인: Figma에서 CI까지 접근성 결함을 앞당겨 잡기

Figma 설계부터 CI 테스트까지 이어지는 접근성 검증 워크플로우
접근성 QA는 한 번의 검사보다 설계, 개발, 테스트 단계마다 작게 반복될 때 효과가 크다.

접근성 통합은 완벽한 한 번의 검사가 아니라 작은 실패를 일찍 발견하는 구조입니다. Storybook의 접근성 테스트는 렌더링된 DOM을 WCAG 규칙과 업계 베스트 프랙티스 기반 휴리스틱으로 검사하며, 접근성 애드온은 axe-core 위에서 동작합니다. Playwright도 axe-core를 E2E 테스트에 연결하는 예시를 제공하지만, 자동 테스트가 모든 WCAG 위반을 탐지할 수 없고 수동 평가와 사용자 테스트를 함께 권장한다고 명시합니다. ([storybook.js.org](https://storybook.js.org/docs/writing-tests/accessibility-testing))

  1. Figma 단계: 색상 토큰, 포커스 상태, 오류 상태, 키보드 순서, 스크린리더 설명을 annotation으로 남깁니다.
  2. 컴포넌트 개발 단계: Storybook에 기본, hover, focus, disabled, error, loading, long text, dark mode 사례를 등록합니다.
  3. 자동 점검 단계: Storybook a11y, eslint-plugin-jsx-a11y, axe, Playwright를 사용해 반복 결함을 CI에서 막습니다.
  4. 수동 키보드 QA: 주요 흐름을 마우스 없이 Tab, Shift+Tab, Enter, Space, Esc, 방향키로 완료합니다.
  5. 스크린리더 스모크 테스트: NVDA, VoiceOver 등 팀 환경에 맞는 도구로 라벨, 오류, 상태 변경, 모달 안내를 확인합니다.
  6. 릴리즈 게이트: 신규 컴포넌트 또는 고위험 화면은 접근성 체크리스트 통과 없이는 배포하지 않도록 기준을 정합니다.
검사 방식잘 잡는 문제놓치기 쉬운 문제권장 담당
자동 DOM 검사이름 없는 버튼, 잘못된 ARIA, 일부 대비, 누락 label문구의 적절성, 실제 업무 흐름, 의도한 포커스 이동개발
키보드 수동 테스트키보드 트랩, 포커스 순서, 닫기 불가 모달스크린리더 안내 품질QA·PM
스크린리더 테스트라벨, 역할, 상태 변경, live region시각 대비와 터치 오작동QA·개발
디자인 리뷰대비, 상태 구분, 터치 영역, 오류 표현렌더링된 DOM 구조디자인
제품 흐름 리뷰전환 단계, 반복 입력, 도움말 위치, 파괴적 액션개별 컴포넌트 구현 결함PM

출시 전 30분 수동 QA 체크리스트

접근성 출시 체크리스트를 보며 SaaS 화면을 점검하는 PM 작업 장면
자동 점검으로 반복 결함을 줄이고, 수동 QA로 실제 사용자 흐름의 품질을 확인한다.

자동 테스트가 통과해도 실제 사용자는 막힐 수 있습니다. 아래 항목은 기업 홈페이지 리뉴얼, SaaS MVP, 관리자 대시보드 배포 전에 최소한으로 확인할 만한 수동 QA 기준입니다.

  • 마우스를 빼고 문의, 가입, 결제, 저장, 승인, 삭제 흐름을 끝까지 완료한다.
  • 포커스가 현재 위치를 명확히 보여주는지, sticky header나 팝업에 가려지지 않는지 확인한다.
  • 모달을 열고 닫은 뒤 포커스가 예상 위치로 돌아오는지 확인한다.
  • 모든 아이콘 버튼이 스크린리더에서 구체적인 목적을 갖는지 확인한다. 예: 검색, 필터 삭제, 행 더보기.
  • 필수 입력, 오류, 도움말이 색만으로 전달되지 않는지 확인한다.
  • 텍스트 200% 확대와 작은 화면에서 주요 기능이 사라지지 않는지 확인한다. WCAG는 보조 기술 없이 텍스트를 200%까지 확대해도 콘텐츠나 기능 손실이 없어야 한다고 규정합니다. ([w3.org](https://www.w3.org/TR/WCAG22/))
  • 모바일에서 페이지네이션, 닫기 버튼, 칩 삭제, 캘린더 날짜를 손가락으로 눌렀을 때 인접 버튼 오작동이 없는지 확인한다.
  • 드래그 정렬이 필요한 경우 위로 이동, 아래로 이동, 순서 입력 같은 대체 조작이 있는지 확인한다.
  • 성공·실패 토스트가 너무 빨리 사라져 사용자가 내용을 놓치지 않는지 확인한다.
  • 로그인·인증 흐름에서 복사·붙여넣기, 비밀번호 관리자 사용을 막지 않는지 확인한다. WCAG 2.2는 접근 가능한 인증 기준에서 비밀번호 관리자 지원과 복사·붙여넣기가 인지 부담을 줄이는 예가 될 수 있다고 설명합니다. ([w3.org](https://www.w3.org/TR/WCAG22/))

도입 우선순위: 모든 것을 한 번에 고치려 하지 말 것

접근성 개선은 전체 화면을 한 번에 뜯어고치는 방식보다, 재사용 컴포넌트와 고위험 사용자 흐름부터 처리하는 편이 낫습니다. 특히 이미 운영 중인 서비스라면 접근성 개선이 기능 개발 일정을 모두 멈추게 만들면 내부 저항이 커집니다. 다음처럼 단계화하면 현실적인 합의가 쉽습니다.

단계기간 예시해야 할 일성과물
0단계 진단1~2주주요 화면 5~10개, 핵심 컴포넌트 10개 접근성 샘플 감사결함 목록, 우선순위, 빠른 수정 항목
1단계 토큰 정리2~4주색상, 포커스, 간격, 터치 영역, 상태 토큰 정리토큰 표, 대비 검증표, Figma·CSS 변수 매핑
2단계 핵심 컴포넌트4~8주Button, Input, Select, Modal, Toast, Table 접근성 리팩토링컴포넌트 문서, Storybook 사례, 테스트 코드
3단계 주요 흐름상시가입, 문의, 결제, 관리자 승인, 검색·필터 흐름 검수QA 체크리스트, 릴리즈 기준
4단계 운영 체계상시신규 화면 템플릿, PR 체크, 디자인 리뷰 기준 반영작업 가이드, RFP·검수 기준, 회귀 테스트

기업 홈페이지 리뉴얼에서는 접근성과 정보 구조, 검색 노출을 함께 보는 편이 좋습니다. 제목 구조, 링크 문구, 폼 라벨은 사용성뿐 아니라 콘텐츠 운영 품질에도 영향을 주기 때문입니다. Next.js 기반 랜딩·SaaS 사이트 구조는 Next.js App Router SEO 가이드와 함께 검토하면 중복 작업을 줄일 수 있습니다. SaaS 관리자 화면처럼 컴포넌트 수가 많고 데이터 로딩이 복잡한 경우에는 React Server Components 성능 최적화 가이드에서 다룬 렌더링 구조와 접근성 있는 인터랙션을 함께 설계해야 합니다.

리뉴얼·외주개발 RFP에 넣을 접근성 요구사항

접근성을 외주개발이나 리뉴얼 범위에 넣을 때는 웹 접근성 준수라고만 쓰면 해석이 갈립니다. 어느 기준을 목표로 하는지, 어느 화면까지 포함하는지, 어떤 산출물을 받을 것인지, 자동 테스트와 수동 테스트를 어떻게 나눌 것인지 명확히 적어야 합니다.

나쁜 요구사항좋은 요구사항
웹 접근성 준수대상 화면은 홈페이지 주요 템플릿 8종과 가입·문의 흐름이며, WCAG 2.2 AA 및 KWCAG 2.2 주요 항목을 기준으로 검수한다.
색상은 보기 좋게텍스트, 아이콘, 경계, 상태 색상은 토큰 조합별 대비 검증표를 제공한다.
키보드 가능하게모든 주요 흐름은 Tab, Shift+Tab, Enter, Space, Esc로 완료 가능해야 하며 모달은 포커스 트랩과 복귀를 제공한다.
스크린리더 대응아이콘 버튼, 폼 오류, 상태 메시지, 모달 제목, 테이블 정렬 상태의 접근성 이름·역할·상태를 확인한다.
테스트 알아서Storybook a11y 또는 axe 기반 자동 테스트 결과, 수동 키보드 QA 체크리스트, 알려진 예외 목록을 검수 산출물로 제출한다.

정부지원사업 MVP나 공공 성격이 있는 서비스라면 처음부터 인증 수준의 모든 항목을 구현할 수 있는지, 아니면 핵심 사용자 흐름과 향후 인증 대비 구조를 먼저 잡을지 의사결정이 필요합니다. 범위를 모호하게 두면 디자인, 개발, 검수 단계에서 모두 비용이 늘어납니다.

자주 생기는 실수와 주의점

  • 색만 바꾸는 오류 표시: 빨간색 테두리만으로 오류를 알리면 색각 이상 사용자뿐 아니라 급하게 입력하는 사용자도 놓치기 쉽습니다.
  • outline 제거: 미관 때문에 focus outline을 없애고 대체 스타일을 주지 않는 것은 키보드 사용자에게 치명적입니다.
  • aria-label 남용: 보이는 라벨과 다른 접근성 이름을 넣으면 스크린리더와 음성 입력 사용자가 혼란을 겪습니다.
  • div 버튼: div에 클릭 이벤트만 붙이면 키보드 포커스와 Enter·Space 동작을 직접 구현해야 합니다.
  • 자동으로 열리는 팝업: 포커스만 받았는데 드롭다운이나 캘린더가 열리면 사용자가 현재 위치를 잃을 수 있습니다.
  • tooltip 의존: 중요한 설명을 hover tooltip에만 넣으면 키보드와 터치 사용자가 놓칠 수 있습니다.
  • tabindex 남용: tabindex=1처럼 순서를 억지로 바꾸면 페이지 구조가 복잡해질수록 유지보수가 어려워집니다.
  • 자동 테스트 통과를 인증처럼 해석: 자동 도구는 첫 번째 방어선이지 최종 보증서가 아닙니다.

AgentMit 관점: 접근성은 신뢰를 만드는 화면 운영 기준

AgentMit는 접근성을 별도 장식 요소가 아니라 사업 홈페이지와 SaaS 화면의 기본 설계 기준으로 봅니다. 특히 BizMit 같은 업무 운영형 서비스, 관리자 대시보드, 신청·승인·정산 화면, AI 자동화 화면은 사용자가 반복해서 조작하고 실수 비용이 큰 영역입니다. 이곳에서 포커스가 사라지거나 오류 안내가 불명확하면 기능이 좋아도 서비스 신뢰가 떨어집니다.

기존 React·Next.js 컴포넌트 라이브러리에 접근성 기준을 붙이려면 처음부터 전면 개편을 할 필요는 없습니다. 보통은 토큰 진단, 핵심 컴포넌트 리팩토링, Storybook 접근성 사례 등록, Playwright 기반 흐름 테스트, 수동 QA 체크리스트 정리 순서로 접근하는 편이 현실적입니다. 신규 SaaS MVP나 정부지원사업 후속 개발이라면 초기에 버튼·폼·모달·테이블 기준만 제대로 잡아도 이후 화면 확장 비용을 줄일 수 있습니다.

AgentMit와 함께 접근성 기준이 포함된 SaaS, 관리자 화면, 업무 자동화 웹서비스를 설계하고 싶다면 BizMit 서비스 안내를 먼저 확인해 보셔도 좋습니다. 이미 운영 중인 디자인 시스템이나 외주개발 산출물을 점검해야 한다면 프로덕션 문의에서 현재 화면, 기술 스택, 개선 목표를 함께 보내주시면 논의가 빠릅니다.

FAQ

Q1. 디자인 시스템 접근성은 WCAG 인증을 받는 것과 같은 의미인가요?

같지 않습니다. 디자인 시스템 접근성은 토큰, 컴포넌트, 문서, 테스트 기준을 만들어 접근성 결함을 반복 생산하지 않게 하는 운영 방식입니다. 인증은 특정 사이트나 서비스가 정해진 기준을 충족했는지 심사하는 절차에 가깝습니다.

Q2. 색 대비는 디자인 토큰에서 몇 대 몇으로 잡아야 하나요?

일반 본문 텍스트는 WCAG AA 기준 4.5:1 이상, 큰 텍스트는 3:1 이상, UI 컴포넌트 경계·상태·아이콘처럼 의미 전달에 필요한 비텍스트 요소는 3:1 이상을 기본선으로 잡는 것이 실무적으로 안전합니다.

Q3. 키보드 조작은 Tab 이동만 확인하면 충분한가요?

충분하지 않습니다. 버튼은 Enter와 Space, 모달은 진입·탈출·초점 복귀, 드롭다운과 콤보박스는 열기·선택·닫기 규칙까지 확인해야 합니다. Tab 순서만 맞아도 포커스가 가려지거나 키보드 트랩이 있으면 실패입니다.

Q4. 스크린리더 라벨은 모든 요소에 aria-label을 넣으면 해결되나요?

아닙니다. 네이티브 HTML 라벨과 텍스트가 우선입니다. aria-label은 아이콘 버튼처럼 보이는 텍스트가 없는 경우에 제한적으로 사용해야 하며, 시각 라벨과 접근성 이름이 달라지면 음성 입력 사용자에게 문제가 될 수 있습니다.

Q5. Storybook, axe, Playwright 자동 테스트만 통과하면 접근성 QA를 생략해도 되나요?

생략하면 안 됩니다. 자동 테스트는 누락된 이름, 잘못된 속성, 일부 대비 문제 같은 반복 결함을 빨리 찾는 데 유용하지만, 문맥상 적절한 라벨, 헤딩 구조, 실제 키보드 흐름, 스크린리더 안내 품질은 수동 확인이 필요합니다.

참고 자료

자주 묻는 질문

디자인 시스템 접근성은 WCAG 인증을 받는 것과 같은 의미인가요?
같지 않습니다. 디자인 시스템 접근성은 토큰, 컴포넌트, 문서, 테스트 기준을 만들어 접근성 결함을 반복 생산하지 않게 하는 운영 방식입니다. 인증은 특정 사이트나 서비스가 정해진 기준을 충족했는지 심사하는 절차에 가깝습니다.
색 대비는 디자인 토큰에서 몇 대 몇으로 잡아야 하나요?
일반 본문 텍스트는 WCAG AA 기준 4.5:1 이상, 큰 텍스트는 3:1 이상, UI 컴포넌트 경계·상태·아이콘처럼 의미 전달에 필요한 비텍스트 요소는 3:1 이상을 기본선으로 잡는 것이 실무적으로 안전합니다.
키보드 조작은 Tab 이동만 확인하면 충분한가요?
충분하지 않습니다. 버튼은 Enter와 Space, 모달은 진입·탈출·초점 복귀, 드롭다운과 콤보박스는 열기·선택·닫기 규칙까지 확인해야 합니다. Tab 순서만 맞아도 포커스가 가려지거나 키보드 트랩이 있으면 실패입니다.
스크린리더 라벨은 모든 요소에 aria-label을 넣으면 해결되나요?
아닙니다. 네이티브 HTML 라벨과 텍스트가 우선입니다. aria-label은 아이콘 버튼처럼 보이는 텍스트가 없는 경우에 제한적으로 사용해야 하며, 시각 라벨과 접근성 이름이 달라지면 음성 입력 사용자에게 문제가 될 수 있습니다.
Storybook, axe, Playwright 자동 테스트만 통과하면 접근성 QA를 생략해도 되나요?
생략하면 안 됩니다. 자동 테스트는 누락된 이름, 잘못된 속성, 일부 대비 문제 같은 반복 결함을 빨리 찾는 데 유용하지만, 문맥상 적절한 라벨, 헤딩 구조, 실제 키보드 흐름, 스크린리더 안내 품질은 수동 확인이 필요합니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 부산진구 서전로 8, 8층 101호 DD-33,34호(부전동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.