웹 접근성(Web Accessibility)의 이해

웹 접근성(Web Accessibility)의 이해

Web Content Accessibility Guidelines 2.1

 

 

*이 글은 무엇인가요?

본 포스팅에서는 웹 접근성에 대한 전반적이고 간단할 설명을 제공합니다.

웹 콘텐츠 접근성 지침에 대한 일부 예시를 다루고 있습니다.

 

 

*이 글은 무엇이 아닌가요?

본 포스팅은 웹 접근성 지침과 관련된 구체적인 예시들을 제공하지 않습니다. 간단한 소개 목적으로 일부 예시가 포함되나 해당 글의 목적과는 다릅니다. 접근성을 위한 구체적인 코드 예시를 원하신다면, [한국형 웹 콘텐츠 접근성 지침 2.1] 혹은 [NULI]라는 사이트를 활용하시는 것을 추천드립니다.

 

 

---

 

웹 접근성

  웹 접근성(Accessibility)이라는 용어는 어떠한 사용자(장애인, 노인 등), 어떠한 기술환경에서도 사용자가 전문적인 능력 없이 웹 사이트에서 제공하는 모든 정보에 접근할 수 있도록 보장하는 것을 의미합니다. 접근성의 주된 접근성 고려 대상으로 보조 기술을 사용해야하는 장애인이나 고령자를 중점에 두고 있는 듯하지만, 접근성의 본질은 모든 사용자의 유익을 위함임을 명확히 알고 있어야합니다.

 

 

웹 접근성 지침의 시작

  1997년 12월 18일, W3C(World Wide Web Consortium)가 첫 HTML 4.0을 공개하면서 처음으로 접근성에 관한 언급이 있었습니다. 

웹 기반 공동체의 덩치가 커지고 그 속의 구성원들도 가진 재능과 기술이 다변화되면서, 떠받치고 있는 기술도 그들의 입맛에 맞는 요구에 부응해야 하는 시점에 도달하게 되었다. 그래서 HTML은 신체적으로 장애를 갖고 있는 사람들에게도 웹 페이지들로의 접근이 더 손쉬워지도록 설계되었다. HTML 4.0의 개발은 다음과 같은 접근성을 염두에 두고 진행되었다.
- HTML 4.0 문서 중

 

1999년 5월 5일, WCAG(Web Content Accessibility Guidelines) 1.0이 W3C 권고 사항이 되었고, 그 이후 지금까지 발전되어 현재 공식 버전은 WCAG 2.1, 21년 1월 기준 WCAG 3.0 (초안)까지 공개된 상황입니다. 우리나라에서도 마찬가지로 영국, 호주, EU 등에서 사용되고 있는 W3C 의 웹 콘텐츠 접근성 지침 (WCAG : Web Contents Accessibility Guidelines) 1.0과 WCAG 2.0 초안 및 미국 재활법 508조를 기반으로 국내 웹 기반 환경에 맞게끔 재구성한 KWCAG를 만들어 공식 지침으로 사용하고 있습니다. 

 

KWCAG 2.1과 WCAG 2.1

 

 

우리가 웹 접근성을 고려해야 하는 이유

  HTML 4.0에서 언급되었듯이, 접근성 지침의 등장 배경은 웹을 사용하는 구성원들의 특징들이 다변화되면서 기술이 사용자에게 적합하도록 설계되어야 한다는 것이 주된 이유였습니다. 접근성 지침이 없는 상황은, 레이아웃을 위해 table 태그를 사용하는 등 개발자들의 잘못된 습관이 만연하게 되는 결과를 가져오게 되었고, 이는 컨텐츠 사용자 뿐만 아니라, 개발자들끼리도 불편함을 겪어야하는 문제가 되었습니다. 즉, 접근성 및 표준에 대한 준수는 사용자 뿐만 아니라 개발자에게도 필요한 부분이 된 것입니다.

  접근성 준수가 장애인이나 고령자에게 가장 혜택이 많이 돌아가는 것은 사실이지만, 리모컨, 자동문 등이 초기에는 노인이나 장애인들을 위해 개발되었다가 이후 모든 사람들이 편하게 활용하게 된 것처럼, 접근성을 준수하는 것 또한 일부를 위한 것처럼 보이지만 본질은 모두의 유익을 위한 것임을 알고 있어야한다고 생각합니다.

 

  추가로, 대한민국은 2008년 4월 11일부터 시행된 「장애인차별금지 및 권리구제 등에 관한 법률 」(이하 ‘장차법’) 제21조 및 동법 시행령 제14조에 의거하여 공공 및 민간 웹 사이트의 웹 접근성 준수가 의무화 되었습니다. 현대에서의 웹이 부정할 수 없을 정도로 보편화되었기 때문에 소외될 수 있는 장애 환경의 구성원을 위한 국가 차원의 지원으로 해석할 수 있으며, 기술적 이유든 법적 이유든 우리가 접근성을 지켜야한다는 사실은 변함이 없겠습니다. 물론, 안 지키면 소송을 당할 가능성이 있고, 실제 소송 사례가 있습니다.

 

 

 

 

여러 장애 환경에 대한 이해

1. 전맹 시각 장애
  시력 장애로 인해 앞을 볼 수 없는 상황으로, 청각이나 촉각을 통해 웹을 이용합니다. 청각적으로는 스크린리더가 웹에 존재하는 이미지, 글씨를 음성으로 읽어주며, 촉각적으로는 점자 정보 단말기를 통해 점자를 손으로 읽으면서 웹 페이지의 내용을 인식합니다.

 

2. 저시력 시각 장애
  저시력 시각 장애 종류로, 시력저하, 시야장애, 적록색맹, 전색맹 등이 있으며, 저시력 시각 장애인을 위한 접근성 기능으로는 화면 확대, 고대비, 명도 대비 4.5:1 이상의 디자인, 모양 등의 색상 외 정보 구분 기능 등이 있습니다.

 

3. 중증 운동 장애
  손 또는 팔을 사용하지 못하고 목만 움질일 수 있는 장애 환경으로, 헤드 포인터, 빅키 키보드, 키가드 등의 보조기기를 이용하여 키보드를 조작할 수 있습니다.

 

4. 손 운동 장애
  한 손만 사용 가능하며, 마우스나 키보드의 정교한 조작이 어려운 장애입니다.  한 손 사용자용 키보드, 트랙볼 마우스 등의 보조기기를 이용하여 마우스 및 키보드를 조작할 수 있습니다.

5. 청각 장애
  알림음, 영상 같은 정보를 제공받을 수 없는 환경으로, 안내 문구나 자막 같은 화면의 글씨를 읽습니다.

 

6. OS 환경 차이
  window에서만 발생하는 알림도 mac 사용자는 불가능하므로 접근성에 문제가 있습니다.

7. 느린 인터넷 환경
  느린 인터넷으로 화면의 정보가 완전한 모습으로 출력되지 않는 경우도 접근성 문제입니다.

 

 

 

 

KCAG 2.1 지침 요약

   한국형 웹 컨텐츠 지침 2.1의 내용은 다음과 같이 요약할 수 있습니다.

 

<원칙 1> 인식의 용이성 (Perceivable) : 모든 콘텐츠는 사용자가 인식할 수 있어야 한다.

• 1.1.1 (적절한 대체 텍스트 제공) 텍스트 아닌 콘텐츠는 그 의미나 용도를 이해할 수 있도록 대체 텍스트를 제공해야 한다.
• 1.2.1 (자막 제공) 멀티미디어 콘텐츠에는 자막, 원고 또는 수화를 제공해야 한다.
• 1.3.1 (색에 무관한 콘텐츠 인식) 콘텐츠는 색에 관계없이 인식될 수 있어야 한다.
• 1.3.2 (명확한 지시사항 제공) 지시사항은 모양, 크기, 위치, 방향, 색, 소리 등에 관계없이 인식될 수 있어야 한다.
• 1.3.3 (텍스트 콘텐츠의 명도 대비) 텍스트 콘텐츠와 배경 간의 명도 대비는 4.5대 1 이상이어야 한다.
• 1.3.4 (자동 재생 금지) 자동으로 소리가 재생되지 않아야 한다.
• 1.3.5 (콘텐츠 간의 구분) 이웃한 콘텐츠는 구별될 수 있어야 한다.

 

<원칙 2> 운용의 용이성(Operable) : 사용자 인터페이스 구성요소는 조작 가능하고 내비게이션 할 수 있어야 한다.

• 2.1.1 (키보드 사용 보장) 모든 기능은 키보드만으로도 사용할 수 있어야 한다. (PC웹)
• 2.1.1 (누르기 동작 지원) 터치(touch) 기반 모바일 기기의 모든 컨트롤은 누르기 동작으로 제어할 수 있어야 한다. (모바일웹)
• 2.1.2 (초점 이동) 키보드에 의한 초점은 논리적으로 이동해야 하며 시각적으로 구별할 수 있어야 한다.
• 2.1.3 (조작 가능) 사용자 입력 및 컨트롤은 조작 가능하도록 제공되어야 한다.
• 2.2.1 (응답시간 조절) 시간제한이 있는 콘텐츠는 응답시간을 조절할 수 있어야 한다.
• 2.2.2 (정지 기능 제공) 자동으로 변경되는 콘텐츠는 움직임을 제어할 수 있어야 한다.
• 2.3.1 (깜빡임과 번쩍임 사용 제한) 초당 3~50회 주기로 깜빡이거나 번쩍이는 콘텐츠를 제공하지 않아야 한다.
• 2.4.1 (반복 영역 건너뛰기) 콘텐츠의 반복되는 영역은 건너뛸 수 있어야 한다.
• 2.4.2 (제목 제공) 페이지, 프레임, 콘텐츠 블록에는 적절한 제목을 제공해야 한다.
• 2.4.3 (적절한 링크 텍스트) 링크 텍스트는 용도나 목적을 이해할 수 있도록 제공해야 한다.

 

<원칙 3> 이해의 용이성(Understandable) : 콘텐츠는 이해할 수 있어야 한다.

• 3.1.1 (기본 언어 표시) 주로 사용하는 언어를 명시해야 한다.
• 3.2.1 (사용자 요구에 따른 실행) 사용자가 의도하지 않은 기능 (새 창, 초점 변화 등)은 실행되지 않아야 한다.
• 3.3.1 (콘텐츠의 선형화) 콘텐츠는 논리적인 순서로 제공해야 한다.
• 3.3.2 (표의 구성) 표는 이해하기 쉽게 구성해야 한다.
• 3.4.1 (레이블 제공) 사용자 입력에는 대응하는 레이블을 제공해야 한다.
• 3.4.2 (오류 정정) 입력 오류를 정정할 수 있는 방법을 제공해야 한다.

 

<원칙 4> 견고성(Robust) : 웹 콘텐츠는 미래의 기술로도 접근할 수 있도록 견고하게 만들어야 한다.

• 4.1.1 (마크업 오류 방지) 마크업 언어의 요소는 열고 닫음, 중첩 관계 및 속성 선언에 오류가 없어야 한다.
• 4.2.1 (웹 애플리케이션 접근성 준수) 콘텐츠에 포함된 웹 애플리케이션은 접근성이 있어야 한다.

 

 

 

웹 접근성 지침 예제

대체 텍스트를 제공하지 않음

   - 1.1.1 (적절한 대체 텍스트 제공) 텍스트가 아닌 콘텐츠는 그 의미나 용도를 인식할 수 있도록 대체 텍스트를 제공해야 한다.

<img src="banner.png" />

 

접근성을 고려하여 해당 코드 수정한 예시

  - 방법 1) alt 속성으로 대체 텍스트 제공

<img src="banner.png" alt="주식수수료 평생무료 비대면계좌개설 신규/온라인/유관기관 제비용 제외  2018년 12월 31일까지 선물/옵션 1년 무료, 신용이자 연 3.5% 60일 우대" />

  - 방법 2) 마크업으로 대체 텍스트 제공

<img src="160314.png" alt="">
<p class="blind">
    주식수수료 평생무료 비대면계좌개설 신규/온라인/유관기관 제비용 제외  
    2018년 12월 31일까지 선물/옵션 1년 무료, 신용이자 연 3.5% 60일 우대
</p> 
<!-- 이 때, 이미지 설명을 위한 p 태그는 화면에서 숨겨야하며,
display:none 이나  visibility:hidden을 사용하면 스크린 리더가 읽지 못하므로
다른 방법으로 숨겨야한다. -->

<!--숨김 예시
<style>
.blind{
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  overflow: hidden;
  clip-path: polygon(0 0, 0 0, 0 0);
}
</style>
-->

그 외 복잡한 콘텐츠의 대체 텍스트, 이모티콘, 배경 이미지, QR 코드 이미지 등 다양한 상황에 대한 대체 텍스트 제공 방법이 있습니다.

 

구체적인 웹 접근성 지침 사례

  웹 접근성과 관련된 구체적인 적용 사례를 알고 싶으시면, [NULI]라는 웹 사이트를 참고하시는 것을 추천드립니다.

널리 사람을 이롭게 하는 기술, 널리 NULI

[널리 바로가기]

NULI

 

 

Lighthouse를 활용한 웹 접근성 평가

  Lighthouse는 구글에서 개발한 웹 앱의 품질을 개선하는 오픈 소스 자동화 도구입니다. 이전에는 크롬 확장프로그램을 설치하여 사용할 수 있었지만, 최신 크롬 브라우저에서는 개발자 도구를 통해 기본적으로 제공하고 있습니다. 다만, Lighthouse는 HTTP/HTTPS 페이지 및 크롬 확장 프로그램만 감사할 수 있다는 아쉬움이 있습니다. 배포되지 않은 개발 환경에서는 측정이 불가능한 것이죠.

NAVER 첫 페이지 Lighthouse 분석 결과

  Lighthouse는 성능(Performance), 접근성(Accessibility), 권장사항(Best Practices), 검색엔진 최적화(SEO), Progressive Web App 의 5가지 카테고리를 제공하며, 원하는 카테고리만 선택적으로 적용할 수 있습니다. 위의 NAVER 홈페이지 예시에서는 평가 점수와 더불어 접근성 분야에서 1) 배경색에 대한 명도 대비가 충분하지 않음 2) <iframe> 요소의 title이 제공되지 않음 3) Link 요소가 이미지로 사용될 때 읽기 어려운 이름을 포함하고 있음 등 해당 페이지의 접근성 관련 문제를 상세하게 알려주고 있습니다.

 

  클라이언트단에서 평가할 수 있는 여러 지표를 상당히 친절한 방법으로 제공해주고 있기 때문에 프론트엔드 개발자에게 큰 도움이 되며 추천할만한 도구라고 생각합니다.

  

 

 

앞으로의 웹 접근성

  WCAG는 웹 접근성에 대한 지침을 제공하고 있지만, 해당 지침들을 잘 따르는 것이 실제 사용자의 접근성 문제를 모두 해결했다는 의미는 아닐 것입니다. 웹을 사용하는 Android, IOS, Tablet, PC, 폴더블 디바이스나 웨어러블 등 다양한 디바이스 환경이 등장해왔고,  앞으로도 우리가 상상하지 못했던 새로운 형태의 환경에서 웹을 사용하게 될 수 있습니다. 혹은 접근성을 향상시킬 수 있는 더 좋은 기술과 방법들이 나타날 가능성도 있죠.

 

  개인적으로 저는 음성 인터페이스인 VUI(Voice User Interface) Design이 웹 개발에 큰 영향을 줄 것으로 기대하고 있습니다. 시리(Siri), 빅스비(Bixby), Google Assistant 등의 음성 인식 기술이 계속해서 발전하는 중이고, 점차 많은 사람들이 기술에 익숙해지고 있기 때문입니다. 아직은 비장애인들이 음성 인식을 통해 웹에 접근하려는 시도가 많지는 않지만, 조금씩 기술이 발전하고 기술을 적용하는 영역이 넓어진다면, 훗날에는 일반적이라고 칭할 만큼 당연한 접근 방법이 될 수 있다고 생각합니다. 

 

 

 

마무리

웹 접근성 지침을 준수하는 것은 +α가 아니라, 필수라고 생각하자

 

  웹 접근성 지침을 따르는 것을 넘어, 변화하고 발전하는 환경 속에서 모든 사용자에게 어떻게 더 나은 접근성을 제공할 것인지 고민하고 시도하는 것이 접근성 지침의 본질이라고 생각합니다. 웹 접근성을 블로깅 주제로 선택하고 관련 내용들을 공부하는 과정에서 과거의 작업물들에 대한 반성과 부끄러움이 물밀듯 밀려왔지만, 보다 좋은 개발을 할 수 있는 기반이 될 것이라 믿고, 기술적 학습과 더불어 접근성에 대해 꾸준한 관심을 갖는 것이 필요하다는 생각을 하게 되었습니다. 

 

 

---

참고 자료

[널리 바로가기]

NULI

[웹 접근성 과거]

웹 접근성으로의 여행

[WCAG 3.0]

WCAG 3.0 첫번째 초안 문서를 기준으로 살펴보는 WCAG 변경된 사항

[WCAG 공식 문서]

 

Web Content Accessibility Guidelines (WCAG) 2.1

[KWCAG 2.1 바로가기]