목차10개 항목
출처와 참고
web.dev의 「Learn Accessibility」 강좌의 디자인과 사용자 경험, 패턴·컴포넌트·디자인 시스템 편을 바탕으로 재구성한 노트다.
왜 디자인 단계인가
접근성은 다 만든 뒤 검사로 고치는 것보다 그리기 전에 정하는 편이 싸다. 포커스 순서, 제목 구조, 오류 메시지 자리, 색 조합, 터치 대상 크기는 디자인 파일에서 이미 정해진다. 개발자가 나중에 고치려면 디자인을 다시 열어야 한다. Deque는 웹·앱 접근성 버그의 최대 67%를 디자인 단계에서 막을 수 있다고 본다.
사람은 시간, 기기, 잠, 건강, 쓰는 보조 기술에 따라 매번 다르게 쓴다. 디자인 단계의 접근성은 이 다양성을 처음부터 설계 조건으로 넣는 일이다. 다 만든 뒤의 평가는 접근성 평가 방법과 도구가 맡는다.
포용적 디자인
포용적 디자인(inclusive design)은 포용성·사용성·접근성을 하나의 사람 중심 방법으로 묶는다. 처음부터 「모두에게 맞는 하나」를 노리는 유니버설 디자인과 달리, 구체적인 한 사람이나 상황에서 출발해 다른 사람에게 넓혀 간다.
| 원칙 | 뜻 |
|---|---|
| 비교 가능한 경험 | 모두에게 같은 수준의 경험을 준다. 대안이라는 이유로 품질을 낮추지 않는다 |
| 상황 고려 | 어떤 환경에서 쓰든 가치를 준다 |
| 일관성 | 익숙한 관례를 논리적으로 쓴다 |
| 통제권 | 사람이 원하는 방식으로 내용에 접근하고 조작하게 한다 |
| 선택지 | 특히 복잡하거나 흔치 않은 과제는 여러 방법으로 끝낼 수 있게 한다 |
| 콘텐츠 우선순위 | 핵심 과제·기능·정보를 앞에 둔다 |
| 가치 더하기 | 기능마다 서로 다른 사용자에게 무엇을 더해 주는지 따진다 |
페르소나에 장애를 담는다
페르소나는 정량·정성 리서치를 바탕으로 만든 가상의 사용자다. 기능의 우선순위를 싸고 빠르게 정하고, 팀이 같은 사용자를 떠올리게 한다. 리서치 자체는 사용자 리서치에 있다.
장애는 영구적·일시적·상황적으로 생기고, 촉각·시각·청각·말하기에 걸친다(Microsoft Inclusive Design의 페르소나 스펙트럼). 페르소나에 장애를 담는 방법은 세 가지다.
| 방법 | 내용 |
|---|---|
| 장애 전용 페르소나 | 특정 장애가 있는 사용자를 따로 만든다 |
| 기존 페르소나에 더하기 | 이미 쓰는 페르소나에 장애와 그로 인한 행동을 넣는다 |
| 페르소나 스펙트럼 | 같은 어려움의 영구적(한 팔이 없음)·일시적(팔 골절)·상황적(아기를 안음) 판을 함께 둔다 |
예: 57세 UX 엔지니어, 젊은 나이에 발병한 파킨슨병으로 손이 떨린다
목표 음성 입력으로 코드 제안을 받는다 / 최소한의 키 입력으로 쇼핑한다
불편 키보드만으로 안 되는 사이트, 디자인 도구의 작은 터치 대상
변화 점점 키보드에 더 기댄다- 실제 인물이나 고정관념을 바탕으로 만들지 않는다. 장애인 한 명을 만났다면 그 한 명을 만난 것뿐이다.
- 페르소나는 사용자 테스트를 대신하지 못한다.
장애 시뮬레이터는 조심해서 쓴다
눈가리개, 시야를 흐리게 하는 안경, 색각 시뮬레이터 같은 체험은 동정이나 공감을 끌어낼 수는 있지만, 짧은 체험은 오래 그 장애로 살며 익힌 기술과 적응을 담지 못하고 「얼마나 불편할까」라는 오해만 키우기 쉽다. 대신 장애가 있는 사람이 직접 만든 영상·시연·튜토리얼을 보고, 실제 사용자와 테스트한다. 색각 시뮬레이터의 한계는 색과 움직임의 접근성에도 있다.
접근성 휴리스틱 리뷰
닐슨과 몰리치의 사용성 휴리스틱(1990)처럼, Deque는 2019년에 디지털 제품용 접근성 휴리스틱 10개를 냈다. 디자인 시안을 코드 없이 점검하는 틀이다.
| 휴리스틱 | 사용자가 할 수 있어야 하는 것 |
|---|---|
| 상호작용 방식 | 마우스·키보드·터치 등 원하는 입력 방식으로 쓴다 |
| 내비게이션과 길 찾기 | 내용을 찾고, 지금 어디 있는지 안다 |
| 구조와 의미 | 페이지 구조와 조작법을 이해한다 |
| 오류 예방과 상태 | 늘 보이는 안내로 실수를 피하고, 오류 메시지로 무엇이 틀렸고 어떻게 고치는지 안다 |
| 대비와 가독성 | 글과 의미 있는 정보를 쉽게 구분해 읽는다 |
| 언어와 읽기 쉬움 | 내용을 쉽게 읽고 이해한다 |
| 예측 가능성과 일관성 | 요소의 목적과 관계가 분명하다 |
| 시간과 보존 | 시간이 충분하고, 세션이 끝나도 입력을 잃지 않는다 |
| 움직임과 번쩍임 | 움직이거나 번쩍이는 요소를 멈출 수 있다 |
| 시각·청각 대안 | 보거나 들어야 하는 정보에 텍스트 대안이 있다 |
진행 방법: 휴리스틱마다 체크포인트를 두고 팀원 여럿이 각자 매긴 뒤 합친다. 점수는 뛰어남 +2, 통과 +1, 실패 −1, 해당 없음 0이다. 예를 들어 「내비게이션과 길 찾기」의 체크포인트는 이렇다.
- 모든 활성 요소에 분명한 포커스 표시가 있다.
- 페이지 제목이 구체적인 정보부터 시작하고
<h1>과 같거나 비슷하다. - 큰 구획마다 뜻이 통하는 제목이 있다.
- 링크 텍스트나 바로 옆 맥락만으로 목적을 안다.
- 페이지 맨 위에 포커스 때 나타나는 건너뛰기 링크가 있다.
접근성 주석: 핸드오프 전에 적는다
접근성 주석(accessibility annotation)은 디자인 파일 위에 화면으로는 보이지 않는 결정을 적어 개발자에게 넘기는 것이다. 와이어프레임부터 고해상도 시안까지 어느 단계든 달 수 있고, 사용자 흐름·조건부 상태·기능까지 다룬다. 디자인팀이나 접근성 전문가가 이끈다. Figma에는 접근성 주석 키트가 여럿 있고, Stark·axe for Designers 같은 플러그인은 대비 검사와 함께 대체 텍스트·포커스 순서·제목·랜드마크 주석을 시안 위에 단다(접근성 평가 방법과 도구). 핸드오프 일반은 디자인 도구와 개발자 핸드오프에 있다.
| 주석할 것 | 적는 내용 |
|---|---|
| 색 | 팔레트의 모든 조합별 대비비 |
| 버튼·링크 | 기본·호버·활성·포커스·비활성 상태 |
| 건너뛰기 링크 | 숨김·노출 상태와 목적지 |
| 이미지·아이콘 | 필수 이미지의 대체 텍스트, 장식 여부. 버튼처럼 동작하는 아이콘(「저장」, 「관심 없음」)은 이름이 필요하고, 텍스트 옆 장식 아이콘은 필요 없다 |
| 오디오·비디오 | 자막, 대본, 음성 해설 |
| 제목 | 제목처럼 보이는 모든 텍스트의 실제 제목 수준 |
| 랜드마크 | HTML·ARIA 영역 구분 |
| 상호작용 컴포넌트 | 누를 수 있는 요소, 호버 효과, 포커스 영역 |
| 키보드 | 첫 포커스 위치와 Tab 순서 |
| 폼 | 라벨, 도움말, 오류·성공 메시지. 월·연 입력처럼 칸 하나에 여러 라벨이 붙는 경우 |
| 접근 가능한 이름 | 보조 기술이 각 요소를 무엇이라 부를지 |
각 항목을 구현하는 방법은 접근 가능한 페이지 구조, 접근 가능한 폼과 오류 처리, ARIA와 접근 가능한 이름에 있다.
컴포넌트·패턴·디자인 시스템 고르기
큰 화면을 재사용 가능한 조각으로 나누는 컴포넌트 중심 개발에서는 컴포넌트 하나의 접근성이 제품 전체로 복제된다. 좋은 패턴은 모든 화면을 고치고, 나쁜 패턴은 모든 화면을 망친다. 디자인 시스템의 구성과 구축은 디자인 시스템에 있다.
완벽한 패턴은 없다. 상황에 가장 맞는 것을 고른다. 먼저 세 가지를 묻는다.
| 질문 | 확인할 것 |
|---|---|
| 이미 검증된 패턴이 있나 | 새로 만들기 전에 아래 자료를 찾는다 |
| 어떤 브라우저와 보조 기술을 지원해야 하나 | 사용자 조합과 각 패턴의 실제 지원 수준 |
| 어떤 제약이 있나 | 코드·프레임워크·CMS·레거시, 연동, 사용자 요구 |
참고할 패턴 자료
| 종류 | 자료 |
|---|---|
| 패턴 명세 | W3C ARIA Authoring Practices Guide(APG) |
| 공공 디자인 시스템 | GOV.UK Design System, 미국 USWDS |
| 패턴 해설 | Inclusive Components, Scott O'Hara의 Accessible Components, Deque University ARIA 예제, MagentaA11y |
| 헤드리스 라이브러리 | React Aria, Radix UI, Ariakit, Angular CDK a11y |
| 지원 현황 | a11ysupport.io, HTML5 Accessibility |
어떤 자료도 그대로 복사해 끝내지 않는다. 「완전히 접근 가능」이라고 적힌 코드도 내 환경과 사용자에게 맞는지는 모른다. 출발점으로 쓰고 실제 보조 기술로 시험한다. 탭·디스클로저·캐러셀 같은 개별 위젯 구현은 접근 가능한 위젯: 펼침·탭·캐러셀에 있다.
그 밖에 따질 것
- 플랫폼 제약: CMS나 레거시 코드가 고를 수 있는 패턴을 한두 개로 좁히기도 한다. 반대로 JavaScript 프레임워크는 거의 어떤 패턴이든 허용하므로 가장 접근 가능한 쪽을 고를 수 있다.
- 함께 볼 품질: 성능, 보안, 검색 엔진 최적화, 번역 지원, 서드파티 연동.
- 사람: 편집자와 사용자가 넣는 콘텐츠(빈 alt, 제목 수준을 건너뛴 본문)를 견디는가. 접근성 지식이 제각각인 개발자도 틀리지 않고 쓸 수 있는 API인가.
정리
- 접근성 버그의 상당수는 디자인 단계에서 막을 수 있다. 다 만든 뒤 검사는 마지막 그물이다.
- 포용적 디자인은 한 사람의 구체적 상황에서 출발해 넓혀 간다.
- 페르소나에 영구적·일시적·상황적 장애를 담되, 시뮬레이터와 페르소나가 실제 사용자 테스트를 대신하지는 못한다.
- 시안은 접근성 휴리스틱으로 점검하고, 상태·순서·이름·대체 텍스트를 주석으로 적어 넘긴다.
- 컴포넌트와 디자인 시스템은 검증된 패턴에서 출발하되, 지원해야 할 보조 기술로 직접 시험한다.
관련 노트: 웹 접근성, 접근성 평가 방법과 도구, 접근 가능한 위젯: 펼침·탭·캐러셀, 디자인 시스템: 구성, 도입, 구축과 배포, 디자인 도구와 개발자 핸드오프, 사용자 리서치