많은 사람들이 개발 워크플로 프로세스에서 패턴 스타일 가이드, 구성요소 라이브러리 또는 전체 디자인 시스템을 사용하여 구성요소 기반 개발을 사용합니다. 이러한 도구를 공식적으로 사용하지 않았더라도 웹사이트, 앱 또는 기타 디지털 제품의 대규모 디자인을 관리 가능한 부분으로 나누는 유사한 프로세스를 사용할 가능성이 높습니다.
물리적 구조물을 만드는 것처럼 한 번에 한 조각씩 만드는 것이 중요합니다. 먼저 기초, 구조, 벽, 창문, 지붕, 그 사이의 모든 것. 구성요소 기반 개발 도구를 사용하면 웹사이트, 앱, 기타 디지털 제품에 대해 이 작업을 실행할 수 있습니다.
구성요소 기반 개발의 장점으로는 관리 가능한 부분으로 나누어 재사용 가능한 구성요소를 사용하므로 개발 시간이 단축된다는 점이 있습니다. 이를 통해 디자이너, 프런트엔드 및 백엔드 개발자, QA가 동시에 작업할 수 있습니다. 클라이언트, 디자이너, PM 등은 빌드 프로세스를 미리 볼 수 있고 웹사이트가 출시된 후에는 라이브 스타일 가이드를 참조로 사용할 수 있기 때문에 좋아합니다.
하지만 접근성을 고려하여 패턴, 구성요소, 디자인 시스템을 살펴보면 몇 가지 의문이 듭니다. 접근성 측면에서 어떤 패턴이 가장 적합한지 어떻게 알 수 있나요? 확립된 패턴이나 라이브러리를 사용해야 할까요, 아니면 새로운 패턴이나 라이브러리를 만들어야 할까요? 이러한 패턴이 실제로 사용자에게 도움이 되는지 어떻게 알 수 있나요?
다양한 선택지가 있어 패턴, 구성요소, 디자인 시스템에 대해 혼동이 있을 수 있습니다. 이 모듈은 접근성을 위해 패턴, 구성요소, 디자인 시스템을 평가하는 방법에 관한 일반적인 정보를 제공하고 접근성이 더 뛰어난 선택을 하는 데 도움이 되는 출발점을 제공합니다.
비판적으로 생각하기
접근성 패턴, 구성요소 또는 디자인 시스템을 선택하는 것은 어려운 일이 아니지만 시간과 비판적 사고가 필요합니다. 사실 '하나의 완벽한 패턴'은 없지만 작동할 수 있는 옵션은 여러 개 있을 수 있습니다. 고유한 상황에 가장 적합한 옵션을 선택하는 방법을 배우는 것입니다.
이후 테스트 모듈에서는 접근성 패턴, 구성요소, 디자인 시스템을 평가하는 기법과 방법에 대해 자세히 알아봅니다. 그 전에 다음과 같은 기본적인 질문을 스스로에게 던져야 합니다.
- 이미 확립된 접근성 패턴, 구성요소 또는 디자인 시스템이 있나요?
- 어떤 브라우저와 보조 기술 (AT)을 지원해야 하나요?
- 코드 또는 프레임워크 제한사항이 있나요? 고려해야 할 다른 통합, 요소 또는 사용자 요구사항이 있나요?
개발 환경과 사용자 요구사항에 따라 이 외의 질문이 추가되거나 달라질 수 있습니다. 접근성 평가의 시작점으로 다음 질문을 고려하세요.
확립된 리소스
새로운 것을 만들기 전에 접근성 패턴, 구성요소, 디자인 시스템 측면에서 이미 존재하는 것을 실사하고 검토하세요. 조금만 조사해 보면 필요에 맞는 솔루션 (또는 여러 솔루션)을 찾을 수 있습니다.
액세스 가능한 패턴, 구성요소, 디자인 시스템에 관한 유용한 리소스는 다음과 같습니다.
- 접근성 구성요소
- Deque University ARIA 라이브러리
- Gov.UK 디자인 시스템
- 포함된 구성요소
- MagentaA11y
- 미국 연방 정부를 위해 만들어진 미국 웹 디자인 시스템 (USWDS)
- Smashing Magazine의 접근성 패턴 목록
JavaScript 프레임워크의 경우 다음 리소스는 기본적으로 액세스 가능하거나 접근성을 위해 맞춤설정할 수 있습니다.
- CSS만으로는 충분하지 않은 경우: 접근성 있는 구성요소를 위한 JavaScript 요구사항
- React
- Angular: Material 라이브러리
- Vue: Vuetensils
하지만 코드를 복사/붙여넣기하여 환경에 적합하고 사용자 요구사항을 자동으로 충족한다고 가정해서는 안 됩니다. 완전히 접근 가능하다고 표시된 경우에도 모든 패턴, 구성요소, 디자인 시스템에 적용됩니다.
모든 리소스는 시작점으로 간주해야 합니다. 모든 것을 테스트해야 합니다.
브라우저 및 보조 기술 (AT) 지원
개발 환경에 적합한 몇 가지 기본 패턴, 구성요소 또는 전체 디자인 시스템을 조사한 후 보조 기술 지원으로 이동할 수 있습니다. 패턴, 구성요소, 디자인 시스템을 평가할 때 집중해야 하는 주요 지원 기술 유형 중 하나는 스크린 리더입니다.
스크린 리더는 특정 브라우저를 염두에 두고 제작되었으며 이러한 브라우저와 함께 사용할 때 가장 잘 작동합니다. AT 테스트 모듈에서 이 주제를 훨씬 더 자세히 다루겠지만, 패턴 평가를 위해서는 이러한 조합이 존재한다는 것을 이해하여 지원 측면에서 무엇이 필요한지 아는 것이 좋습니다.
| 스크린 리더 | OS | 브라우저 호환성 | 비용 |
|---|---|---|---|
| Job Access with Speech (JAWS) | Windows | Chrome, Firefox, Edge | 라이선스 필요 (40분 무료 버전 있음) |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome 및 Firefox | 무료 (다운로드 필요) |
| Narrator | Windows | 에지 | 무료 (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 프레임워크를 사용하면 개발자가 원하는 패턴을 거의 모두 사용할 수 있습니다. 이러한 경우 제한이 적어 가장 접근성이 좋은 패턴 옵션을 선택할 수 있습니다.
패턴, 구성요소 또는 디자인 시스템을 선택할 때는 다음과 같은 추가 고려사항을 고려해야 합니다.
- 성능
- 보안
- 검색엔진 최적화
- 언어 번역 지원
- 타사 통합
이러한 요소가 패턴 선택에 영향을 미치는 것은 분명하지만 콘텐츠와 코드를 만드는 사람도 고려해야 합니다. 선택한 패턴은 편집자 생성 콘텐츠 또는 사용자 제작 콘텐츠와 관련된 잠재적 제한사항을 처리할 수 있을 만큼 강력해야 하며, 모든 접근성 지식의 개발자가 사용할 수 있는 방식으로 빌드해야 합니다.