접근성(Accessibility) 개요

접근성은 제품이 다양한 사용자 요구와 능력을 지원하도록 구성된 방식을 뜻해요. 사용자 경험을 더 편안하게 만들고 정보와 쉽게 상호작용할 수 있게 보장하는 거죠. PatternFly는 접근성을 최우선으로 두고 있으니, 우리 디자인 시스템에 기여하거나 PatternFly를 제품에 사용한다면 먼저 접근성 가이드라인과 권장사항을 숙지하는 것이 좋아요.

출처: Accessibility Overview

본문

어떤 사용자도 제품을 사용할 때 뒤처진다고 느끼게 해서는 안 돼요. 접근성 좋은 디자인의 목표는 장벽을 제거하고 능력과 무관하게 모든 사람에게 작동하는 포용적인 제품 경험을 만드는 것입니다. 이것은 디자인과 개발 프로세스 초기에 접근성을 고려할 때 가장 잘 달성되지만, 접근성을 우선시하는 데 늦은 때란 없어요.

접근성에는 언제나 개선의 여지가 있어요. 그래서 우리 가이드라인은 계속 발전할 거예요. 여러분의 피드백은 더 포용적인 디자인 시스템을 만드는 데 도움이 되니, 접근성 문서에 기여하거나 GitHub Discussions에 참여해 주세요.

PatternFly에서 접근성은 어떻게 생겼나요?

우리는 컴포넌트를 테스트하고 접근성 준수를 확인하는 데 전념하며, WCAG(Web Content Accessibility Guidelines) 2.2의 레벨 AA에 맞추고 있어요.

컴포넌트 테스트와 준수

PatternFly의 컴포넌트가 접근성을 우선하도록 보장하기 위해, 우리는 코드베이스에 접근성을 구축해 넣어요.

PatternFly가 업데이트·향상됨에 따라, 우리는 변경사항과 새 기능을 자동화·수동 테스트의 조합으로 검증하며, aXe: The Accessibility Engine을 사용해 모든 컴포넌트가 PatternFly에 추가되기 전에 접근성 감사를 통과하도록 보장해요.

또한 수동 테스트와 통합 테스트로 키보드 접근성을 정기적으로 감사해요. 주요 스크린 리더로 VoiceOver의 완전한 지원을 목표로 하지만, 여전히 NVDA와 JAWS로도 컴포넌트를 테스트해요. 수동 감사의 일부로 모든 컴포넌트를 VoiceOver로 실행해, 제품에서 최대한 접근 가능하게 만들고 있어요.

접근성 표준

우리는 코어 PatternFly HTML·React 라이브러리와 확장 기능 전반에서 WCAG(Web Content Accessibility Guidelines) 2.2의 레벨 AA를 준수하도록 노력해요. PatternFly를 사용하거나 기여한다면, PatternFly가 준수할 것으로 기대할 수 있는 접근성 가이드라인은 다음과 같아요(이것이 완전한 목록은 아니라는 점을 명심하세요):

Guideline	Link	Applies to	Tested
의미론적 HTML 구조를 사용해 UI 요소의 목적과 관계를 정확히 전달한다.	WCAG 1.3.1	design, html, css	aXe 자동 테스트 및 수동 테스트
색상만이 유일한 전달 방법이어서는 안 된다. 색상으로 의미를 제공하는 것은 텍스트로 의미를 제공하는 것에 대한 보조다.	WCAG 1.4.1	design, html, css	수동 테스트 및 aXe 사용
사용되는 색상은 충분한 대비를 제공한다.	WCAG 1.4.3 및 1.4.11	css	aXe 자동 테스트
글꼴 크기는 콘텐츠나 기능 손실 없이 최대 200%까지, 한 방향 이상으로 스크롤할 필요 없이 최대 400%까지 확대할 수 있다.	WCAG 1.4.4 및 1.4.10	css	수동 테스트
텍스트 간격(줄 높이, 문단 사이 간격, 자간, 단어 간격)에 영향을 주는 스타일은 콘텐츠나 기능 손실 없이 늘릴 수 있다.	WCAG 1.4.12	css	수동 테스트 및 aXe 사용
호버와 포커스 시 나타나는 콘텐츠는 해제 가능하고, 호버 가능하며, 지속적이어야 한다.	WCAG 1.4.13	html, css, js	수동 테스트
모든 기능이 키보드로 접근 가능하다.	WCAG 2.1.1 및 2.1.2	html	수동 테스트
HTML과 레이아웃의 요소는 논리적 순서를 따른다.	WCAG 1.3.2 및 2.4.3	design, html, css	수동 테스트
깜빡이는 콘텐츠는 1초 동안 3회 이상 깜빡이지 않거나, 일반 플래시 및 빨간 플래시 임계값보다 낮아야 한다.	WCAG 2.3.1	css	수동 테스트
포커스가 있는 요소는 명확히 보인다.	WCAG 2.4.7	css	수동 테스트
포커스 가능한 요소는 완전히 가려지지 않는다.	WCAG 2.4.11	design	수동 테스트
복잡한 제스처를 사용하는 기능도 경로 기반 제스처 없이 단일 포인터로 작동할 수 있다.	WCAG 2.5.1	design	수동 테스트
포인터 이벤트는 취소될 수 있다.	WCAG 2.5.2	js	수동 테스트
UI 컴포넌트의 표시 라벨은 접근 가능한 이름과 같거나, 접근 가능한 이름의 시작 부분에 사용된다.	WCAG 2.5.3	html	aXe 자동 테스트 및 수동 테스트
드래그를 포함한 모든 동작에는 포인터 대안이 있다.	WCAG 2.5.7	js	수동 테스트
클릭 가능한 요소의 대상 영역은 특정 예외를 제외하고 최소 24×24 CSS 픽셀이다.	WCAG 2.5.8	css	수동 테스트
모든 UI 요소에 접근 가능한 이름·역할·값이 제공된다.	WCAG 4.1.2	design, html	aXe 자동 테스트 및 VoiceOver 수동 테스트
상태 메시지는 역할이나 속성을 통해 프로그래밍 방식으로 결정될 수 있다.	WCAG 4.1.3	html	수동 테스트

접근성을 위해 디자인하는 방법

경험의 동등성(Experience parity)

우리는 모든 능력이 동등하게 취급되어야 한다고 믿어요. 모든 사용자의 경험에 동등성이 있어야 해요—한 사용자 그룹이 다른 그룹보다 우선시되어서는 안 됩니다.

이를 달성하려면 다음 가이드라인을 고려하세요:

콘텐츠는 터치·마우스·키보드 등 모든 입력 유형에 최적화되어야 해요.
한 입력 유형을 위해 다른 유형의 경험을 희생하지 마세요.
마우스로 접근 가능한 콘텐츠는 터치나 키보드로도 접근 가능해야 해요.
호버 시에만 대화형 요소를 표시하지 마세요.
팝업에 표시되는 대화형 요소는 클릭·터치·Enter 키 이벤트에서도 표시되어야 해요.
스크린 리더 콘텐츠는 시각적으로 렌더링된 콘텐츠와 일치해야 해요(aria-hidden 상태에 대한 첫 번째 메모를 참조하되, 이는 구버전 WCAG 가이드라인을 참조한다는 점을 명심하세요).
호버와 포커스 이벤트 사이에 동등성이 있어야 해요. 마우스 사용자가 호버에서 얻는 모든 정보는 키보드 포커스에서도 얻을 수 있어야 해요.
aria-describedby를 사용해 호버 시 나타나는 콘텐츠를 스크린 리더에서 접근 가능하게 만드세요(Inclusive Components의 Tooltips & Toggletips 예제 참조).

접근성 좋은 사용자 경험을 구축할 때, 하나를 해결하면 그것이 많은 것으로 확장될 수 있어요. 인간은 다양하고 독특하므로, 접근성을 위한 디자인은 이를 고려해 진정으로 포용적인 제품을 만듭니다.

사용자 요구와 보조 기술 이해하기

보조 기술

키보드

일부 사용자가 마우스 대신 사용하는 키보드는, 사용자가 페이지에 나타나는 순서대로 UI 요소를 탐색할 수 있게 해주며, 보통 <kbd>Tab</kbd> 키를 사용해요. 키보드 사용자는 마우스 사용자가 할 수 있는 모든 것을 할 수 있어야 해요. 여기에는 호버 시 또는 팝업에 표시되는 텍스트 보기도 포함됩니다.

스크린 리더

스크린 리더는 보이는 콘텐츠와 보이지 않는 콘텐츠(툴팁, 아이콘·이미지·링크용 alt 텍스트 등)를 소리 내어 읽어줘요. 시력 장애(일시적 또는 영구적)로 화면을 볼 수 없는 사용자는 스크린 리더로 제품 또는 애플리케이션의 콘텐츠에 접근할 수 있어요.

종종 사용자는 스크린 리더를 사용하면서 키보드로 탐색하기도 해요.

장애 유형별 사용자 요구

이 섹션은 다양한 능력을 가진 사용자들의 일부 요구를 더 잘 이해하고 해결하도록 돕는 정보를 제공해요. 일부 사용자는 여러 그룹에 속할 수 있고, 다른 그룹을 위해 만들어진 도구를 사용할 수도 있다는 점을 유의하는 게 중요해요.

운동 제어

운동 제어가 저하된 사용자는 종종 키보드나 컴퓨터 마우스로 콘텐츠에 접근해요. 일부 사용자는 콘텐츠와 상호작용할 때 마우스를 안정적으로 유지하기 어려울 수도 있어요.

운동 제어가 저하된 사용자를 위해 디자인할 때 다음을 기억하세요:

키보드에 의존하는 사용자는 키보드로 접근 가능하고 포커스 시 매우 잘 보이는 요소가 필요해요.
마우스나 터치에 의존하는 사용자는 쉽게 클릭·선택할 수 있을 만큼 큰 대상 영역이 필요해요.

시각

시력 없음

시력이 없는 사용자는 웹사이트와 애플리케이션에 접근하기 위해 스크린 리더에 의존해요. 이 사용자들은 종종 헤더·링크·폼 요소 같은 특정 요소를 관찰하며 페이지를 탐색해요.

시력이 없는 사용자를 위해 디자인하려면:

의미론적 요소를 사용하세요.
맥락에서 떼어내도 의미 있는 라벨을 작성하세요.

저시력

저시력 사용자는 시각 장애의 특성(색 구분 어려움, 흐림, 중심 또는 주변부 시야 부족 등)에 따라 다른 요구를 가질 수 있어요.

저시력 사용자를 위해 디자인하려면:

인터페이스는 정보를 전달할 때 색상에만 의존해서는 안 돼요.
팔레트는 충분한 대비를 가져야 해요.
레이아웃은 글꼴 크기 증가에 반응해야 해요.

인지 처리

정보 처리에 어려움을 겪는 사용자는 잘 작성된 콘텐츠의 혜택을 받아요.

인지 처리 문제가 있는 사용자를 위해 디자인하려면:

명확하고 간결하며 스캔하기 쉬운 콘텐츠를 작성하세요.
시각적 계층을 고려하고 콘텐츠를 짧고 관련성 있는 섹션으로 묶으세요.
긴 문단을 피하세요.

접근성 스펙트럼

몇 가지 주요 접근성 요구가 있지만, 그게 완전한 목록은 아니에요. 종종 Microsoft가 만든 "Persona Spectrum"(Inclusive Guidebook PDF 다운로드)을 사용해 영구·일시·상황적 시나리오 스펙트럼 전반의 관련된 불일치와 동기를 이해할 수 있어요.

접근성은 영구 장애가 있는 사람들에 초점을 맞추는 경향이 있지만, 모든 사람이 접근성 좋은 제품의 혜택을 받아요:

접근성 좋은 콘텐츠는 언어 유창성과 문해력 수준 전반에서 더 나은 이해를 지원해요.
대체 텍스트(alt text)는 이미지를 로드할 수 없는 낮은 대역폭 연결이나 구형 기술 사용자도 이미지에 접근할 수 있게 해줘요.
자막은 붐비는 장소에 있는 사람, 읽기를 배우는 사람, 새 언어를 배우는 사람에게 혜택을 줘요.

접근성은 모든 사용자를 고려합니다.

접근성(Accessibility) 개요