[WEB] 웹 접근성에 대한 나의 고찰

in WEB on Web




1. 웹 접근성이란? (Web Accessibility)

웹 접근성이란 웹 사이트에서 제공하는 정보를 차별 및 제한없이 동등하게 이용할 수 있도록 보장하는 것을 말한다.
쉽게 말해, 신체적 조건, 환경적 조건에 관계없이 웹에 접근해서 정보를 이용할 수 있도록 보장해달라는 것인데
신체적 조건 : 장애인 및 고령자를 포함한 모든 사람
환경적 조건 : 다양항 platform / device와 웹브라우저 등 모든 환경
이라 생각하면 이해가 쉬울 것이다.

이것 또한 편견일 수 있지만 아마 대부분의 개발자들은 신체적 조건의 차별을 받는 사람이 별로 없을 것이라 생각한다.
그래서 아무 지장없는 우리의 시선으로 웹을 개발할 때, 우리는 웹 접근성을 놓치기가 매우 쉽다.
하지만 웹의 시초, World Wide Web이 뜻하는 “모든 사람들이 인터넷이라는 연결된 컴퓨터를 통해 차별없이 정보를 공유하자”는 그 의도에 맞춰 우리는 결코 웹 접근성을 간과하면 안된다.
그런 의미로 오늘은 웹 접근성에 대해 알아보도록 하자.


2. 웹 접근성의 신체적 조건

웹 접근성에서 가장 고려되어야 하는 사람들은 신체적 장애를 가진 사람들이다.
장애를 가진 사람이 웹을 사용하는 것이 얼마나 불편할 지 생각해본 적이 있는가?
나를 포함하여 장애를 가지지 않은 사람은 지레짐작으로만 알 수 있을 것이다.
다음 예시를 보면 이해가 조금 더 빠를 것이다.

  • 소아마비를 가진 사람들은 마우스나 키보드를 이용할 때 손을 사용할 수 없어 입을 사용한다.
  • 뇌성 마비를 가지고 있는 사람들은 팔, 입의 움직임이 제한되어 머리를 사용한다.
  • 장님일 경우, 앞을 전혀 볼 수 없어 웹 페이지를 스크린리더를 통해서만 접한다.
  • 노년층으로 갈 수록 마우스의 자유로운 사용이 어려워진다.
  • 또한 시력 저하로 인해 작은 글자는 인식할 수 없다.

조금만 생각해봐도 이들이 얼마나 불편할 지 가늠조차 안간다. 🤭😭

찾아보니 이들의 입장에서 웹을 체험할 수 있는 좋은 웹페이지가 있어서 소개하고 싶다!

온라인 웹 접근성 체험 NULI 바로가기

NULI 라는 웹사이트인데 다양한 사용자 환경을 체험해볼 수 있는 사이트이다.
저시력 시각장애, 전맹 시각장애, 손 운동장애, 중증 운동장애를 겪는 분들의 입장이 되어서 웹을 체험할 수 있다.

나는 이들 중 내가 생각하기에 조금이라도 웹 접근성이 높아보이는 저시력 시각장애를 체험해보았다.

저시력 장애 체험

🤭🤭
앞서 글을 읽었을 때 보다 더 와닿았다.
어떻게 정자역을 찾으라는거지…?
이 사람들이 이 화면만 보고 과연 정상적으로 웹 서비스를 이용할 수 있을까?

중증 운동 장애 체험

이번엔 중증 운동 장애를 체험해보았다.
입에 펜을 물고 화면을 움직이는 것이 상상 이상으로 정말 어려웠다.ㅠ

글로만 신체적 장애를 가진 분의 입장을 생각했던 것과 내가 간접적으로나마 체험한 것은 완전히 달랐다..!
웹 개발자로서 웹 접근성을 왜 준수해야하는지에 대한 경각심을 더 갖게 되었다.
(다들 오래걸리지 않으니 저 사이트에서 체험을 해보길 추천한다!)

시각장애인도 할 수 있는 모바일 인디게임 영상 바로가기
웹은 아니지만 사용자 접근성을 잘 준수하여 개발한 모바일 게임에 관련된 영상이니 다들 한번 참고하길 바란다.

3. 웹 접근성이 높은 개발 원칙 - 신체적 조건

그렇다면 이러한 신체적 장애를 가진 이용자를 위해 어떤 규칙을 준수하며 웹 개발을 해야할까?
웹 접근성이 높은 웹을 개발하기 위해서는 다음 영역의 용이성을 지켜야 한다.

인식의 용이성

  • 텍스트가 아닌 콘텐츠는 그 의미나 용도를 인식할 수 있도록 대체 텍스트를 제공해야 한다.
  • 이미지는 alt 속성을 활용하여 적절한 대체 텍스트를 제공한다.
  • 캡차 이미지시, 음성으로 들을 수 있도록 청각적 캡차를 같이 제공한다.
  • 멀티미디어 콘텐츠에는 자막, 대본 또는 수화를 제공해아 한다.
  • 콘텐츠는 색에 관계없이 인식될 수 있어야 한다.
  • 차트, 페이지네이션, 슬라이드 버튼 선택 여부 등은 색이 아닌 패턴, 굵기, 보양, 테두리 등의 다양한 방법으로 구분할 수 있도록 제공한다.
  • 텍스트 콘텐츠와 배경 간의 명 도 대비는 4.5 대 1 이상이어야 한다.
  • 오디오, 비디오의 소리가 자동으로 재생되지 않아야 한다.
  • 이웃한 콘텐츠는 구별될 수 있어야 한다.



운용의 용이성

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



이해의 용이성

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



견고성

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



4. 웹 접근성의 환경적 조건

웹 접근성에서의 환경적 조건이란, 다양한 기기 (PC, 모바일, PDA)에서, 운영체제, 웹브라우저(IE, Chrome, Safari 등) 또는 저사양 및 저속회전 사용자나 이미지, 동영상 등을 볼 수 없는 환경을 의미한다.

쉽게 말해 웹을 접근하는 기기의 성능, 기기의 종류를 뜻하는데 나는 여기서 기기의 크기 즉, 반응형 웹에 초점을 두고 살펴보고자 한다.

반응형 웹이란?

디바이스 종류에 따라 웹페이지의 크기가 자동적으로 재조정되는 것을 의미한다.
어떠한 환경에서도 그 디바이스에 맞게 화면 사이즈가 변화되어 사용자가 보기 편한 웹을 제공하는 것이다.

모바일을 통해 웹사이트에 접근했을 때, 글씨가 너무 작아지고 화면 비율이 전혀 맞지 않아 불편했던 경험이 있는가?
그런 경험을 겪게 한 웹사이트는 아마 반응형 웹의 조건을 만족하지 못하고 있을 것이다.

반응형 웹과 떼려야 뗄 수 없는 존재가 있다. 바로 적응형 웹이다.
적응형 웹은 서버사이드에서 클라이언트의 정보를 미리 받아 해당 조건별로 정해진 환경을 보여주는 것이다.
즉, 사용자의 환경이 모바일이라면 스마트폰에 최적화된 별도의 웹사이트를 구축해놓고, 그 화면을 보여준다.

예를 들어 naver 의 경우 웹으로 접근하면 www.naver.com 으로 접속되고, 모바일에서는 m.naver.com 으로 접근이 된다.

적응형 웹은 정해진 환경에 따라 미리 만들어놓은 페이지를 보여주는 반면, 반응형 웹은 디바이스가 달라져도 같은 페이지의 리소스를 가지고 온다.
각각 장단점이 있겠지만 하나의 화면만 개발하고 디바이스에 따라 화면을 조정해줄 수 있는 반응형 웹이 나는 조금 더 끌린다🤩

그렇다면 반응형 웹은 어떻게, 무엇을 고려하여 개발해야 할까?


5. 웹 접근성이 높은 개발 원칙 - 반응형 웹


meta 태그 - viewport 활용하기

viewport란 웹 페이지에서 사용자의 보이는 영역(visible area)를 뜻한다.

<meta name="viewport" content="width=device-width, initial-scale=1.0">

  • width=device-width : 페이지의 너비를 기기의 스크린 너비로 설정한다. 렌더링 영역을 기기의 뷰포트 크기와 같게 만든다.
  • initial-scale = 1.0 : 처음 페이지 로딩시 확대/축소가 되지 않은 원래 크기를 사용하도록 한다. (0~10 사이의 값을 가진다.)
  • minimum-scale : 줄일 수 있는 최소 크기를 지정한다. (0~10 사이의 값을 가진다.)
  • maximum-scale : 늘릴 수 있는 최대 크기를 지정한다. (0~10 사이의 값을 가진다.)
  • user-scalable : yes / no 값을 가지며 사용자가 화면을 확대,축소 할 수 있는가를 지정한다.


width 는 뷰포트의 가로 크기를 정하며, 숫자와 퍼센트로 나타낼 수 있다.
뷰포트를 따로 지정하지 않을 때의 기본 width는 980으로 퍼센트로 나타냈을 때는 100% 이다.
만약 width=800 으로 한다면, 800개의 픽셀 개수를 가진 width로 화면이 설정되는 것이다.
위의 코드는 device-width 이므로 디바이스의 넓이에 맞추어 보여달라는 의미이다.

반응형 웹을 위해서라면 device-width 를 기준으로 화면을 보여주는 것이 더 바람직 할 것이다.👍

css 미디어쿼리 활용하기

반응형 웹을 만들기 위한 가장 핵심이라고 생각하면 된다.
화면의 크기별로 css를 다르게 제공하여 사용자의 디바이스에 맞는 화면을 제공한다.

.letter {
    font-size: 36px;
}

@media (max-width: 760px) {
    .letter {
        font-size: 16px;
    }
}

letter 클래스의 글자 크기를 기본으로 36px로 설정하는데,
화면의 크기가 760px 이하에서는 16px로 제공한다는 의미이다.

min-width, max-width 를 활용하여 화면의 크기에 맞게 유동적으로 변화하는 멋진 웹을 만들 수 있다 🤩


6. 웹 접근성의 안 좋은 예

인터넷 부실공사라는 말을 들어본 적이 있는가?
여기 조금 부끄럽지만 내가 학부생시절, 근로장학생으로 근무하며 웹 개발에 참여했던 로완 뮤직 엔터테인먼트 웹사이트가 있다.
한 화면이 신체적, 환경적 조건에 모두 맞지 않아서 안 좋은 예로 최적이라고 말할 수 있다…ㅎㅎ🤔🤫

로완뮤직 사이트 바로가기

로완뮤직 레슨 이미지

수강생 모집을 위한 안내 화면이다.
당시 클라이언트이신 교수님께서 그냥 이미지를 넣어달라고 요청하셔서 이미지를 넣긴했었다…
웹 접근성을 공부하고나니 더 볼품없어진 내 첫 웹 페이지…하하😭

우선, 실용음악 레슨에 관련된 모집파트, 강사진, 레슨시간, 수강료 등등의 아주 중요한 정보가 들어있는데
이 내용이 무려 한 이미지에 담겨있다.
심지어 alt 태그도 없다…

당시 이 사이트에 들어오는 학생들의 가장 큰 이유가 재학생을 대상으로 한 이 레슨을 받기 위해서였는데…!!
시각장애를 겪는 학생들은 이걸 도대체 어떻게 보고 어덯게 신청을 한 단 말인가….!

이렇게 중요하고 많은 정보는 이미지로 제공되지 않고, 표나 li 태그를 사용해서 나타내야 한다.
(스크린리더로 읽힐 수 있게끔)

과연 이 화면을 모바일에서 본다면..?

로완 뮤직 모바일 이미지

위 이미지는 개발자 도구를 통해서 본 아이폰X 기준의 화면이다.
맙소사.. 이미지가 너무 웹 페이지 전체 영역보다 밖으로 나가있어서 옆으로, 위아래로 스크롤을 해야한다…

과거 내가 개발했던 것이 안좋은 예로 소개를 하며 많이 부끄럽고, 그 당시 내가 참… 아무것도 몰랐구나 라는 생각이 많이 든다.
지금 다시 유지보수의 기회가 생긴다면 바꾸고 싶은 부분이 정말 많다. (거의 새로 만드는 수준으로ㅠ)


7. 내가 희망하는 앞으로의 기술 방향성

모바일 접근성은 많은 유저들의 서비스 이용률에 영향을 많이 미치기 때문에 많이 발전중이고 적용중이다.
하지만 신체적 장애를 가진 유저를 위한 개선은 발전 속도가 매우 더뎌지고 있다.
유명한 웹사이트를 돌아다녀보면 웹 접근성의 기본으로 알려진 이미지의 alt 속성 넣기조차 제대로 이루어지지 않고 있는 것을 보기 쉽다.
거창하게 말해 앞으로의 기술 방향성이지 사실은 이렇게 변했으면 좋겠다 싶은 나의 바램이다.

  • 웹 접근성에 대한 웹 개발자들의 인식 강화 : 장애인 차별법만 지키자는 안일한 생각 갖기 않기
  • 다양한 디바이스에서의 웹 표준도 준수하도록 노력하기 (특히 PDA에서 잘 지켜지지 않고 있다고 한다.)
  • 라이트하우스 같은 웹 표준 준수 측정 서비스 많이 등장하기 (저번 프로젝트때 사용해봤는데 문제점도 지적해주고 아주 좋았다!)
  • 접근성 데이터가 자동 완성되도록 하는 시스템 개발 : 개발자의 추가적인 작업 없이 차트, 표 등을 구현함과 동시에 자동으로 접근성이 보장된 데이터가 생성되도록 하는 시스템
  • 보편화된 명암 대비, 색체 등의 웹 접근성 디자인 가이드 : 디자인을 전공하지 않은 나로서는 이 부분이 취약했다ㅠ
  • 더 활성화되고 사용하기 편리해지는 크로스브라우징



8. 나의 회고

지난 “웹 접근성이 낮은 데이터 테이블 찾아 수정하기” 프로젝트에 이어 웹 접근성의 중요성의 필요성을 확인할 수 있는 시간이었다.
이렇게 제대로 시간을 갖고 살펴볼 때는 “그래! 앞으로 꼭 웹 접근성을 준수하며 개발을 해야지!”라고 다짐하는데, 막상 개발을 하다보면 기능 개발에도 급급하여 웹 접근성을 잊곤 한다. (도대체 언제쯤 정신차릴까 나자신..!)
내 프로젝트를 개발하며, 웹 표준 지침이 가리키는 모든 내용들을 다 준수하긴 어려울테지만, 자주 언급되고 기본이 되는 접근성 규칙은 가능한한 지키도록 노력하고자 한다. (시멘틱 태그 사용, alt 속성, 태그 잘 닫기 등등)

반응형 웹은 사실 실제 프로젝트를 진행하다보면, 미디어 쿼리로 모든 화면을 구성하기 보다, 부트스트랩 등을 활용하여 전반적인 화면 비율은 먼저 쉽게 잡아가곤 하기 때문에 잘 안지켜질 일이 별로 없었다. (눈에 보이는 화면이다보니 이상한 부분을 바로바로 수정하기도 하지만ㅎ)

내가 잘 지키지 못하는 부분은 크로스브라우징 영역.
개발 환경을 크롬을 베이스로 두다보니 여러 브라우저 환경에서의 테스트가 번거로웠고, 그러다보니 크롬에만 맞춰서 개발을 하곤 했다.
특히 점점 죽어가고 있는 익스플로어는 정말 고려하지 않는데, 주변만 봐도 크롬보다 아직 익스플로어를 사용하는 지인들이 많다.
앞으로는 크로스브라우징 신경 많이 쓰기!!

서비스 개발자를 꿈꾸며, 내가 개발한 서비스를 모든 사람이 어떠한 환경에도 제약받지 않고 평등하게 사용할 수 있기를 바라며,
늘, 언제나, 웹 접근성을 염두해두며 개발할 수 있는 내가 될 수 있으면 좋겠다.😳