모두를 위한 접근성

접근성은 왜 중요하고, 어떻게 개선해야할까?

모든 사람들이 손쉽게 정보를 공유할 수 있는 공간

기술의 발전은 사람들이 쉽게 콘텐츠에 접근할 수 있게 하였지만, 한편으로 사람들이 어렵게 콘텐츠에 접근할 수 있게 하였다. 우리가 사는 세상에는 다양한 사람이 존재한다. 언어, 신체, 문화, 가치관 등이 모두 다른 많은 사람들이 이 세상을 살아가고 있으며, 우리 모두가 그 사실을 인지하고 있다.

여러분들이 생각하고 있는 접근성이 무엇일 지 궁금하다. 아마 대부분은 아래 이미지를 제일 먼저 떠올릴 거라 생각한다.

접근성은 장애인을 위한 것이다?

접근성이 장애인을 위한 것이라는 건 반은 맞고 반은 틀리다. 접근성은 ‘누구나 콘텐츠를 이용할 수 있어야한다'에 가깝기 때문에 접근성 지침을 준수하고 개선해나가는 작업을 다르게 풀이하자면 더 나은 사용성을 준다는 것에 가깝다.

그럼 여기에서 접근성을 준수하지 못한 사례를 하나 살펴보자.

최근 인건비 절감을 위해 키오스크 (Kiosk)를 도입하고 있는 매장이 많아지고 있다. 키오스크는 과거에도 있었지만 최근에 가장 많이 활성화되고 있고, 그리고 키오스크를 통해 더 나쁜 사용자 경험을 제공하고 있다.

시간대별로 보자.

2:13 — 대략 신장이 160cm 이상의 사람을 대상으로 설계되어있어 메뉴를 선택하고 싶어도 손이 닿지 않는 이슈가 발생한다. 만약 휠체어를 탄 사람이 메뉴를 선택하고 싶다면 어떻게 해야할까? (자세히 보면 휠체어를 탄 사람을 위한 별도의 버튼이 존재하고, 우측 하단에 작게 보인다. 저 아이콘이 장애인 아이콘인 지 휠체어 아이콘인 지 잘 모르겠다.)

2:33 — 유저가 선택하기에 충분한 시간을 제공하고 있지 않아 유저가 선택 중인 상태에서도 화면이 전환된다.

3:35 — 폰트 크기가 작아서 유저가 충분히 인지하지 못한 상태로 메뉴를 고르게 되었다. 선택하기에 충분한 시간을 제공하고 있지 않기 때문에 메뉴를 고르는 데 더 많은 시간을 사용할 수 없었을 거라 생각한다. 5:00에서 폰트 크기 문제가 다시 언급된다.

접근성을 제대로 고려하지 못한 서비스가 어떤 문제를 일으키는 지에 대해서 보여주는 대표적인 사례라고 생각한다. 위에서도 이야기했던 대로 접근성을 개선하는 작업은 장애인이 콘텐츠에 접근할 수 있게 하는거야! 가 아니라 더 나은 서비스를 만들어나가는 과정에서 당연히 고려해야하는 것에 가깝다고 생각한다.

어떻게 개선할 수 있나요?

내가 웹 개발자이기 때문에 아래 내용은 웹 관련 내용이 상대적으로 디테일하게 작성되어있다. 하지만 ‘콘텐츠 접근성 지침' 이기 때문에 앱 개발자도 충분히 고려해야할 사항이라고 생각한다.

웹에는 국제 표준인 웹 콘텐츠 접근성 지침 (WCAG, Web Contents Accessibility Guidelines)가 있다. 한국 표준인 한국형 웹 콘텐츠 접근성 지침 (KWCAG, Korean Web Contents Accessibility Guidelines)도 있으니 양쪽을 비교해가면서 살펴보는 것도 좋다.

크게 네가지 분류를 두고있다.

  1. Perceivable (인식의 용이성)
  2. Operable (운용의 용이성)
  3. Understandable (이해의 용이성)
  4. Robust (견고성)

모든 내용을 설명할 수 없으니, 이해의 용이성 항목 중 하나인 가독성에 대해서 살펴보자. 가독성을 개선하는 데에는 총 6개의 항목이 있다.

  1. 페이지의 언어를 표기하세요. (Level A)
  2. 부분별 언어를 표기하세요. (Level AA)
  3. 숙어나 전문용어를 사용할 때 주의하세요. (Level AAA)
  4. 약어를 사용할 때 주의하세요. (Level AAA)
  5. 콘텐츠를 쉽고 읽기 쉽게 작성하세요. (Level AAA)
  6. 발음을 같이 작성해주세요. (Level AAA)

제일 먼저 눈에 들어오는 건 A, AA, AAA 일 것이다. 접근성의 정도를 의미하며 A가 가장 기본적으로 해야하는 것, AAA가 하면 더 나은 접근성을 제공하는 것이다. 접근성 개선 작업을 할 때는 A를 우선 모두 준수하고, AA, AAA 순서대로 올라가면서 차근차근히 접근성 개선 작업을 진행하는 것이 좋다.

본문의 내용만 봐서는 ‘그래서 이게 뭘 하라는 거지?’ 라고 생각할 수 있다. 각 항목 별 우측에 Understanding과 How to 가이드가 있다. 각 가이드에서 해당 항목에 대해 더 자세히 설명한다.

예를 들어 Level A인 페이지의 언어를 표기하세요를 살펴보자.

Understanding Language of Page

How to Meet Language of Page

Understanding에서는 이 항목이 어떤 부분에 초점을 맞추고 있고, 이 항목을 준수했을 때 얻을 수 있는 장점 등에 대해서 다룬다.

The intent of this Success Criterion is to ensure that content developers provide information in the Web page that user agents need to present text and other linguistic content correctly

이 성공 기준의 목적은 콘텐츠 개발자가 웹 페이지에서 사용자 에이전트가 텍스트 및 기타 언어 콘텐츠를 올바르게 표시하는 데 필요한 정보를 제공하도록하는 것입니다 (by Google Translate)

페이지의 언어를 표기하여 유저 에이전트가 콘텐츠를 올바르게 표현하는 데 필요한 정보를 제공한다고 한다. 페이지의 언어를 표기함으로써 얻을 수 있는 장점은 아래와 같다. (마찬가지로 구글 번역기)

  • 텍스트를 합성 음성으로 변환하는 화면 판독기 또는 기타 기술을 사용하는 사람들.
  • 문자 및 알파벳 인식 또는 단어 해독과 같이 유창하고 정확하게 서면 자료를 읽기가 어려워하는 사람들
  • 텍스트 음성 변환 소프트웨어를 사용하는 인지 기능, 언어 학습 장애가있는 사람들
  • 동기화 된 미디어에 대한 캡션에 의존하는 사람들.

언어를 표기했을 때 시각적으로 달라지는 건 없을까? 놀랍게도 있다.

각각 en, ko, ja (CSS는 안건드렸다)

유저 에이전트가 가지고 있는 기본 스타일 중 폰트와 관련된 것은 언어 표기에 따라서도 달라진다. 예를 들어 현재 내가 사용하고 있는 맥 기준으로, enSF Display를 기본으로 한국어 폰트로 APPLE SD Gothic Neo를 쓰고, ko는 한국어든 영어든 상관없이 APPLE SD Gothic NEO를 사용하고, ja는 일본어와 영어는 Hiragino Kaku Gothic ProN, 한국어는 APPLE SD Gothic NEO를 사용한다. (Apple에서 권장하는 중국어, 한국어, 일본어 포맷 표기 폰트 를 참고하자)

따라서 서비스에서 주로 사용되는 언어에 따른 올바른 언어 표기가 시각적으로 더 나은결과물을 제공할 수 있다. 물론 CSS로도 폰트는 제어 가능하다.

플랫폼별 접근성 가이드라인을 보는 것도 도움이 된다:

보조과학기술 (AT, Assistive technology)

보조과학기술 (AT, Assistive technology)은 장애인이나 노약자처럼 신체 기능의 일부가 본래 기능을 못 하게 되는 경우에 그 기능을 구현하기 위해 적용하는 재활과학기술(rehabilitation technology)의 일종이다. (from wikipedia)

예를 들어, 이동이 불편한 사람을 위한 보조과학기술의 가장 대표적인 사례가 휠체어다. 시각적으로 어려움을 겪는 사람들을 위해서는 스크린 리더, 점자, 점자 디스플레이 등이 있다.

Mac에서는 기본 스크린 리더로 VoiceOver를 제공하고 있는데, VoiceOver를 이용하면 콘텐츠를 소리로 들을 수 있다. 유저 가이드도 있으니 참고해보면 좋을 거 같다.

이 섹션을 추가한 이유는 단순한데, 생각보다 많은 사람들이 장애인을 생각할 때 시각 장애인을 제일 먼저 떠올리고, 시각 장애인을 대상으로 한 접근성 개선 작업만 우선하는 점에 대해서 이야기하고 싶었기 때문이다.

장애에는 다양한 종류가 있기 때문에, 접근성 개선 작업을 진행할 때 절대 특정 종류의 장애만 우선하는 것은 좋지 않다고 생각한다. 물론 어떤 작업이던 이전보다 개선된다는 점에서는 긍정적이지만 항상 다양한 시점으로 개선해주면 좋다.

마무리

이 글이 여러분들에게 도움이 되기를 바라고 있다.

접근성 개선 작업을 진행할 때에는, 어느날 갑자기 ‘우리 접근성 개선해야돼!’ 라면서 시작하기 보다는 평소 프로젝트를 진행할 때 바탕에 접근성을 깔아둔 상태로 작업하는 것이 좋다.

만약 이미 프로젝트를 시작했고, 여러분이 접근성에 대해서 잘 몰랐던 상태였다면 지금이라도 늦지 않았으니 접근성 가이드라인을 잘 살펴보고 어떤 포인트부터 개선 가능할 지 살펴보면 좋을 거라 생각한다.

가까운 토요일에 접근성과 관련한 이벤트를 개최한다. 이 글에서 나온 내용들에 대해서 오프라인에서 이야기하는 자리이다. 이 글을 통해 관심이 생겼다면 이 이벤트에 참석해보는 것도 좋을 거 같다.

--

--

--

FE Tech Lead Manager, FE Domain Lead from 오늘의집, Business: choeun@techhtml.dev

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
조은, John Cho

조은, John Cho

FE Tech Lead Manager, FE Domain Lead from 오늘의집, Business: choeun@techhtml.dev

More from Medium

A sneak peek into OutSystems UI 2.8.0

Outsystems UI 2.8.0

Ingredients for Better Accessibility — Part Two: Customizing the Recipe

A chef sprinkles seasoning on a sizzling pan of spicy food

Tilda vs Frontend: 6 most common myths about the builder

How We Created 36 Unique WebGL Demos in 36 Days