많은 사람이 개발 워크플로 프로세스에 패턴 스타일 가이드, 구성요소 라이브러리 또는 전체 디자인 시스템을 사용하여 구성요소 중심 개발을 사용합니다. 이러한 도구를 공식적으로 사용하지 않더라도 유사한 프로세스를 사용하여 웹사이트, 앱 또는 기타 디지털 제품의 대규모 디자인을 관리 가능한 조각으로 나눌 수 있습니다.
물리적 구조물을 짓는 것처럼 한 번에 한 조각씩 제작하는 것이 중요합니다. 먼저 기초, 구조, 벽, 창문, 지붕 및 그 사이의 모든 것을 포함합니다. 구성요소 기반 개발 도구를 사용하면 웹사이트, 앱, 기타 디지털 제품에서 이 작업을 수행할 수 있습니다.
구성요소 기반 개발의 장점으로는 항목을 관리 가능한 조각으로 분해하여 재사용 가능한 구성요소를 사용하면 개발 시간을 단축할 수 있습니다. 따라서 디자이너, 프런트엔드, 백엔드 개발자, QA가 동시에 작업할 수 있습니다. 그리고 클라이언트, 디자이너, PM 등은 웹사이트 출시 후 빌드 프로세스를 미리 보고 라이브 스타일 가이드를 참고 자료로 사용할 수 있다는 점을 선호합니다.
그러나 접근성을 염두에 두고 패턴, 구성요소, 디자인 시스템을 살펴보면 몇 가지 의문이 제기됩니다. 접근성과 관련하여 가장 적합한 패턴을 어떻게 알 수 있을까요? 기존 패턴/라이브러리를 사용해야 하나요, 아니면 새 패턴/라이브러리를 만들어야 하나요? 이러한 패턴이 사용자에게 실제로 도움이 될지 어떻게 알 수 있을까요?
선택할 수 있는 옵션이 무수히 다양하기 때문에 이 주제를 혼동하기 쉽습니다. 이 모듈은 접근성을 위해 패턴, 구성요소, 디자인 시스템을 평가하는 방법에 관한 일반적인 정보를 제공하고 접근성을 높이는 데 도움이 되는 시작점을 제공하는 것을 목표로 합니다.
비판적으로 사고하세요
액세스 가능한 패턴, 구성요소, 디자인 시스템을 선택하는 것은 로켓 과학은 아니지만 시간과 비판적 사고가 필요합니다. 실제로 '완벽한 패턴 1개'와 같은 것은 없지만, 작동할 수 있는 옵션이 많을 수 있습니다. 고유한 상황에 가장 적합한 옵션을 선택하는 방법을 배우는 것입니다.
후속 테스트 모듈에서는 접근성을 위해 패턴, 구성요소, 디자인 시스템을 평가하는 방법에 관한 기법과 메서드에 관해 자세히 알아봅니다. 하지만 그 전에 한 걸음 물러서서 다음과 같은 기본적인 질문을 자문해야 합니다.
- 액세스 가능한 패턴, 구성요소, 디자인 시스템이 이미 확립되어 있나요?
- 어떤 브라우저 및 보조 기술 (AT)을 지원하나요?
- 고려해야 할 코드/프레임워크 제한 또는 기타 통합/요소/사용자 요구사항이 있는가?
개발 환경 및 사용자 요구사항에 따라 이와 관련하여 추가 질문이 있거나 다른 질문이 있을 수 있습니다. 이러한 질문을 접근성 평가의 시작점으로 고려해 보세요.
기존 리소스
새로운 것을 빌드하기 전에 실사를 실시하고 액세스 가능한 패턴, 구성요소, 디자인 시스템 측면에서 이미 존재하는 것이 무엇인지 검토합니다. 약간의 조사만으로도 니즈에 맞는 솔루션을 찾을 수 있을 것입니다.
액세스 가능한 패턴, 구성요소 및 디자인 시스템에 대한 몇 가지 훌륭한 리소스는 다음과 같습니다.
- 액세스 가능한 구성요소
- 데크 대학교 ARIA 라이브러리
- 정부 영국 디자인 시스템(Gov.UK Design System)
- 포함된 구성요소
- 자홍색 A11y
- 미국 연방 정부를 위해 만들어진 USWDS (U.S. Web Design System)
- Smashing Magazine의 액세스 가능한 패턴 목록
JavaScript 프레임워크의 경우 다음 리소스는 즉시 액세스할 수 있거나 접근성을 위해 쉽게 맞춤설정할 수 있습니다.
하지만 아무리 강조해도 지나치지 않습니다. 코드를 복사/붙여넣기하고 해당 환경이 사용자 환경에 적합하고 자동으로 사용자의 요구사항을 충족한다고 가정해서는 안 됩니다. 이는 전체 액세스 가능으로 라벨이 지정된 경우에도 모든 패턴, 구성요소, 디자인 시스템에 적용됩니다.
모든 리소스를 시작점으로 생각해야 합니다. 모든 것을 테스트해야 합니다.
브라우저 및 보조 기술 (AT) 지원
개발 환경에서 작동할 수 있는 몇 가지 기본 패턴, 구성요소 또는 전체 설계 시스템을 조사한 후 보조 기술 지원으로 이동할 수 있습니다. 패턴, 구성요소, 디자인 시스템을 평가할 때 중점을 두어야 할 주요 AT 유형 중 하나는 스크린 리더입니다.
스크린 리더는 특정 브라우저를 염두에 두고 개발되었으며 이러한 브라우저와 페어링할 때 가장 잘 작동합니다. 이 주제에 관해서는 AT 테스트에 관한 모듈에서 더 자세히 다룰 예정이지만 패턴 평가를 위해서는 이러한 조합이 존재한다는 점을 이해하면 지원 측면에서 필요한 사항을 파악하는 데 도움이 됩니다.
| 스크린 리더 | OS | 브라우저 호환성 | 비용 |
|---|---|---|---|
| 음성을 통한 작업 액세스 (JAWS) | Windows | Chrome, Firefox, Edge | 라이선스 필요 (40분 무료 버전 존재) |
| 비시각적 데스크톱 액세스 (NVDA) | Windows | Chrome 및 Firefox | 무료 (다운로드 필요) |
| 내레이터 | Windows | 에지 | 무료 (Windows 머신에 내장) |
| VoiceOver | macOS | Safari | 무료 (macOS 머신에 내장) |
| 범고래 | Linux | Firefox | 무료 (Gnome 기반 배포에 내장) |
| TalkBack | Android | Chrome 및 Firefox | 무료 (특정 버전의 Android OS에 내장됨) |
| VoiceOver | iOS | Safari | 무료 (iOS 기기에 내장) |
브라우저 지원은 일반적으로 복잡하며 AT 기기와 ARIA 사양을 함께 추가하면 더욱 까다로워집니다.
그렇다고 해서 모두 나쁜 것은 아닙니다. 다행히 HTML5 접근성, 접근성 지원, WCAG의 맞춤 제어 액세스 가능 개발 체크리스트와 같은 훌륭한 리소스는 현재 브라우저 및 AT 기기 지원을 더 잘 이해하고 애초에 ARIA를 사용해야 하는 경우에 도움이 됩니다.
이 리소스에서는 오픈소스 커뮤니티 테스트를 비롯하여 사용 가능한 다른 HTML 및 ARIA 패턴 하위 요소를 간략하게 설명합니다. 데스크톱과 모바일 브라우저/AT 기기에 모두 해당하는 패턴의 예를 검토할 수도 있습니다. 따라서 이러한 리소스는 사용하려는 패턴, 구성요소, 디자인 시스템과 관련하여 좀 더 접근성 높은 결정을 내리는 데 도움이 될 수 있습니다.
기타 고려사항
액세스 가능한 몇 가지 기본 패턴 또는 구성요소를 선택하고 브라우저 및 AT 기기 지원을 고려한 후에는 패턴, 구성요소, 설계 시스템, 개발 환경에 관한 좀 더 구체적인 상황별 질문으로 넘어갈 수 있습니다.
예를 들어 관리 시스템 (CMS)에서 작업하거나 기존 코드가 있는 경우 사용할 수 있는 패턴에 몇 가지 제한사항이 있을 수 있습니다. 검토 후 여러 패턴 선택 항목을 한두 개의 옵션으로 빠르게 줄일 수 있습니다.
많은 자바스크립트 프레임워크에서는 개발자가 자신이 선택한 거의 모든 패턴을 사용할 수 있습니다. 이러한 경우에는 제한사항이 더 적을 수 있으며 가장 액세스 가능한 패턴 옵션을 선택할 수 있습니다.
패턴, 구성요소 또는 디자인 시스템을 선택할 때 추가로 고려해야 할 사항은 다음과 같습니다.
- 성능
- 보안
- 검색엔진 최적화
- 언어 번역 지원
- 타사 통합
이러한 요소가 패턴 선택에 의심할 여지 없이 영향을 미치지만 콘텐츠와 코드를 만드는 사람도 고려해야 합니다. 선택한 패턴은 편집기에서 생성한 콘텐츠 또는 사용자 제작 콘텐츠와 관련된 잠재적 제한사항을 처리할 수 있을 만큼 견고해야 하며 접근성에 관한 모든 지식을 가진 개발자가 사용할 수 있는 방식으로 빌드되어야 합니다.
학습 내용 확인하기
패턴에 관한 지식 테스트
액세스 가능한 구성요소는 사용자가 항상 액세스할 수 있나요?