도서 소개
웹 접근성 관련 이론과 표준(WCAG)을 탄탄히 설명할 뿐만 아니라, '자주 있는 사례에서 문제 알아보기'와 '자주 있는 사례를 개선하다'에서 실제 개발 및 디자인 과정에서 흔히 겪는 문제점을 지적하고, 명확하게 해결 방법을 제시한다. 웹 접근성의 기본적인 내용부터 복잡한 UI 패턴과 디자인 시스템 활용 그리고 조직 내 접근성 문화 정착에 이르기까지 다양한 측면을 아우르기에 실무자들이 즉시 적용할 수 있다.
출판사 리뷰
“웹 접근성의 바이블”
이 책은 웹 접근성 관련 이론과 표준(WCAG)을 탄탄히 설명할 뿐만 아니라, '자주 있는 사례에서 문제 알아보기'와 '자주 있는 사례를 개선하다'에서 실제 개발 및 디자인 과정에서 흔히 겪는 문제점을 지적하고, 명확하게 해결 방법을 제시합니다.
웹 접근성의 기본적인 내용부터 복잡한 UI 패턴과 디자인 시스템 활용 그리고 조직 내 접근성 문화 정착에 이르기까지 다양한 측면을 아우르기에 실무자들이 즉시 적용할 수 있습니다.
웹 접근성의 중요성을 깊이 이해하고 사용성 높은 웹 서비스를 만들고자 하는 모든 웹 관련 종사자인 개발자, 디자이너, 기획자, 프로젝트 관리자 등에게 필독서입니다. 웹 접근성 역량을 강화하고 웹 환경을 구축하는 데 이 책은 훌륭한 지침서가 될 것입니다.
이 책을 추천합니다.
접근성에 흥미가 있는 디자이너나 엔지니어
웹 애플리케이션을 개발하고 있는 분
HTML, CSS, JavaScript의 기본적인 문법을 이해하고 있는 분
React 프로그램을 몰라 걱정인 분(해당 부분에서 해설하므로 읽는 데 지장이 없습니다.)
작가 소개
지은이 : 이하라 리키야
2004년에 주식회사 비즈니스 아키텍츠에 입사해 정보 아키텍트로 활동했다. 2017년에 freee 주식회사에 입사했다. 다양한 업무처리 방식의 실현을 목표로 디자인 팀을 관리하거나 접근성을 보급하는 활동을 하고 있다. 외부 컨설턴트로서 note, Ubie, STUDIO, 도쿄도 신형 코로나바이러스 감염증 대책 사이트의 접근성 개선을 지원했다. 웹 접근성 기반위원회(WAIC) 위원, 인간중심 설계추진기구(HCD-Net) 평가위원이다. 저서(공동 집필)로 ‘디자이닝 웹 접근성’, 감역서로 ‘코딩 웹 접근성’, ‘인클루시브 HTML + CSS & 자바스크립트’가 있다.트위터: @magi1125
지은이 : 고바야시 다이스케
2012년에 cybozu 주식회사에 신입 사원으로 입사했다. 프로그래머로 클라우드 서비스 ‘kintone’의 개발에 참여했다. 2014년에 저시력자 직원의 사용성 테스트를 관찰한 일을 계기로 접근성 개선 활동을 시작했다. 접근성 전문가로서 접근할 수 있는 디자인과 개발 지도, 사내 가이드라인 작성 등에 종사했다. 2021년부터 kintone의 디자인 시스템 구축에 참여했다. 웹 접근성 기반위원회(WAIC) 워킹그룹 1의 주임이다.트위터: @sukoyakarizumu
지은이 : 마스다 소이치
2007년에 주식회사 구조계획연구소에 입사해 제조업 고객에 대한 법인 영업과 마케팅을 담당했다. 2014년에 데지파 주식회사에 입사해 프런트엔드 엔지니어로 전직했다. 2017년에 주식회사 사이버 에이전트에 입사하여 방송 플랫폼, 공영경기투표 서비스의 웹 프런트 개발을 걸쳐 아메바 블로그, ABEMA의 접근성 향상 프로젝트를 추진했다. 2021년에 주식회사 SmartHR에 입사했다. 직원 설문조사 기능의 프로덕트 디자인을 담당했고 접근성과 다언어화를 전문으로 하는 프로그레시브 디자인 그룹을 만들어 매니저로 취임했다. 현재는 전사 차원의 접근성 추진을 담당하고 있다.트위터: @masuP9
지은이 : 야마모토 레이
게이오기주쿠대학 정책미디어 연구과 석사 과정을 수료 후 모바일 게임을 만드는 벤처 기업을 거쳐 2014년에 freee 주식회사에 입사했다. 프런트엔드 개발을 중심으로 엔지니어로서 회계와 인사노무 소프트웨어의 기능 개발에 참여했다. 2019년에 디자이너로 전직하여 현재는 사내에서 사용하는 디자인 시스템 구축, 사원 연수를 비롯한 접근성 보급 활동, 접근성이 좋은 제품을 릴리즈하기 위한 프로세스 정비 등에 참가하고 있다.트위터: @ymrl
목차
머리말
저자 소개
옮긴이의 말
베타 리더 추천사
제1장 웹 접근성이란
1.1 접근성이란
단어로서의 정의
사용성과의 비교
접근성은 사용하기 쉬운 정도다?
1.2 웹 접근성이란
웹에 있기만 하면 접근성이 압도적으로 높다
웹 콘텐츠는 형태를 바꿀 수 있다
1.3 웹 접근성과 ‘장애’
장애의 종류별 개요와 이용 상황
노화와 장애
일시적인 장애
의학 모델과 사회 모델
1.4 WCAG: 웹 접근성의 표준
WCAG의 개요
세 가지 적합 레벨과 그 내용
접근성 지원 여부
1.5 웹 접근성을 개선하는 이유
사용자를 늘린다
사용성을 높일 수 있다
권리를 지키며 법을 준수할 수 있다
1.6 왜 웹 애플리케이션 접근성인가
꾸준히 이용함으로써 생활이나 업무가 변화하므로
공동 이용을 하는 데 모두가 사용할 수 있어야 하므로
기업의 미션으로 이어지므로
제2장 웹 접근성의 기초
2.1 기초 머신 리더블 이해하기
아무것도 읽지 못하며 조작할 수 없는 버튼 - ‘이름’과 ‘역할’
선택 여부를 알 수 없는 체크 박스 - ‘상태’
HTML 시맨틱스와 이를 보완하는 WAI-ARIA
HTML과 WAI-ARIA와 AOM(접근성 오브젝트 모델)
2.2 키보드 조작의 기본
자주 있는 사례에서 문제 알아보기
[사례 1] 키보드로 조작할 수 없다 - 인터랙티브 요소를 사용하지 않았다
[사례 2] 키보드로 조작할 수 없다 - 인터랙티브 요소를 가렸다
[사례 3] 키보드로 조작할 수 없다 - 마우스로만 표시되는 UI
[사례 4] 키보드 조작 시 현재 위치를 알 수 없다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선?] 인터랙티브 요소를 사용해서 키보드 조작을 가능케 한다
[사례 1 개선?] 포커스를 받아 키 이벤트로 실행 가능하도록 한다 - 인터랙티브 요소를 사용할 수 없을 때
[사례 2 개선] 키보드 조작으로 포커스가 가능한 상태에서 인터랙티브 요소를 감춘다
[사례 3 개선] 마우스 이벤트와 키보드 이벤트를 병행해 키보드를 조작할 때 표시한다
[사례 4 개선?] 적절한 포커스 인디케이터를 표시한다
[사례 4 개선?] 필요할 때만 포커스 인디케이터를 표시한다
2.3 비텍스트 콘텐츠의 머신 리더빌리티
자주 있는 사례에서 문제 알아보기
[사례 1] 대체 텍스트가 부여되지 않은 이미지
[사례 2] 접근 가능한 이름이 없는 UI
[사례 3] 장식을 위한 시각 표현에 텍스트 데이터가 존재한다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선?] 이미지에 대체 텍스트를 부여한다
[사례 1 개선?] 사용자가 이미지에 대체 텍스트를 설정할 수 있도록 한다
[사례 1 개선?] 그래프나 차트를 대체할 콘텐츠를 제공한다
[사례 2 개선] UI에 접근 가능한 이름을 부여한다
[사례 3 개선] 장식을 위한 시각 표현을 무시한다
2.4 콘텐츠 구조의 머신 리더빌리티
자주 있는 사례에서 문제 알아보기
[사례 1] 표제가 표제로서 마크업되지 않았다
[사례 2] 정보의 관계성을 마크업하지 않았다
[사례 3] 정보의 그룹을 마크업하지 않았다
[사례 4] 시각적인 표현을 위해 잘못된 시맨틱스를 사용했다
체크 포인트
자주 있는 사례를 개선하다
[사례 1의 개선] 표제를 표제로서 마크업한다
[사례 2의 개선] 마크업으로 정보를 연관 짓다
[사례 3의 개선] 마크업으로 그룹화한다
[사례 4의 개선] 시각 표현을 위해 사용한 시맨틱스를 삭제한다
제3장 폼 개선
3.1 레이블과 설명
자주 있는 사례에서 문제 알아보기
[사례 1] 플레이스 홀더로 레이블을 표현했다
[사례 2] 레이블과 설명 배치를 이해하기 어렵다
[사례 3] 폼 제어에 레이블과 설명을 연관 짓지 않았다
[사례 4] 그룹에 레이블과 설명을 연관 짓지 않았다
[사례 5] 필수 입력의 설명이 전달되지 않는다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 레이블이나 설명을 플레이스 홀더 바깥쪽에 배치한다
[사례 2 개선] 폼 제어·그룹 레이블과 설명을 이해하기 쉽게 배치한다
[사례 3 개선?] 폼 제어에 레이블과 설명을 연관 짓는다 - label 요소를 사용했을 때
[사례 3 개선?] 폼 제어에 레이블과 설명을 연관 짓는다 - WAI-ARIA를 사용했을 때
[사례 3 개선?] 폼 제어에 보이지 않는 레이블을 붙인다
[사례 4 개선?] 그룹에 레이블과 설명을 연관 짓는다 - fieldset 요소와 legend 요소를 사용했을 때
[사례 4 개선?] 그룹에 레이블과 설명을 연관 짓는다 - WAI-ARIA를 사용했을 때
[사례 5 개선] 필수 입력 여부를 텍스트로 설명한다
3.2 입력 지원
자주 있는 사례에서 문제 알아보기
[사례 1] 필요 이상으로 입력을 요구한다
[사례 2] 하나의 입력값을 나타내는 폼 제어가 분할되어 있다
[사례 3] 브라우저의 자동 완성을 사용할 수 없다
[사례 4] 입력값 종류에 적절한 입력 형식이 선택되지 않았다
[사례 5] 선택지가 있는 입력란에 적절한 폼 제어가 선택되지 않았다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 입력 항목 개수를 최소화한다
[사례 2 개선] 하나의 입력값을 나타내는 폼 제어를 합친다
[사례 3 개선] 자동 완성되도록 마크업한다
[사례 4 개선?] 입력값 종류에 따라 입력 형식을 지정한다
[사례 4 개선?] 소프트웨어 키보드의 종류를 지정한다 - inputmode 속성과 pattern 속성
[사례 4 개선?] 인터페이스의 입력을 제한한다 - max 속성·min 속성·step 속성·maxlength 속성
[사례 5 개선?] 선택식 폼 제어를 검토한다 - 라디오 버튼·체크 박스
[사례 5 개선?] 선택식 폼 제어를 검토한다 - 셀렉트 박스·리스트 박스
[사례 5 개선?] 선택식 폼 제어를 검토한다 - 콤보 박스
3.3 제약의 검증과 오류
자주 있는 사례에서 문제 알아보기
[사례 1] 오류 발생 위치와 오류 메시지의 관계를 알기 어렵다
[사례 2] 다양한 사용자에게 오류를 알리는 방법을 검토하지 않았다
[사례 3] 오류 수정 방법을 알기 어렵다
[사례 4] 필요 이상으로 입력을 제약했다
[사례 5] 사용자가 직접 조작을 검증할 수단이 없다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선?] HTML 표준 제약 검증을 이용한다
[사례 1 개선?] 독자적인 오류를 알기 쉽게 디자인한다
[사례 1 개선?] 독자적인 오류를 마크업한다 - 폼 제어의 경우
[사례 1 개선?] 독자적인 오류를 마크업한다 - 그룹의 경우
[사례 2 개선?] 오류 발생 여부와 발생 위치를 알기 쉽게 알린다
[사례 2 개선?] 패턴 1: 전송 시에 폼 제어로 포커싱한다
[사례 2 개선?] 패턴 2: 전송 시에 오류 요약을 표시한다
[사례 2 개선?] 패턴 3: 입력 시에 실시간으로 검증한다
[사례 3 개선?] 오류 수정 방법을 이해하기 쉽게 작성한다
[사례 3 개선?] 오류 수정 후보를 제안한다
[사례 4 개선] 입력 제약을 최소화한다
[사례 5 개선] 사용자가 직접 조작을 검증할 수 있도록 한다
3.4 사용자가 예측할 수 있는 작동
자주 있는 사례에서 문제 알아보기
[사례 1] 폼 제어 값을 변경했을 때 화면 전환이 발생한다
[사례 2] 페이지를 로딩할 때나 폼 제어에 값을 입력할 때 포커스가 이동한다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 사용자가 콘텐츠의 큰 변화를 예측할 수 있도록 한다
[사례 2 개선] 사용자가 포커스 이동을 예측할 수 있도록 한다
3.5 커스텀 컴포넌트
자주 있는 사례에서 문제 알아보기
[사례 1] 커스텀 컴포넌트의 필요성을 제대로 파악하지 않았다
[사례 2] 기존의 커스텀 컴포넌트 샘플을 참고하지 않았다
[사례 3] 키보드 조작이 적절히 설계되지 않았다
[사례 4] WAI-ARIA 사양을 따른 역할이 설정되지 않았다
[사례 5] WAI-ARIA 사양을 따른 속성·상태가 설정되지 않았다
[사례 6] 지원 기술로 검증하지 않았다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 애초에 커스텀 컴포넌트를 이용해야 하는지 검토한다
[사례 2 개선] 접근성을 고려한 커스텀 컴포넌트 샘플을 참고한다
[사례 3 개선] 적절한 키보드 조작을 설계한다
[사례 4 개선] 적절한 WAI-ARIA 역할을 검토한다
[사례 5 개선] 적절한 WAI-ARIA 속성·상태를 검토한다
[사례 6 개선] 지원 기술로 검증한다
제4장 UI 디자인의 개선
4.1 색과 대비
자주 있는 사례에서 문제 알아보기
[사례 1] 색만으로 정보를 제공했다
[사례 2] 명암비가 너무 낮다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 색 이외의 수단으로도 정보를 제공한다
[사례 2 개선?] 문자의 명암비를 개선한다
[사례 2 개선?] 문자 이외의 명암비를 개선한다
[사례 2 개선?] 되도록 명암비를 높이거나, 문자를 크고 굵게 표시한다(명암비를 확보할 수 없을 때)
4.2 텍스트 크기
자주 있는 사례에서 문제 알아보기
[사례 1] 터치 디바이스에서 핀치 아웃으로 화면을 확대하지 못한다
[사례 2] 화면을 확대하면 위치가 고정된 요소가 화면을 가려버린다
[사례 3] 브라우저의 문자 크기 변경 기능이 반영되지 않는다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 핀치 아웃으로 화면을 확대할 수 있게 한다
[사례 2 개선] 위치가 고정된 요소를 확대했을 때의 표시 방법을 검토한다
[사례 3 개선] 폰트 사이즈는 상대 단위로 지정한다
4.3 텍스트 레이아웃
자주 있는 사례에서 문제 알아보기
[사례 1] 줄이 너무 길다
[사례 2] 줄 간격이나 단락 간격이 좁다
[사례 3] 텍스트가 양쪽 정렬됐다
[사례 4] 공백 문자를 사용해 문자 간격을 조정했다
[사례 5] 텍스트 블록의 크기를 고정했다
[사례 6] 문자 이미지로 텍스트 레이아웃을 고정했다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 줄을 적절한 길이로 맞춘다
[사례 2 개선] 줄 간격과 단락 간격을 넓게 한다
[사례 3 개선] 양쪽 정렬을 사용하지 않는다
[사례 4 개선] CSS를 사용해 문자 간격을 조정한다
[사례 5 개선] 텍스트 블록의 크기를 가변으로 한다
[사례 6 개선] 문자 이미지 사용은 최소화한다
4.4 라이팅
자주 있는 사례에서 문제 알아보기
[사례 1] 페이지의 언어가 지정되지 않았다
[사례 2] 페이지 제목에 페이지의 주제가 나타나지 않았다
[사례 3] 표제가 페이지의 개요를 표현하지 않았다
[사례 4] 링크 텍스트가 이동되는 곳을 표현하지 않았다
[사례 5] 감각적 특징에만 의존했다
[사례 6] 화면에 표시된 텍스트의 이름 속성을 덮어썼다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] lang 속성에 적절한 언어를 지정한다
[사례 2 개선] 주제가 나타나는 페이지 제목을 부여한다
[사례 3 개선] 표제만 추출해 페이지의 개요를 이해할 수 있도록 한다
[사례 4 개선] 링크 텍스트만으로도 이동되는 곳을 이해할 수 있도록 한다
[사례 5 개선] 감각적 특징과 함께 콘텐츠를 특정하는 텍스트를 전달한다
[사례 6 개선] 표시된 텍스트와 이름 속성을 일치시킨다
4.5 이미지의 대체 텍스트
자주 있는 사례에서 문제 알아보기
[사례 1] 대체 텍스트가 이미지 내용을 표현하지 않았다
[사례 2] 일러스트, 사진, 스크린샷의 대체 텍스트가 ‘일러스트’, ‘사진’, ‘스크린샷’으로 지정되어 있다
[사례 3] 장식 이미지에 대체 텍스트가 설정되어 있다
[사례 4] 기능을 가진 이미지의 대체 텍스트가 외관을 나타냈다
[사례 5] 문자 이미지가 나타내는 텍스트 중 일부만 대체 텍스트로 설정했다
[사례 6] 그래프나 그림의 대체 텍스트를 ‘그래프’, ‘그림’으로 설정했다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 이미지 내용을 나타내는 대체 텍스트를 설정한다
[사례 2 개선] 정보를 제공하는 이미지의 대체 텍스트로는 중요한 정보를 짧게 전달한다
[사례 3 개선] 장식 이미지의 대체 텍스트는 공백으로 한다
[사례 4 개선] 기능을 갖는 이미지의 대체 텍스트라면 해당 기능을 설명한다
[사례 5 개선] 문자 이미지에 적힌 텍스트를 문자 이미지의 대체 텍스트로 설정한다
[사례 6 개선] 제공된 데이터 또는 동등한 정보를 그래프나 그림의 대체 텍스트로 설정한다
4.6 동영상·음성 매체
자주 있는 사례에서 문제 알아보기
[사례 1] 동영상·음성 콘텐츠에서 음성을 듣지 않으면 내용을 이해할 수 없다: 녹화된 콘텐츠의 경우
[사례 2] 동영상·음성 콘텐츠에서 음성을 듣지 않으면 내용을 이해할 수 없다: 실시간 방송의 경우
[사례 3] 동영상 콘텐츠에서 영상을 보지 않으면 내용을 이해할 수 없다
[사례 4] 동영상·음성이 자동 재생된다
[사례 5] BGM의 음량이 너무 크다
[사례 6] 미디어 플레이어의 접근성이 낮다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선?] 동영상·음성에 대체 콘텐츠(캡션, 자막)를 제공한다
[사례 1 개선?] 적절한 캡션 제공 방법을 선택한다
[사례 2 개선] 실시간 방송에 대체 콘텐츠(캡션, 자막)를 제공한다
[사례 3 개선] 음성만으로 동영상을 이해할 수 있도록 한다
[사례 4 개선] 사용자의 동의를 얻고 동영상과 음성을 재생한다
[사례 5 개선] BGM의 음량은 낮게 한다
[사례 6 개선] 미디어 플레이어의 접근성을 확보한다
4.7 애니메이션
자주 있는 사례에서 문제 알아보기
[사례 1] 자동 재생되는 애니메이션을 제어할 수 없다
[사례 2] 사용자 조작으로 재생되는 애니메이션을 제어할 수 없다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선?] 애니메이션을 짧은 시간만 표시하던가 애니메이션을 이용하지 않는다
[사례 1 개선?] 자동 재생되는 애니메이션은 사용자가 일시정지 및 정지 가능하거나 숨길 수 있도록 한다
[사례 2 개선] 사용자 조작에 의한 애니메이션을 비활성화할 수 있도록 한다
4.8 모바일 디바이스
자주 있는 사례에서 문제 알아보기
[사례 1] 콘텐츠가 화면 크기에 최적화되지 않았다
[사례 2] 표시되는 방향을 제한했다
[사례 3] 터치 대상이 너무 작다
[사례 4] 제스처에만 의존했다
[사례 5] 데스크톱 특유의 조작에만 의존했다
[사례 6] 모바일 디바이스 특유의 지원 기술을 고려하지 않았다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 반응형 디자인을 채택한다
[사례 2 개선] 표시되는 방향을 한 방향으로 제한하지 않는다
[사례 3 개선] 터치 대상의 크기를 키운다
[사례 4 개선] 제스처는 사용하지 않거나 대체 수단을 마련한다
[사례 5 개선] 데스크톱 특유의 조작은 사용하지 않거나 대체 수단을 마련한다
[사례 6 개선] 모바일 디바이스의 지원 기술로 검증한다
4.9 페이지의 레이아웃과 일관성
자주 있는 사례에서 문제 알아보기
[사례 1] 페이지 레이아웃이 시각적 특징만으로 표현됐다
[사례 2] 페이지가 랜드마크로 적절히 분할되지 않았다
[사례 3] 페이지 레이아웃에 일관성이 없다
[사례 4] 컴포넌트에 일관성이 없다
[사례 5] 현재 위치를 알 수 없다
체크 포인트
자주 있는 사례를 개선하다
[사례 1 개선] 표제를 이용해 페이지의 영역에 쉽게 도달하도록 한다
[사례 2 개선] 랜드마크를 이용해 페이지의 영역에 쉽게 도달하도록 한다
[사례 3 개선] 페이지의 레이아웃을 통일한다
[사례 4 개선] 페이지의 컴포넌트를 통일한다
[사례 5 개선] 현재 위치를 파악할 수단을 마련한다
제5장 복잡한 UI 패턴 개선
5.1 모달 다이얼로그
모달 다이얼로그의 사례와 문제점
다이얼로그의 인터랙티브 요소를 곧바로 포커싱할 수 없다: 포커스 제어 구현
다이얼로그 바깥으로 포커스가 이동한다: 포커스 트랩 구현
요소의 상태를 머신 리더블하게 한다: WAI-ARIA의 활용
모달 다이얼로그의 개선 사례
최신 HTML 사양인 dialog 요소의 기대
5.2 알림
소극적인 알림을 스크린 리더에도 전달한다: 라이브 리전
페이지 밖에서의 알림: Notifications API
알림 제한 시간: 마음대로 사라지는 알림과 현실적인 대처법
5.3 캐러셀
이미지 자동 전환을 일시 정지할 수 있도록 한다
다양한 사용자가 이미지를 전환할 수 있도록 한다
표시하지 않은 이미지를 모든 환경에서 보거나 조작할 수 없도록 한다
이미지 자동 전환을 스크린 리더에 알리지 않는다
캐러셀이 꼭 필요한지 재검토한다
5.4 단순한 툴팁
단순한 툴팁의 사례와 문제점
화면 확대·키보드 조작 문제와 개선: 툴팁 표시·미표시 제어
스마트폰·스크린 리더의 문제와 개선: 마우스 오버 의존에서 탈피
5.5 풍부한 툴팁
풍부한 툴팁의 사례와 문제점
포커스 제어를 구현한다: 키보드 조작과 스크린 리더를 지원
툴팁 정리하기
5.6 드래그 앤 드롭
드래그 앤 드롭 조작 시 문제점: 키보드 조작에 의한 대체
드래그 앤 드롭의 대체 수단
5.7 햄버거 메뉴
햄버거 메뉴의 사례와 문제점
메뉴를 열고 닫는 버튼을 접근 가능하도록 한다
메뉴를 접근 가능하도록 한다
햄버거 메뉴의 개선 사례
HTML 표준 요소를 사용해 열고 닫힌 상태를 갖는 UI를 구현한다:
디스클로저(summary 요소·details 요소)
5.8 화면 전환
클라이언트 사이트 라우팅의 문제점
클라이언트 사이드 라우팅을 접근 가능하도록 한다
클라이언트 사이트 라우팅에서도 a 요소를 사용한다
제6장 디자인 시스템과 접근성
6.1 디자인 시스템이란
디자인 시스템의 구성
디자인 시스템의 장점
디자인 시스템 제정과 도입 시의 의사 결정
6.2 디자인 시스템과 접근성의 관계
디자인 시스템의 일부로 접근성을 포함하는 장점
유명한 디자인 시스템에서의 접근성의 위상
접근성을 ‘좋은 제약’으로 활용할 수 있다
6.3 디자인 시스템에 접근성을 포함시킨다
디자인 원리에 포함시킨다
스타일 가이드에 포함시킨다
패턴 라이브러리에 포함시킨다
6.4 디자인 시스템을 접근성 관점에서 강화한다
접근성과 연관된 직종과 역할
접근 가능하도록 하기 위한 역할과 작업 방법 정의
접근성 강화를 위해서 준비할 수 있는 것
6.5 디자인 시스템만으로는 접근할 수 없다
디자인 시스템 작성자의 의도대로 사용하지 않는다
페이지 전체 및 제품 전체의 상황을 알 수 없다
각자가 책임감을 갖는다
제7장 접근성의 조직 도입
7.1 이 장을 읽는 법과 사용법
7.2 정보를 공유하고 동료를 찾는다
7.3 사내 커뮤니티를 설립한다
7.4 자신의 생각을 사내에서 발언한다
7.5 작은 규모의 개선을 시도한다
7.6 주변에서 확인 및 개선 가능하도록 지원한다
7.7 접근성이 필요한 사람과 만나다
7.8 접근성 면에서 사내 오너가 된다
제8장 접근할 수 있는 UI 설계의 원리를 이끌어내다.
8.1 처음부터 접근 가능하도록 하려면
8.2 이용 상황으로부터 공통적 문제를 이끌어낸다
8.3 안티 패턴과 대책?: 한 화면에 많은 상태를 가진다
8.4 안티 패턴과 대책?: 텍스트가 생략된 화면
8.5 안티 패턴과 대책?: 작게 밀집된 조작 대상
8.6 안티 패턴과 대책?: 사용자가 요구하지 않은 작동
8.7 안티 패턴과 대책?: 확인과 보고가 많다
8.8 안티 패턴과 대책?: 입력 사항이 수고가 든다
8.9 접근 가능한 UI 설계 원리
부 록 지원 기술과 이용 상황
1 포인팅 디바이스와 지원 기술
2 키보드 조작과 지원 기술
3 조작 방식을 변경하는 지원 기술
4 화면 표시와 지원 기술
찾아보기
