웹 접근성 공부를 위해서 공부한 내용 시리즈
▶ 2024.02.17 - [Web] - 웹 표준, 웹 호환성, 웹 접근성
▶ 2024.02.21 - [Web] - 웹 접근성 시나리오
▶ 2024.02.25 - [Web] - 웹 접근성이 왜 필요할까? <= 현재 글
▶ 2024.03.16 - [Web] - 웹 접근성 기술 학습
▶ 2024.03.20 - [Web] - 웹 접근성 시나리오 - 2
▶ 2024.03.27 - [Web] - WAI-aria
▶ 2024.03.31 - [Web] - 웹 접근성 시나리오 - 3
▶ 2024.04.04 - [Web] - 사용자가 입력하는 이미지
웹 표준, 웹 호환성, 웹 접근성, 웹 접근성 시나리오 등 지금까지 공부를 했지만
결국 왜 웹 접근성이 필요한 것일까??
웹 접근성의 필요성
지금까지 [ 우리는 사용자 층 확대 ] 부분 또는 [ 기업 이미지 상승 ]에 대해서 중심적으로 알고 있었다.
하지만 딱 이미지를 봤을 때 눈에 보이는 [ 법 준수 ] 측면에서도 웹 접근성은 중요하다.
근데 웹 접근성을 지키지 않는다고 고소를 당할 수 있다는 사실은 들어본 적이 없는데...!
장애인 차별 금지 및 권리구제 등에 관한 법률 시행령 제14조에 따르면 법으로 지정되어 있다.
누구든지 신체적ㆍ기술적 여건과 관계없이 웹사이트를 통하여 원하는
서비스를 이용할 수 있도록 접근성이 보장되는 웹사이트
실제로 대한항공, 한국전력병원 등 사이트에서 소송을 당한 전적이 있다.
우리들이 만든 홈페이지가 대한항공 같이 사람이 많이 접근하는 사이트는 아닐 수 있지만 모든 프로젝트는 성공을
목표로 작업하는 거 아닐까? 그렇다면 당연히 지켜야 하는 이유가 될 수 있다.
해외에서의 웹 접근성
또한 웹 접근성에 해당하는 법은 우리나라만 있는 것이 아닌 해외에도 존재한다.
내가 만드는 프로젝트가 한국에서만 서비스되는 것이 아니라 다국적 서비스라면 골치 아파진다.
한국 기준으로 개발하는 것도 현실적으로 쉽지 않은데, 각 나라의 법을 다 지키면서 개발을 해야 할까?
그것은 아니다.
웹 표준의 경우 우리는 W3C를 통해서 확인할 수 있는 것처럼 웹 접근성은 WCAG라는 가이드라인이 있다.
모든 나라의 법이 WCAG를 기준으로 한다.
그러므로, WCAG 가이드라인으로 개발한다면 어느 나라에서든 웹 접근성이 법적으로 문제없는
사이트를 만들 수 있게 된다.
어떤 방식으로 웹 접근성을 고려해야 할까?
웹 접근성의 중요성을 알아보았다.
그렇다면 어떤 방식으로 웹 접근성을 고려할 수 있을까?
한국에서는 한국형 웹 콘텐츠 접근성 지침이라는 K-WCAG 2.1이 존재한다.
WCAG를 기반으로 만들어졌으며, 4개의 원칙, 13개의 지침, 24개의 검사항목으로 구성이 되어있다.
간략하게 알아보자면 다음과 같다.
대상자
- 시각을 통해 정보를 인지할 수 없는 시각 장애가 있는 경우
- 청각을 통해 음향 정보를 인지하지 못하는 청각 장애가 있는 경우
- 신체의 움직임에 제한이 있는 지체 장애가 있는 경우
- 읽기나 문장 이해력이 떨어지는 언어 장애가 있는 경우
- 키보드나 마우스를 사용할 수 없는 장애가 있는 경우
- 운전 중이거나 소음이 많은 곳에서 일하는 등 장애라기 보단 웹 사용자가 처한 환경에 따라 제한받는 경우
우리가 생각했을 때 웹 접근성은 대부분 시각 장애인들은 위해서 고려한다고 생각하지만
뿐만 아니라 다양한 유형의 고려사항이 존재한다.
시각장애 보조 기술 - 대체 텍스트
텍스트가 아닌 콘텐츠는 의미나 용도를 인식할 수 있게 대체 텍스트를 제공해야 한다.
이미지 등 텍스트가 아닌 콘텐츠를 이용할 경우, 의미나 용도를 동등하게 인식할 수 있도록
적절한 대체 콘텐츠를 제공해야 한다. 이때 대체 텍스트는 간단명료하게 제공되어야 한다.
(1) 구체적인 정보를 제공해야 하는 경우 : 이미지 링크, 이미지 버튼 등은 용도가 매우 명확하므로 이미지 링크나
이미지 버튼의 핵심 기능에 대한 설명을 간단한 대체 텍스트로 제공해야 한다.
(2) 의미 있는 배경 이미지 : 배경 이미지의 의미가 사용자에게 전달되어야 하는 콘텐츠는
그 의미가 보조 기술로 전달되도록 대체 텍스트를 제공해야 한다.
(3) 충분한 정보가 필요한 경우 : 데이터 차트와 같이 내용이 복잡한 콘텐츠는 사용자가 해당 콘텐츠의
의미를 충분히 파악할 수 있도록 대체 텍스트를 제공해야 한다.
시각장애 보조 기술 - 명료성
콘텐츠는 색에 관계없이 인식될 수 있어야 한다.
콘텐츠에서 제공하는 모든 정보는 특정한 색을 구별할 수 없는 사용자, 흑백 디스플레이 사용자 흑백 인쇄물을
보는 사용자 및 고대비 모드 사용자가 인식할 수 있도록 제공해야 한다.
(1) 색에 의한 정보 표현 방지 : 차트나 그래프 등을 고대비 모드로 화면에 표시하면 모든 색이
단색(회색조)으로 표시되어 사용자가 색을 구분하지 못하는 경우가 발생한다.
따라서 사용자가 경조 모드에서도 콘텐츠를 인식할 수 있도록 색을 이용하여
정보를 제공하지 않아야 한다. 즉, 색은 시각적인 강조를 위해서만 사용해야 한다.
(2) 무늬를 이용한 정보 제공 : 서로 다른 정보를 무늬로 구분하여 표시하면 경조 모드 사용자,
단색 디스플레이 사용자, 흑백 인쇄물의 사용자도 충분히 정보를 구분할 수 있다.
무늬와 색을 동시에 이용한 콘텐츠는 색각 장애가 있는 사용자도 접근이 가능하다.
※ 막간 꿀팁 - 다양한 명료성 테스트
렌더링을 들어가면 색맹 에뮬레이션이 있는데 이것을 통해서 적색맹, 청색맹 등 다양한 환경을 테스트할 수 있다.
시각장애 보조 기술 - 명확한 지시 사항 제공
지시 사항은 모양, 크기, 위치, 등에 관계없이 인식될 수 있어야 한다.
특정 요소를 가리키거나 지시 사항을 전달하는 콘텐츠에 대해서 시각이나 청각 등 특정 단일 감각에만
의존하는 방법으로 제공해서는 안된다.
구글의 설정 아이콘의 경우 경험을 통해서 해당 아이콘이 설정이라는 것을 알 수 있지만
해당 아이콘의 의미를 모르는 사람의 경우 인지할 수 없기 때문에 아래 툴팁으로 어떤 아이콘인지 설명을 하고 있다.
시각장애 보조 기술 - 명도 대비
텍스트 콘텐츠와 배경 간의 명도 대비는 4.5 대 1 이상이어야 한다.
웹 페이지에서 보이는 텍스트 콘텐츠와 배경 간 충분한 대비를 제공해서, 저시력 장애인, 노인 등 콘텐츠를 인식할
수 있도록 제공해야 한다.
다만, 로고, 장식의 목적의 콘텐츠, 마우스나 키보드를 활용해서 초점을 받았을 때 명도 대비가 커지는 콘텐츠 등은
예외로 한다.
개발자 도구에서 텍스트를 클릭하고 색상 영역의 네모 박스를 클릭하면 현재 배경과 텍스트 색상의
명도 대비를 알 수 있다. 네이버 [ 쇼핑 ] 텍스트는 #080808 색상으로 대비율이 20.02로 4.5를 훨씬 넘긴다.
이처럼 개발자 도구를 통해서 명도 대비를 확인할 수 있다.
※ 막간 꿀팁 - A, AA, AAA
명도 대비를 확인할 때 20.02 아래에 AA와 AAA라는 텍스트가 존재한다.
이 친구들은 모 하는 녀석들이길래 함께 나와있는 걸까?
WCAG 준수를 나타내는 데 사용되는 시스템이고 A는 필수 레벨, AA는 권장 레벨, AAA는 최대 레벨이다.
웹 접근성 A의 기준을 준수하지 못하는 경우 고소를 당할 확률이 높다.
명도 대비에서는 4.5라면 권장 레벨이다.
한국에서는 AA를 준수하라는 의미이다. 그렇다면 A는 몇일까? 3.0이다.
시각장애 보조 기술 - 콘텐츠 간의 구분
이웃한 콘텐츠는 구별될 수 있어야 한다.
웹 페이지를 구성하는 이웃한 콘텐츠는 구별될 수 있어야 한다.
(1) 테두리를 이용하여 구분함
(2) 콘텐츠 사이에 시각적인 구분선을 삽입하여 구분함
(3) 서로 다른 무늬를 이용하여 구분함
(4) 콘텐츠 배경색 간의 명도대비(채도)를 달리하여 구분함
(5) 줄 간격 및 글자 간격을 조절하여 구분함
(6) 기타 콘텐츠를 시각적으로 구분할 수 있는 방법 등
페이지네이션에서 현재 내가 몇 페이지에 있는지를 밑줄과 붉은색으로 나타내고 있는데,
이런 부분이 콘텐츠 간 구분이 잘 된 예시이다.
시각장애 보조 기술 - 제목 제공
페이지, 프레임, 콘텐츠 블록에는 적절한 제목을 제공해야 한다.
페이지, 프레임, 콘텐츠 블록의 제목은 사용자가 웹 콘텐츠를 운용하기 쉽게 도와준다.
각각의 제목은 간단명료해야 하며, 영역을 유추할 수 있도록 제공되어야 한다.
(1) 페이지 (title태그 사용) : 각 페이지는 해당 페이지만의 유일하고 서로 다른 제목을 가져야 한다.
(2) 프레임 (iframe, frame 태그의 title 속성) : 동일한 페이지에 포함된 모든 프레임은 해당 프레임만의
유일하고 서로 다른 프레임 제목을 가져야 한다.
(3) 콘텐츠 블록 (h계열 태그 사용) : 제목은 간단명료해야 하며, 해당 페이지, 프레임, 콘텐츠 블록을
유추할 수 있어야 한다.
(4) 표 (table 태그 안에 caption 태그 사용) : 제목은 간단명료해야 하며, 해당 페이지, 프레임, 콘텐츠 블록을
유추할 수 있어야 한다.
여기서 title 태그는 웹 접근성을 위해서도 중요하지만 SEO 측면에서도 중요하다!
검색을 했을 때 노출되는 부분이 title 태그이기 때문이다.
※ 막간 꿀팁 - title 태그 컨벤션
네이버의 경우에도 일관적인 title 태그의 컨벤션을 가지고 있다.
주제가 없는 경우 " 브랜드명 서비스" 형식으로 "네이버[브랜드명] 웹툰[서비스]" 구성되어 있다.
주제가 있는 경우 " 주제 : 브랜드명 서비스" 형식으로 "외모지상주의[주제] : 네이버[브랜드명] 웹툰[서비스]"
페이지를 이동할 때 스크린리더는 title 태그를 먼저 읽는다.
이때 모든 title이 동일하다면 스크린리더를 사용하는 사용자는 페이지를 이동했는지 제대로 인지하지 못하는 경우가
발생할 수 있다.
청각장애 보조 기술 - 멀티미디어 콘텐츠
멀티미디어 콘텐츠에는 자막, 대본 또는 수화를 제공해야 한다.
멀티미디어 콘텐츠를 장애인도 비장애인과 동등하게 인식할 수 있도록 제작하기 위해서는 자막, 대본 또는 수화를
제공해야 한다.
일반적으로 유튜브를 통해 자막을 통한 제공이 기능이 대부분 구현되어서 많이 사용된다.
신체 움직임 제한자 보조 기술 - 키보드 접근
모든 기능은 키보드 만으로도 사용할 수 있어야 한다.
웹 페이지에서 제공하는 모든 기능을 키보드만으로도 사용할 수 있도록 제공해야 한다.
다만 시뮬레이션 콘텐츠 등과 시각적인 방법으로만 접근이 가능한 지리 정보 콘텐츠 등은 예외로 할 수 있다.
네이버 로그인 페이지에서 첫 번째로 텝을 누르면 아이디로 포커스가 가고 그다음은 비밀번호, 마지막으로 로그인이
되는 것이 일반적인 플로우다.
하지만 로그인 버튼이 먼저 포커스가 되고 비밀번호, 아이디 순으로 간다면?
사용하는데 불편함이 있을 것이다.
이것을 지키는 가장 쉬운 방법은 선형 구조로 코드를 작성하는 것이다.
<form>
<input id={"id"}/>
<input id={"pw"}/>
<button>로그인</button>
</form>선형적으로 코드를 작성한다면 자연스럽게 포커스가 순서대로 이동할 것이다.
신체 움직임 제한자 보조 기술 - 조작 가능
사용자 입력 및 컨트롤은 조작이 가능하도록 제공되어야 한다.
(1) 컨트롤의 크기 : 콘텐츠에 포함된 모든 컨트롤은 대각선 방향 길이를 6.0mm 이상으로 제공하는 것이 바람직하다.
버튼이 너무 작으면 시각 장애인이 확인하기 힘들거나 손 떨림이 있는 사용자는
이용하기가 어렵다.
신체 움직임 제한자 보조 기술 - 응답 시간 조절
시간제한이 있는 콘텐츠는 응답시간을 조절할 수 있어야 한다.
웹 콘텐츠 제작 시 시간제한이 있는 콘텐츠는 가급적 포함하지 않는 것이 바람직하며, 보안 등의 사유로
시간제한이 반드시 필요할 경우 회피할 수 있는 수단을 제공해야 한다.
우리가 자주 보는 휴대폰 인증을 진행할 때 제한 시간이 노출되며, 시간 연장을 할 수 있는 기능을 제공한다.
공통 - 깜빡임과 번쩍임 사용 제한
초당 3~ 50회 주기로 깜빡이거나 번쩍이는 콘텐츠는 제공하지 않아야 한다.
깜빡이거나 번쩍이는 콘텐츠로 인해서 발작을 일으키지 않도록 초당 3~ 50회 주기로 깜빡이거나 번쩍이는 콘텐츠를
제공하지 않아야 한다.
공통 - 기본 언어 표시
주로 사용하는 언어는 명시해야 한다.
웹 브라우저는 웹 페이지를 구성하는 텍스트 콘텐츠의 언어 정보를 바탕으로 텍스트 콘텐츠를 화면에 표시하거나
보조 기술로 전달해야 한다.
<html lang="ko">
html 파일을 구성할 lang 옵션을 주는 경우가 있다.
이게 바로 기본 언어 표시를 위해서 사용하는 것인데, 한국 홈페이지에서는 ko로 설정하는 것이 중요하다.
그 이유는 스크린 리더가 홈페이지를 읽을 때 기본 언어가 한국어라는 것을 알려주는 것이다.
<html lang="ko">
<a>
channel 이동
</a>이렇게 구성되어 있다면 스크린리더는 어떻게 읽을까?
"채널 이동"이라고 읽을 수 있다. 하지만 홈페이지가 명품 판매 홈페이지라면 이것은 문제가 될 수 있다.
이때 lang 옵션을 통해서 제대로 읽도록 설정할 수 있다.
<html lang="ko">
<a>
<span lang="fr">channel</span> 이동
</a>
공통 - 명확한 지시 사항 제공
지시 사항은 모양, 크기, 위치, 방향, 색, 소리 등에 관계없이 인식될 수 있어야 한다.
특정 감각에만 의존하는 방법으로 제공해서는 안된다.
| 구분 | 잘못된 지시 사항 문구 |
| 모양 | 동그란 버튼을 누르세요 => 동그란 버튼이 무엇인지 모름 |
| 크기 | 큰 버튼을 누르세요 => 큰 버튼이 무엇인지 모름 |
| 위치 | 왼쪽에 있는 버튼을 누르세요 => 왼쪽이 어딘지 모름 |
| 방향 | 현재로부터 아래에 있는 버튼을 누르세요 => 현재 내가 어디있고 내 아래 어디에 버튼이 있는지 모름 |
| 색 | 파란색 버튼을 누르세요 => 파란색을 확인할 수 없음 |
| 소리 | ( 동작이 맞거나 틀렸을 때 특정 소리가 나오는 경우 ) => 무슨 소리인지 모름 |
'Web' 카테고리의 다른 글
| 웹 접근성 시나리오 - 2 (0) | 2024.03.20 |
|---|---|
| 웹 접근성 기술 학습 (0) | 2024.03.16 |
| 웹 접근성 시나리오 (1) | 2024.02.21 |
| 웹 표준, 웹 호환성, 웹 접근성 (0) | 2024.02.17 |
| 크롬 내장 스크린리더 사용기 (1) | 2024.02.11 |