📌 웹 표준이란?
어떤 운영체제나 브라우저에서든 동일한 컨텐츠 를 볼 수 있도록 웹페이지를 만들 때 지켜야 하는 규칙.
📌 왜 웹 표준이 필요할까?
1990년 ~ 2000년대 초반까지 넷스케이프, 인터넷 익스프로러등 다양한 브라우저들이 나타나기 시작. 그로 인해 과도한 경쟁이 발생
=> 해당 브라우저에서만 사용 가능한 기능들이 나타나기 시작
=> 여러 버전의 페이지를 만들어야 함.
이를 해결하기 위해 W3C라는 공식 웹 표준 기구가 설립되었고
이를 통해 각 브라우저에서도 동일한 컨텐츠를 볼 수 있는 환경이 조성됨
📌 웹 표준을 지킬 때의 장점
- 운영관리 용이
- 소스코드의 통일화로 개발자의 부담이 줄어들고 유지보수가 쉬워짐.
- 검색 엔진 최적화 (SEO) 올바르게 구조화된 웹 페이지는 검색 로봇이 문서 분석을 하기 쉽게 도와줌.
- 웹 접근성 향상
📌 그렇다면 웹 접근성이란 무엇일까?
누구나 신체적, 환경적 조건에 관계없이 인터넷을 통해 정보에 접근하고 이용할 수 있는지에 대한 정도
📌 왜 웹 접근성을 준수해야 할까?
한국형 웹 콘텐츠 접근성 지침 2.2 의 웹 문서 설계 시 고려해야 할 이용자 유형
- 시각을 통해 정보를 인지할 수 없는 시각장애가 있는 경우
- 청각을 통해 음향 정보를 인지하지 못하는 청각장애가 있는 경우
- 시각, 청각 또는 손을 사용하고 있어 필요로 하는 일을 할 수 없는 경우
- 운전 중이거나 소음이 많은 곳에서 일하는 경우 등 웹 사용자가 처한 환경에 따라 제한 받는 경우
또한, 실제 법률에서도 이를 명시하고 있음.
그렇다면, 어떻게 하면 웹 접근성을 높힐 수 있을까?
-
Accessible Name : 스크린 리더가 요소를 포커스 했을 때 읽어주는 내용
- Author : 작성자가 명시적으로 작성한 값 ( aria-label, alt, title 등 )
- Contents : 요소의 텍스트 값
우선 순위 : Author > Contents
<div aria-label='가지마'>잘 가</div>;위의 HTML요소를 스크린리더는 과연 뭐라고 읽을까?
Author : 가지마 > Contents : 잘 가
📌 적은 노력으로 스크린리더 UX 개선하기
1. 의미를 알 수 없는 Button
<div onClick={() => navigate('/register')}>
<span>+</span>
</div>위와 같은 요소를 비장애인이 보았을때는 무언가를 추가하는 요소라는것을 알수 있다. 하지만, 스크린리더로 들었을때 '더하기' 라는 음성만 나오므로 장애인이 들었을 경우 무엇인지 알아 차리기 쉽지 않다. 따라서 다음과 같이 변경하자
<button aria-label='카드 추가' onClick={() => navigate('/register')}>
<span aria-hidden='true'>+</span>
</button>aria-label 이란 ? HTML 요소에 간단한 설명을 제공하는 속성
aria-hidden 이란 ? 사용자에게 불필요한 정보를 스크린 리더가 읽지 않게 하는 속성
aria-live 이란 ? 웹 페이지에서 실시간으로 변화하는 컨텐츠를 사용자에게 즉시 전달하기 위해 사용하는 속성 (off, polite, assertive)
이렇게 변경을 해주면 스크린리더는 카드추가 버튼 이라고 읽게 됨.
또한 위의 예제에서는 aria-label이 있기 때문에 더하기라고 읽지 않지만 만약 없을 경우를 대비해 aria-hidden='true' 속성을 주도록 하자.
2. 대체 텍스트가 없는 Image
스크린 리더가 alt 속성이 없는 이미지를 포커스 했을 때 해당 이미지의 파일명을 읽게 됨.
=> 사용자는 해당 이미지의 어떤 정보가 있는지 해석할 수 없음.
<img src="이미지 경로" alt="이미지에 대한 설명" />위와 같이 img 태그에는 alt 속성을 추가시켜주도록 하자.
📌 아무리 스크린리더가 읽을 필요가 없는 이미지여도 alt 속성을 넣어주어야 스크린리더가 파일명을 읽지 않음.
한국형 웹 컨텐츠 접근성 지침에 따르면 텍스트가 아닌 컨텐츠는 그 의미나 용도를 인식할 수 있도록 대체 텍스트를 제공해야된다고 나와있음.
그렇다면 대체 텍스트는 어떻게 작성해야할까?
웰컴 키트가 있다고 가정을 할 때
'쉽고 명확하고 위트있게' 라는 문구가 적혀있는 흰색 뚜껑의 플라스틱 물컵, 노크식 검정색 볼펜 등등
사용자에게 유의미한 정보를 주어야 함. 그래서 사용자가 어떻게 해석을 할 수 있는지 고민을 해보고 대체 텍스트를 제공해야 함.
3. 다가갈 수 없는 Bottom Sheet
사용자가 무언가를 추가하는 버튼을 눌러서 모달이 열렸다고 가정했을 때 포커스가 모달 안으로 이동하지 않아서
스크린 리더는 밖에 있는 요소를 읽게 되는 경우가 있음.
=> 사용자는 모달이 열렸음에도 그 사실조차 알 수가 없음.
<-- 추가 모달 -->
<div class="modal">
{children}
</div> 위와 같이 div태그를
<-- 추가 모달 -->
<dialog class="modal">
{children}
</dialog> dialog 태그로 바꿔주도록 하자.
<dialog> 가 제공하는 접근성 기능
- 포커스 관리 : 모달이 열리면 포커스 자동 이동
- 접근성 트랩 : 포커스를 모달 안에 가두기. 포커스가 모달 밖으로 이동하지 않게 함으로 접근성을 높혀줌
- 모바일 네이티브 이벤트 구현 : 두 손가락 문지르기를 통한 모달 닫기
<dialog> 사용 시 알아두어야 할 것
- dialog 태그는 Show 메서드와 ShowModal 메서드로 열 수 있음.
- Show() : 비모달식 대화상자 오픈 => 외부요소와 상호작용 O
- ShowModal() : 모달식 대화상자 오픈 => 외부요소와 상호작용 X
- dialog의 웹 접근성 기능을 활용하기 위해서는 ShowModal()를 사용해서 모달을 열어야 함.
4. 눈에만 보이는 Error Message
<p>* 최소 8자리 이상, 하나 이상의 숫자 및 특수문자</p>위와 같은 에러메세지 태그를 그냥 적기만하면 스크린 리더가 에러 메세지가 나왔음에도 읽지 않음.
<p aria-live='assertive'>* 최소 8자리 이상, 하나 이상의 숫자 및 특수문자</p>따라서 즉시 알려주기 위해서 aria-live 속성을 추가해주자.
aria-live의 속성값으로는 off, polite, assertive가 있음.
off의 경우에는 기본값으로 컨텐츠가 변해도 사용자에게 알려주지 않음.
polite의 경우 컨텐츠가 변화했을 때 바로 알려주는 것이 아니라 스크린 리더의 작업이 끝난 이후 알려줌.
그리고 assertive의 경우 스크린리더의 작업을 중단하고 즉시 변화한 내용을 읽어줌.
위의 사진과 같이 에러메세지를 바로 알려주기 위해 assertive 속성을 사용함
5. 페이지 언어 표시
<html lang="en"> // 영어<html lang="ko"> // 한국어📌 결론
웹 표준과 웹 접근성 모두 결국은 모든 것이 사용자를 향해 있음.
사용자에게 어떠한 문제가 있고 어떻게 해결해야 할지 고민을 하고 조금만 더 노력을 한다면 모두를 위한 웹 페이지를 만들 수 있음!
