개발자 / 웹서비스

지금 당장 적용할 수 있는 웹 접근성 개선 방법 10가지

Serdar Yegulalp | InfoWorld 2021.05.07
인터넷은 현대의 가장 큰 혁신 가운데 하나라는 점은 의심의 여지가 없다. 특히, 웹은 수십억 명의 사람에게 정보, 엔터테인먼트, 재화 및 서비스, 인간관계에 대해 이전 세대들이 거의 상상하지 못했던 수준의 접근성을 제공했다.

하지만 모든 사람이 웹을 동등하게 사용할 수 있는 것은 아니다. 시각 또는 신체적 장애가 있는 사람은 웹 상에서 다른 사람이 당연하게 여기는 것들을 기술의 도움을 받아야만 이용할 수 있다. 이런 보조 기술은 웹 개발자가 사용하거나 지원하는 경우에만 성공적일 수 있다. 까다로운 페이지 레이아웃 때문에 스크린 리더(Screen Reader)가 헷갈릴 수 있으며, 심지어 장애가 없는 사람도 저대비 텍스트나 오해의 소지가 있는 색상으로 이해하는 데 문제가 될 수 있다.

웹상의 접근성 표준은 일반적으로 W3C의 WCAG(Web Content Accessibility Guidelines)에 기초한다. WCAG의 모든 지침을 따르는 것은 어렵지만 세부적인 것에 치중해 큰 그림을 놓치기 쉽다.

이번 기사는 웹 사이트의 접근성을 높이는 10가지 방법을 복잡성의 순서대로 살펴본다. 가장 간단한 제안사항부터 구현한 후에 시간과 자원이 허용하는 대로 진행할 수 있다.

웹 접근성 조치는 시각 또는 운동 제어 문제가 있는 사람들에게 도움이 될 뿐 아니라 모든 사람이 웹 사이트를 더 쉽게 읽고 탐색할 수 있다. 웹 사이트에 모든 방문자에게 도움이 되는 이런 개선점을 적용할 수 있다.


웹 사이트의 이미지에 캡션을 적용한다(쉬움)

지금 당장 쉽게 실천할 수 있으면서도 효과가 좋은 것은 웹 사이트의 이미지에 캡션(Caption)을 적용하는 것이다. 캡션을 통해 스크린 리더 소프트웨어는 텍스트에 포함된 이미지의 설명을 읽을 수 있다. 또한 대역폭이 제한되어 있거나 연결에 문제가 있는 웹 사이트 방문자에게 도움이 될 수 있는 이미지에 대한 본문 플레이스홀더(Placeholder)를 제공한다.

이미지에 캡션을 적용하는 가장 쉬운 방법은 alt 태그를 이미지에 보이는 것에 대한 본문 설명을 제공하는 img 태그에 추가하는 것이다.

<img onerror="removeImage($(this));" src=”https://yoursite.com/deckard.jpg” alt=”외투를 입은 짧은 머리의 남자”>

이미지의 메타데이터(Metadata)뿐만 아니라 이미지와 함께 캡션을 텍스트의 일환으로 제공하려면 figure figcaption 블록 레벨 요소를 사용한다. 이 요소들은 CSS 클래스를 통해 개별적으로 스타일을 지정하거나 변경할 수 있다. 또한 figcaption은 블록 레벨 요소이기 때문에 필요에 따라 다른 요소나 형식을 포함할 수 있다.

설명을 제공하는 요소에 추가할 수 있는 또 다른 태그는 longdesc 태그이다. 이미지를 설명하는 텍스트를 포함하는 대신에 설명을 제공하는 URL을 포함할 수 있다. 하지만 longdesc에 대한 브라우저 지원은 현재 불투명하기 때문에 여기에만 의존하지 않는 것이 좋다. longdesc을 alt 또는 figure/figcaption과 함께 사용한다.


헤더 태그를 사용해 문서를 정리한다(쉬움)

웹 디자인 시 헤더 태그를 많이 사용하지만 콘텍스트 안에서 반복해야 한다. h1, h2, h3 등을 사용해 문서를 개요 레벨 세션으로 나눈다. 가장 쉬운 접근방식은 페이지의 제목을 h1으로 표시하고 다른 (모든) 하위 제목을 h2로 표시하는 것이다.

이것이 접근성에 중요한 이유는 다음과 같다. 많은 스크린 리더가 헤더 태그를 키입력 또는 명령으로 직접 건너뛸 수 있는 앵커(Anchor)로 해석한다. 그래서 추가적인 메타데이터를 추가하지 않고도 문서의 탐색성이 높아진다.


서식에 라벨을 적용하고 가독성을 유지한다(쉬움)

서식의 필드에 대한 설명 텍스트가 있다면 좋다. 이런 설명이 설명하는 요소와 명시적으로 연결되어 있으면 더 좋다. 항상 label 태그를 사용해 각 필드 설명과 필드를 연결시킨다. 그러면 스크린 리더와 다른 접근성 시스템이 각 필드에 대한 더 많은 콘텍스트를 얻을 수 있다.

서식의 또 다른 잠재적인 접근성 문제는 서식 필드에 플레이스홀더 텍스트를 사용하는 것이다. 플레이스홀더 텍스트(필드에 아무것도 입력하지 않을 때 기본으로 표시되는 텍스트 제안사항)가 유용한 경우가 많다. 하지만 일반적으로 흐릿하게 표시되어 가독성이 떨어질 수 있기 때문에 여기에 의존해 필수적인 정보를 제공해서는 안 된다. 플레이스홀더 텍스트의 정보는 필드의 title 속성을 통해서도 제공되어야 한다. 마우스를 올릴 때 툴팁(Tooltip)으로 표시되거나 리더 소프트웨어가 추출할 수 있다.

최신 브라우저에서는 브라우저의 검사 패널을 사용해 서식, 이미지 라벨, 기타 접근성 문제에 대한 신속한 피드백을 얻을 수 있는 경우가 많다. 예를 들어, 최신 크롬(Chrome) 및 엣지(Edge) 빌드에서는 개발자 도구 창의 ‘문제(Issues)’ 탭에 접근성 개선 제안사항이 나열된다.
 
ⓒ IDG


요소에 대한 키보드 탐색의 일관성과 접근성을 확보한다(중간)

대부분의 웹 페이지 탐색은 마우스 또는 터치 이벤트를 통해 이루어진다. 누군가 클릭하기를 바라는 요소는 키보드 탐색으로 접근할 수 있어야 한다. 단, 그 과정에서 다른 것들이 망가지지 않도록 주의한다.

페이지가 포커스(Focus) 상태일 때 Tab 키를 사용해 페이지의 요소 사이에서 순서대로 이동할 수 있으며, 이 속성을 ‘탭 인덱싱 가능(tab-indexable)’이라고 부른다. 클릭 가능한 요소는 기본적으로 탭 인덱싱이 가능하고 문서에 배치된 순서대로 탭 인덱싱된다.

그 목적을 달성하기 위해 문서 요소들의 순서가 가능하면 탭 순서를 따르도록 한다. tabindex 요소를 사용해 요소가 색인 방식을 재배열할 수 있지만 최신 웹 디자인 전략은 가능하면 재배열을 피하는 것이다.

또한 사용자 정의 생성된 자바스크립트 요소에 탭 인덱스를 추가해야 할 수도 있다. 그런 경우 다른 요소의 탭 인덱스를 부주의하게 가로채는 일이 없도록 주의하자.

요소의 접근성을 높이는 또 다른 요소는 키를 눌러 특정 요소를 활성화 또는 이동할 수 있는 키보드 바인딩을 활용하는 것이다. 예를 들어, 채팅 애플리케이션에서 텍스트 상자가 포커스 상태이면 Alt-S를 사용해 메시지를 보내거나 (다시 스크롤하여 돌아갈 필요 없이) 다른 단축키를 사용해 텍스트 상자로 되돌아갈 수 있다.

페이지 요소의 키 바인딩을 추가하고 싶다면 다음을 기억하자.
  • 사용자에게 단축키와 사용할 수 있는 곳에 대해 명확히 알려준다. 사용자가 스스로 단축키 동작을 찾아내거나 실수로 잘못 사용하는 일이 없어야 한다. 또한 동작의 범위도 중요하다. 특정 요소가 포커스 상태인 경우에만 단축키가 활성화되는 경우 사용자가 알고 있어야 한다.
  • HTML 네이티브 accesskey attribute를 통해 키 바인딩을 특정 요소에 할당할 수 있다. 하지만 그 동작이 일관되게 지원되지 않고, 심지어 일부 키 바인딩은 모든 사용자에게 제공되지 않을 수 있다. 따라서 이 방식은 권장하지 않는다.


확대/축소뿐 아니라 수동 글꼴 크기 조정을 허용한다(중간)

사용자가 확대/축소를 통해 요소의 크기를 조정할 수 있도록 할 때의 문제점은 페이지에 있는 모든 것의 크기가 바뀐다는 점이다. 더 나은 방법은 페이지상에 필요에 따라 베이스 텍스트의 크기를 변경하는 +/- 아이콘을 구현하고 해당 설정을 클라이언트에 저장하는 것이다. 이를 위해서는 문서의 텍스트 스타일에 대한 베이스 글꼴의 크기를 변경하는 자바스크립트 기능만으로는 부족하다.


레이아웃을 위해 테이블을 사용하지 않는다(중간)

테이블을 사용하지 말아야 한다는 의미는 아니다. 테이블은 엄격한 행렬 형식으로 데이터를 제공해야 할 때 매우 유용하다. 단, 레이아웃, 즉 표 정리 데이터가 아니나 텍스트의 형식을 지정하기 위해 사용해서는 안 된다. 테이블을 사용해 요소의 위치를 결정하는 것이 보편적이던 때가 있었다. 하지만 현재 플렉스박스(Flexbox)와 기타 블록 레벨 스타일 방법은 항목을 정확하고 반응성 있게 배치하는 더욱 정교하고 강력한 수단을 제공한다.

레이아웃에 테이블을 사용하지 않아야 하는 주된 이유는 의도가 헷갈리기 때문이다. 스크린 리더는 테이블의 콘텐츠를 데이터로 해석한다. 레이아웃으로 해석하지 않는 것이다. 테이블의 행렬 헤더를 포함된 데이터의 라벨로 해석한다. 테이블을 레이아웃에 사용하면 스크린 리더가 이를 잘못 해석할 수 있다.

이미 레이아웃에 테이블을 사용하지 않고 최신 CSS 프레임워크를 사용하고 있다면 다행이다. 그렇지 않다면 시간을 투자해 변경하고 테이블 사용을 중단한다. 잠재적으로 시간이 소요될 수 있는 작업이기 때문에 ‘중간’ 레벨 항목으로 표시한 것이다.


웹 사이트의 다크 또는 고대비 모드를 생성한다(중간)

웹 사이트와 앱의 다크 모드가 유행하고 있으며, 그럴 만한 이유가 있다. 화면이 밝고 커지며 사용하는 시간이 길어지면서 디지털 라이프 속에서 다크 모드가 눈을 보호하는 역할을 하게 되었다.

웹 사이트의 여러 사전 패키지 테마가 다크 모드 스타일 시트와 함께 제공된다. 이미 사용하고 있다면 사이트의 햄버거 메뉴 등에 셀렉터를 손쉽게 배치하여 읽는 사람이 다크 모드를 손쉽게 켜거나 끌 수 있도록 하고 브라우저의 상태와 일관성을 유지할 수 있다. 

하지만 사용자 정의 테마가 적용된 웹 사이트는 처음부터 다크 모드를 구축해야 하고 사이트의 모든 요소의 가독성을 확보해야 하기 때문에 다크 모드를 적용하기가 더 어려울 수 있다. 디자인 변경을 고려하고 있다면 스킨을 다크 모드로 손쉽게 변경할 수 있는 테마를 고려한다.


색상과 디자인을 활용해 페이지 요소를 강조한다(중간)

웹 페이지의 요소에 관심을 집중시키거나 강조하는 가장 쉬운 방법은 색상을 변경하는 것이다. 그 자체가 나쁜 아이디어는 아니지만 충분하다고 보기도 어렵다. 색상만으로 항상 눈에 쉽게 띄게 할 수 있는 것은 아니며, 시각 장애가 있는 사람들의 경우에는 더욱 그렇다.

강조할 때는 항상 2가지 이상의 방법을 사용해야 한다. 색상과 다른 디자인 패턴을 조합하면 된다. 예를 들어, 경고 요소는 빨간색으로 상자 안에 경고 아이콘과 함께 표시할 수 있다. 막대 그래프는 가능하면 텍스처(Texture)와 색상을 사용해 구분해야 한다.

물론, 이런 변화를 구현하려면 단순한 스타일 시트로는 어려울 가능성이 높다. 웹 사이트 표시 방식에 따라 대대적인 디자인 변경 노력이 필요할 수 있다. 또한 색맹 시뮬레이터로 사이트의 컬러 체계를 테스트하여 특정 시각 장애가 있는 사람들이 사이트 방문 시 또는 시각 요소 확인 시 어려움이 있는지 판단할 수 있다.


가능하면 서술적인 URL을 사용한다(중간)

서술적인 URL은 대상에 관한 정보를 부호화 한다. https://magazino.com/article/2125451 같은 불투명한 URL은 해당 글에 관한 어떤 정보도 제공하지 않는다. 클릭해 확인하거나 최소한 페이지의 메타데이터를 읽어야 한다(이런 것이 불가능할 수도 있다). 반면에 https://magazino.com/article/ten-best-harrison-ford-films/2125451 같은 서술적인 URL은 한 눈에 꽤 많은 것을 알 수 있다. 

서술적 URL은 방문자가 기사의 내용이 무엇인지 파악하기 위해 수행해야 하는 일의 양을 줄여준다. 그래서 스마트하게 디자인한 웹 사이트는 URL의 일정 부분을 콘텐츠에 대한 짧은 텍스트 설명에 할당하며, 글 ID는 서버가 제공할 글을 결정하기 위해 사용한다.

서술적 URL을 사용하지 않는 웹 사이트는 문제가 직면하게 된다. 몇 년 동안 구형 콘텐츠가 축적된 상태에서 완전히 새로운 URL 체계로 변경하는 것은 쉽지 않다. 하지만 디자인 변경 시 서술적 URL을 포함시킬 만한 가치가 있다.


WAVE 도구를 사용해 웹 사이트 접근성을 테스트한다(어려움)

WAVE 도구는 유타 주립 대학교의 CPD(Center for Persons with Disabilities)에서 개발하여 유지 관리하는 것으로 웹 사이트의 접근성에 관한 자세한 그래픽 피드백을 제공한다. 

WAVE에 URL을 입력하거나 API를 사용하면 분석된 페이지의 모든 접근성 문제에 대한 자세한 보고서를 제공한다. 분석된 페이지는 문제의 위치를 나타내는 표시와 함께 다시 표시되기 때문에 각 문제에 손쉽게 접근해 페이지의 소스의 출처를 확인할 수 있다.
 
ⓒ IDG

접근성을 염두에 두지 않고 개발된 웹 사이트는 분명 WAVE에서 많은 문제가 발견될 것이다. 따라서 WAVE 분석은 산발적인 시정 조치가 아니라 웹 사이트 전체를 대대적으로 재정비하기 위한 준비 또는 이와 관련된 작업에서 빛을 발한다. editor@itworld.co.kr 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.