많은 개발자가 개발 워크플로 프로세스에서 패턴 스타일 가이드, 구성요소 라이브러리 또는 전체 디자인 시스템을 사용하여 구성 기반 개발을 사용합니다. 이러한 도구를 공식적으로 사용하지 않았더라도 웹사이트, 앱 또는 기타 디지털 제품의 대규모 디자인을 관리 가능한 부분으로 나누는 데 유사한 프로세스를 사용했을 가능성이 큽니다.
실제 구조물을 짓는 것처럼 한 번에 하나씩 빌드하는 것이 중요합니다. 먼저 기초, 구조, 벽, 창문, 지붕, 그 사이의 모든 것을 고려합니다. 구성요소 기반 개발 도구를 사용하면 웹사이트, 앱, 기타 디지털 제품에 이를 적용할 수 있습니다.
구성요소 기반 개발의 몇 가지 이점에는 관리 가능한 부분으로 나누는 것이 포함되므로 이러한 재사용 가능한 구성요소를 사용하면 개발 시간이 줄어듭니다. 이를 통해 디자이너, 프런트엔드 및 백엔드 개발자, QA가 동시에 작업할 수 있습니다. 또한 고객, 디자이너, PM 등은 빌드 프로세스를 미리 보고 웹사이트가 출시된 후 실시간 스타일 가이드를 참고할 수 있기 때문에 이 도구를 좋아합니다.
하지만 접근성을 염두에 두고 패턴, 구성요소, 디자인 시스템을 살펴보면 몇 가지 질문이 생깁니다. 접근성 측면에서 가장 적합한 패턴은 어떻게 알 수 있나요? 기존 패턴이나 라이브러리를 사용해야 하나요, 아니면 새 패턴이나 라이브러리를 만들어야 하나요? 이러한 패턴이 실제로 사용자에게 도움이 되는지 어떻게 알 수 있나요?
다양한 선택사항이 있으므로 패턴, 구성요소, 디자인 시스템에 관해 혼동하기 쉽습니다. 이 모듈은 접근성 측면에서 패턴, 구성요소, 디자인 시스템을 평가하는 방법에 관한 일반적인 정보를 제공하고 더 접근하기 쉬운 선택을 하는 데 도움이 되는 출발점을 제공하는 것을 목표로 합니다.
비판적으로 사고하기
접근 가능한 패턴, 구성요소 또는 디자인 시스템을 선택하는 것은 어려운 일이 아니지만 시간과 비판적 사고가 필요합니다. 사실 '완벽한 패턴'은 없지만 효과적인 패턴은 여러 개 있을 수 있습니다. 고유한 상황에 가장 적합한 옵션을 선택하는 방법을 배우는 것입니다.
후속 테스트 모듈에서는 접근성 측면에서 패턴, 구성요소, 디자인 시스템을 평가하는 방법에 관한 기법과 방법을 자세히 알아봅니다. 그 전에 다음과 같은 몇 가지 기본적인 질문을 스스로에게 물어봐야 합니다.
- 액세스 가능한 기존 패턴, 구성요소 또는 디자인 시스템이 이미 있나요?
- 어떤 브라우저와 보조 기술 (AT)을 지원하나요?
- 코드 또는 프레임워크 제한사항이 있나요? 고려해야 할 다른 통합, 요소 또는 사용자 요구사항이 있나요?
개발 환경 및 사용자 요구사항에 따라 추가 질문이 있거나 다른 질문이 있을 수 있습니다. 다음 질문을 접근성 평가의 시작점으로 삼아 보세요.
설정된 리소스
새로운 것을 빌드하기 전에 실사를 수행하고 액세스 가능한 패턴, 구성요소, 디자인 시스템 측면에서 이미 존재하는 항목을 검토하세요. 조금만 조사해 보면 필요에 맞는 솔루션을 찾을 수 있습니다.
접근성 패턴, 구성요소, 디자인 시스템에 관한 유용한 리소스는 다음과 같습니다.
- 접근성 있는 구성요소
- Deque University ARIA 라이브러리
- Gov.UK 디자인 시스템
- 포용적 구성요소
- MagentaA11y
- 미국 연방 정부를 위해 만든 미국 웹 디자인 시스템 (USWDS)
- Smashing Magazine에서 액세스할 수 있는 패턴 목록
JavaScript 프레임워크의 경우 다음 리소스는 기본적으로 상당히 액세스 가능하거나 접근성을 위해 맞춤설정할 수 있습니다.
- CSS가 충분하지 않은 경우: 접근 가능한 구성요소의 JavaScript 요구사항
- 반응
- Angular: Material 라이브러리
- Vue: Vuetensils
하지만 코드를 복사/붙여넣기하고 코드가 환경에 맞고 사용자 요구사항을 자동으로 충족한다고 가정해서는 안 됩니다. 이는 완전히 액세스 가능으로 라벨이 지정된 경우에도 모든 패턴, 구성요소, 디자인 시스템에 적용됩니다.
모든 리소스는 출발점으로 간주해야 합니다. 모든 것을 테스트해야 합니다.
브라우저 및 보조 기술 (AT) 지원
개발 환경에 적합한 몇 가지 기본 패턴, 구성요소 또는 전체 디자인 시스템을 조사한 후에는 보조 기술 지원으로 이동할 수 있습니다. 패턴, 구성요소, 디자인 시스템을 평가할 때 중점적으로 살펴볼 주요한 AT 유형 중 하나는 스크린 리더입니다.
스크린 리더는 특정 브라우저를 염두에 두고 빌드되었으며 이러한 브라우저와 함께 사용할 때 가장 잘 작동합니다. 이 주제는 AT 테스트 모듈에서 더 자세히 다루겠지만, 패턴 평가를 위해 이러한 조합이 존재한다는 점을 이해하면 지원 측면에서 필요한 사항을 파악하는 데 도움이 됩니다.
| 스크린 리더 | OS | 브라우저 호환성 | 비용 |
|---|---|---|---|
| Job Access with Speech (JAWS) | Windows | Chrome, Firefox, Edge | 라이선스 필요 (40분 무료 버전 있음) |
| 비주얼 데스크톱 액세스 (NVDA) | Windows | Chrome 및 Firefox | 무료 (다운로드 필요) |
| 내레이터 | Windows | Edge | 무료 (Windows 머신에 내장됨) |
| VoiceOver | macOS | Safari | 무료 (macOS 컴퓨터에 내장됨) |
| Orca | Linux | Firefox | 무료 (Gnome 기반 배포에 내장됨) |
| TalkBack | Android | Chrome 및 Firefox | 무료 (특정 버전의 Android OS에 내장됨) |
| VoiceOver | iOS | Safari | 무료 (iOS 기기에 내장) |
브라우저 지원은 일반적으로 복잡하며 AT 기기와 ARIA 사양을 추가하면 더욱 복잡해집니다.
하지만 나쁜 소식만 있는 것은 아닙니다. 다행히 HTML5 접근성, 접근성 지원, WCAG의 맞춤 컨트롤 접근성 개발 체크리스트와 같은 유용한 리소스를 통해 현재 브라우저 및 AT 기기 지원과 ARIA를 사용해야 하는 경우를 더 잘 이해할 수 있습니다.
이 리소스에서는 오픈소스 커뮤니티 테스트를 비롯하여 사용 가능한 다양한 HTML 및 ARIA 패턴 하위 요소를 간략히 설명합니다. 데스크톱, 모바일 브라우저, AT 기기의 패턴 예시도 검토할 수 있습니다. 따라서 이러한 리소스를 사용하면 사용할 패턴, 구성요소, 디자인 시스템에 관해 더 쉽게 결정을 내릴 수 있습니다.
기타 고려사항
액세스 가능한 기본 패턴이나 구성요소를 몇 개 선택하고 브라우저 및 AT 기기 지원을 고려한 후에는 패턴, 구성요소, 디자인 시스템, 개발 환경에 관한 더 구체적인 문맥 질문으로 넘어갈 수 있습니다.
예를 들어 관리 시스템 (CMS)에서 작업 중이거나 기존 코드가 있는 경우 사용할 수 있는 패턴에 몇 가지 제한사항이 있을 수 있습니다. 검토 과정에서 여러 패턴 옵션이 빠르게 하나 또는 두 가지 옵션으로 줄어들 수 있습니다.
많은 JavaScript 프레임워크에서는 개발자가 선택한 거의 모든 패턴을 사용할 수 있습니다. 이러한 경우 제한사항이 적을 수 있으며 가장 액세스하기 쉬운 패턴 옵션을 선택할 수 있습니다.
패턴, 구성요소 또는 디자인 시스템을 선택할 때 고려해야 할 추가 사항은 다음과 같습니다.
- 성능
- 보안
- 검색엔진 최적화
- 언어 번역 지원
- 타사 통합
이러한 요소는 패턴 선택에 영향을 미치지만 콘텐츠와 코드 자체를 만드는 사용자도 고려해야 합니다. 선택하는 패턴은 편집기 생성 콘텐츠 또는 사용자 제작 콘텐츠와 관련된 잠재적 제한사항을 처리할 만큼 강력해야 하며 모든 접근성 지식을 갖춘 개발자가 사용할 수 있는 방식으로 빌드되어야 합니다.
이해도 확인
패턴에 대한 지식 테스트
접근 가능한 구성요소는 항상 사용자가 액세스할 수 있나요?