[용어] 웹 접근성 - A11y

---

목차

1. 정의

2. 접근성 안내서

3. 접근성을 프로젝트에 포함시키는 방법

---

 

1. 정의 : Accessibility

MDN Web Docs 에서는 웹 개발에 있어서 접근성을 정말 주된 우선순위로 고려하길 권고한다.

웹 접근성에 대해 MDN Web Docs 를 기준으로 정의부터 살펴본다.

 

웹 개발에서 (종종 A11y 로 축약된 - "a", 11자, "y"로 표시됨) 접근성은 사람들의 능력이 어떤 식으로든 제한되어 있더라도, 가능한 많은 사람이 웹 사이트를 사용할 수 있도록 하는 것을 의미한다. - MDN Web Docs

 

https://developer.mozilla.org/en-US/docs/Web/Accessibility

Accessibility | MDN

 

2. 접근성 안내서 : 모두를 위한 웹 만들기

MDN (Mozilla Developer Network) 웹 문서는 웹 표준과 모질라 프로젝트에 대한 개발 문서들이 담긴 모질라의 공식 웹사이트이다.

사실상 웹 표준 문서를 관리하는 MDN Web Docs 에서는 웹 개발자를 위한 접근성 안내서를 제공하고 있다.

 

[ 웹 접근성 안내서 목차 ]

▷ 접근성 : Overview

▷ 접근성이란 무엇인가

▷ HTML: 접근성을 위한 좋은 기반

▷ CSS, JavaScript 접근성 모범 사례

▷ WAI-ARIA 기초

▷ 접근 가능한 멀티미디어

▷ 모바일 접근성

▷ 평가: 접근성 트러블슈팅

 

https://developer.mozilla.org/ko/docs/Learn/Accessibility

접근성 - Web 개발 학습하기 | MDN

3. 접근성이란 무엇인가?

웹 접근성이 왜 중요한지, 웹 개발에서 고려해야할 사용자 그룹은 어떻게 되는지, 개발 워크 플로우에 어떻게 적용할 수 있는지 구체적으로 살펴보자.

3-1. 접근성이 중요한 이유

웹 개발자는 배운 지식을 효과적으로 사용하기 위해서 HTML, CSS, JavaScript 지식 이상의 기술이 필요하다.

그 기술 중 하나인 접근성은 가능한 많은 사용자가 차별없이 웹 사이트를 사용할 수 있도록 한다.

또한 좋은 접근성은 아래와 같이 추가적인 이점을 갖는다.

 

웹 접근성 향상의 장점

 (1) 간결한 시맨틱 마크업은 스크린 리더에게 좋을 뿐만 아니라 빠르게 로드되어 성능이 좋다.

 (2) 웹 사이트의 접근성 향상은 장애인 뿐만 아니라 모바일이나 느린 네트워크 속도의 사용자 등을 포함해

      다양한 사용자가 사용하기 쉽게 만든다.

 (3) 프로젝트 초기부터 접근성을 고려하고 개발하면 접근성 이슈로 인한 추가 비용을 줄 일 수 있다.

 (4) 좋은 윤리와 도덕 관념으로 서비스의 대중적인 이미지 개선

 (5) 일부 지역에서의 접근성 지침 및 법률 준수 (대한민국은 약칭 장인차별금지법이 존재)

 

웹 접근성은 많은 사람들에게 일을 더 쉽게 만들어주고, 장애를 가진 사람에게 일을 가능하게 만들어준다.

접근성은 개인의 신체적, 인지적 능력 및 웹에 접근하는 방법과 관계없이 가능한 많이 접근할 수 있도록 콘텐츠를 개발하는 것을 의미한다.

 

웹 접근성을 고려하는 일은 일반적으로 공공기관에 있는 휠체어 경사로나 엘리베이터가 설치된 이유와 같다.

모든 사람을 동일하게 대하고, 그들의 능력이나 상황에 상관없이 그들에게 같은 기회를 주는 것이다.

시각 장애가 있다는 이유로 누군가를 웹 사이트에서 제외시키는 것은 옳지 않다.

우리는 모두 다르지만 인간으로서 동일한 권리를 가진다는 것을 유념하자.

 

3-1.  고려해야 할 사용자 그룹

당신이 아닌 다른 사람들이 컴퓨터 그리고 웹 사이트를 어떻게 사용하는지 생각해보자.

다양한 장애가 있지만 대표적인 4가지 유형으로 나누어 살펴본다.

 

웹 콘텐츠에 접근하기 위해 사용하는 특별한 도구를 보조 기술(Assistive Technologies 또는 ATs) 라고 부른다.

 

(1) 시각 장애인

전맹, 저시력, 색각, 색맹, 생약 장애를 가진 사람들이 포함된다.

이들은 실제 물리적인 돋보기나 소프트웨어의 확대 기능을 통해 화면을 확대해서 이용한다.

또는 디지털 텍스트를 소리내어 읽어주는 소프트웨어인 스크린 리더(Screen Reader)를 사용한다.

 

스크린 리더 (screen reader) 종류

- 상업 소프트웨어 : JAWS (Windows), Dolphin Screen Reader (Windows)

- 무료 소프트웨어 : ChromeVox (Chrome), NVDA (Windows), Orca (Linux)

- OS 자체 소프트웨어 : VoiceOver (macOS, iPadOS, iOS), Narrator (Windows), ChromeVox (Chrome OS), TalkBack (Android)

 

통계적으로 세계보건기구(WHO)는 "전 세계적으로 최소 22억 명의 사람들이 근거리 또는 원거리 시각 장애를 가지고 있다." 라고 추정한다. 전세계 인구 78.88억 (2021년) 의 약 27.8% 에 해당한다. 참고로 우리나라 인구는 5,174만명이다. 제대로 코딩되지 않은 웹 사이트의 경우 이 사용자들을 놓칠 수 있다.

 

(2) 청각 장애인

청각 장애 및 난청 (Deaf and hard-of-hearing, DHH) 장애를 가진 사람들이 포함된다.

 

이들도 보조 기술(AT, 청각, 음성, 언어 장애가 있는 사람들을 위한 보조 장치)를 사용하지만 보편적이지 않다.

그렇게 때문에 접근성을 위해서는 대체 텍스트가 제공되야 한다. 영상에는 수동으로 자막을 달고, 오디오 콘텐츠에 대해서도 대본을 제공해야 한다. (대안으로 Chrome live caption 확장 기능이 있다.)

DHH 인구의 높은 언어 박탈(Language Deprivation)을 고려해 텍스트 단순화가 필요할 수 있다.

 

청각 장애 및 난청 인구도 상당한 비중을 차지하는 사용자이다. 세계보건기구(WHO)에 따르면 전 세계 4억명 (세계 인구의 5% ) 이상의 사람들이 난청을 겪고 있다고 추청한다.

 

(3) 운동 장애인

운동 장애(Mobility Impariments) 는 사지의 상실이나 마비 등 물리적인 원인 또는 신경학적/유전학적인 장애에 기인하는 팔 다리 통제력의 약화/상실로 인해 움직임에 제약이 생기는 것이다.

이런 사람들은 마우스 사용이 어려우며, 심각한 경우 헤드 포인터를 사용해야 한다.

 

운동 장애를 고려한 웹 개발의 보편적인 요구사항은 키보드를 통해 접근할 수 있도록 해야 한다.

웹 사이트를 키보드만으로 사용하는 경우 Tab 키를 사용해 컨트롤 요소들에 접근한다.

키보드 컨트롤에 관련된 자세한 내용은 MDN Web Docs 의 Cross browser testing Using native keyboard accessibility 섹션에서 다룬다.

 

(4) 인지 장애인

인지 장애의 정의는 광범위하다. 나이가 들며 생각하고 기억하는데 어려움을 느끼는 우리 모두를 가리키기도 하며 지적 장애, 정신 질환인 우울증과 정신분열증, 학습 장애인 난독증과 ADHD 도 포함한다.

이들 모두가 공통적으로 겪는 문제로는 콘텐츠를 제대로 이해하거나 작업을 완료하는 방법을 기억하는 과정에서 발생하는 어려움과 일관성 없는 웹 페이지 레이아웃으로 발생하는 혼란이 있다.

 

인지 장애를 고려한 접근성의 좋은 기반

- 콘텐츠를 하나 이상의 방식으로 제공한다. (TTS, 비디오 등)

- 표준 문법을 지켜 작성된 텍스트처럼 쉽게 이해할 수 있는 콘텐츠 제공

- 중요한 콘텐츠에는 주의가 집중될 수 있도록 한다.

- 불필요한 내용이나 광고처럼 산만한 요소를 최소화한다.

- 일관된 웹 페이지 레이아웃과 네비게이션을 사용한다.

- 방문하지 않은 경우 파란색, 방문한 경우 보라색 밑줄이 그어지는 링크처럼 친숙한 요소를 사용한다.

- 보안과 타협하지 않는 선에서 웹 사이트 인증은 가능한 쉽게 구현한다.

- 양식은 완성하기 쉽게 만든다. 에러는 명확한 메시지를 보여주고 간단하게 복구되어야 한다.

 

미국 질병통제센터는 2018년 기준으로 미국 시민 4명 중 1명이 장애를 가지고 있으며, 그 중에서 인지 장애는 젊은 사람들에게서 가장 흔하다고 추정한다.

 

인지적 접근성을 고려한 디자인은 좋은 디자인이며 모든 사람들에게 이점을 제공한다.

웹 사이트가 준수해야 할 인지적 접근성 관련 가이드라인을 MDN Web Docs과 W3C 가 제공하고 있다.

 

인지적 접근성 관련 가이드라인

- MDN Web Docs의 인지적 접근성 가이드라인

- W3C의 Web Content Accessibility Guidelines (WCAG)

3-2. 접근성을 프로젝트에 포함시키는 방법

프로젝트가 한참 진행된 뒤, 접근성을 고려하며 관련된 이슈를 발견한 경우 접근성은 비싼 추가 사항이 된다.

접근성 문제도 다른 버그들과도 마찬가지로 늦게 발견될수록 더 많은 비용이 발생한다.

그렇기 때문에 프로젝트 초기부터 접근성을 고려하고 빠르게 자주 테스트한다.

 

접근성을 프로젝트에 포함시키는 방법

- 프로젝트 계획시 Target Audience Segments (대상 브라우저나 OS)를 위한 테스팅과 함께 접근성 테스팅을 고려

- 빠르게 자주 테스트 한다. (일반적인 테스트 항목)

- 이상적인 방식은 자동화된 테스트를 통해 누락되어 있는 접근성 관련 기능을 잡아낸다.

- 장애가 있는 유저 그룹을 대상으로 일부 테스팅을 진행

- 접근성을 위한 작업이 필요한 잠재적 문제 영역에 대해 기록하고, 철저하게 테스팅 될 수 있도록 하며 해결 방안과 대안을 생각한다.

- 할 수 있는 만큼 노력해야 하지만 100% 접근성은 실현 불가능한 이상이다.

- 웹 사이트에 접근성 성명을 게시하고 문제를 겪는 사람들과 소통한다.

 

웹 개발에서 신경써야 하는 접근성 가이드라인은 압도적으로 많아 보인다.

MDN Web Docs 는 본인이 신경써야 하는 가장 기본적인 영역에 익숙해지는 것을 강조한다.

W3C 에서 발행한 WCAG의 모든 기준을 배울 필요도 없다.

주요 관심 분야에 대해 인지하고, WCAG 기준을 충족시키지 못하는 영역을 하이라이트 해주는 다양한 기술과 도구를 사용하면 된다.

 

웹 접근성 평가 도구

- 크롬 개발자 도구 : Lighthouse

- VSCode Extension : Web Accessibility, Webhint

- 무료 웹기반 웹 접근성 평가 도구 : Accessibility Checker, AChecker, FAE, Magentaa11y, TAW, WAVE

 

접근성 API

웹 브라우저는 보조 기술(AT)에 유용한 정보를 드러내는 운영체제의 접근성 API 를 활용한다.

보조 기술은 대부분 시멘틱 관련 정보를 사용하므로 여기에는 CSS, JavaScript 는 포함되지 않는다.

이 정보들은 접근성 트리라고 불리는 트리로 구조화된다.

- Windows : MSAA/IAceessible, UIAExpress, IAceessible2

- MacOS : NSAccessibility

- Linux : AT-SPI

- 안드로이드 : Accessibility framework

- iOS : UIAccessibility

 

웹/앱의 HTML 요소들이 제공하는 Native 시멘틱 정보가 부족한 경우 접근성 트리에 시맨틱 정보를 추가해 접근성을 개선하는 WAI-ARIA 명세서의 기능들로 보완이 가능하다. 관련 내용은 MDN Web Docs WAI-ARIA 기초 섹션에서 다루고 있다.

 

 

+ 국문으로 된 접근성관련 문서

  ○ 웹 접근성 연구소 - 정보접근성 향상을 위한 W3C 국제표준 WAI-ARIA 사례집

  ○ Web Soul Lab - 한국형 웹 접근성 지침 2.1