프론트엔드 웹 접근성(a11y) - 기본

• 웹 접근성(a11y) - 기본 (현재 글)
• 웹 접근성(a11y) - toast
• 웹 접근성(a11y) - rem

접근성

일반적으로 웹에 접근할 수 있다는 것은 웹에서 제공하는 컨텐츠 및 기능을 사용할 수 있다는 것이다. 즉 누구나 기능을 사용할 수 있어야 한다. 개발자는 모든 사용자가 키보드, 마우스 또는 터치를 사용하여 서비스와 상호작용할 수 있다 가정하고는 한다. 이러한 생각은 일반적으로는 잘 작동하는 사용자 경험으로 이어질 수 있지만 누군가에게는 단순한 성가심에서 서비스와 상호작용을 중단하는 문제를 발생시킨다.

따라서 접근성은 일반 사용자의 범위 밖에 있는 사용자의 경험을 의미하지만, 오직 특정 장애를 겪고 있는 사용자와 관련이 된 것은 아니다. 주로 접근성에 대한 논의를 신체적 장애가 있는 사용자에게 초점을 맞추는 경향이 있지만, 우리 모두는 어떠한 이유든 액세스할 수 없는 인터페이스를 접할 수 있다. 특정 지역, 네트워크 환경, 접근 장치에 따라 제대로 동작하지 않는 경우를 본 적이 있을 것이며 모두 접근성 문제이다.

접근성 지침

WCAG(Web Content Accessibility Guidelines) 2.0를 간단하게 요약하면 다음과 같다.

WCAG는 4가지 원칙을 중심으로 구성된다.

• 인지 가능(Perceivable): 사용자가 컨텐츠를 인지할 수 있는가? 이는 시각과 같은 특정 감각으로 무언가를 인지할 수 있다고 해서 모든 사용자가 인지할 수 있다는 의미는 아니라는 점을 기억하자
• 작동 가능(Operable): 사용자가 UI 컴포넌트를 사용하고 컨텐츠와 상호작용할 수 있는가? 예로 호버 인터렉션이 필수적으로 필요하다면 마우스나, 터치가 불가능한 사용자는 조작할 수 없다.
• 이해 가능(Understandable): 사용자가 컨텐츠를 이해할 수 있는가? 사용자가 인터페이스를 이해하는데 어려움 없으며, 일관성을 가지고 있도록 한다.
• 견고함(Robust): 다양한 환경(브라우저, 장치 등)에서 컨텐츠를 사용할 수 있어야 한다.

WCAG에서 접근성에 대한 의미와 개요를 자세히 다루고 있지만 부담스러운 내용으로 느껴질 수 있다. 하지만 부담을 덜어주기 위해 따르기 쉬운 체크리스트로 정리한 글이 있다.

일명 WebAIM 체크리스트는 개발자가 구현해야 하는 것에 대한 간략하지만 높은 퀄리티를 제공한다. 이를 사용하면 당사 서비스의 접근성에 발전이 있을 것이다.

중요성

개발자의 자원은 제한적이기에 소수로 여겨지는 집단은 배제될 수 있다. 그렇기에 서비스 내에 접근성을 도입해야 할 이유를 찾기 어려울 수 있다. 접근성은 모든 사용자에게 당사의 서비스를 사용할 수 있도록 포괄적인 경험을 만들기 때문에 중요하다. 이는 곧 기업의 이미지로 상당한 영향을 미칠 수 있다. 예를 들면

• 마우스를 사용할 수 없는 장애가 있는 사용자를 고려하면 마우스 배터리가 방전된 사용자에게도 도움이 된다.
• 적절한 명암비를 사용하면 모든 사람이 서비스를 더 쉽게 이해할 수 있따.
• 최근 스마트TV나 게임 콘솔에서 웹 사이트를 접근할 수 있고, 이는 극단적인 예이지만 사용자는 다양한 장치를 사용한다.

캐나다에서는 WCAG에 따른 지침을 충족하도록 법으로 지정하여 많은 기업들이 웹 접근성에 대한 많은 투자를 하고 있다. 옆 나라 미국 역시 관련 고소건은 매해 늘어나고 있고, 당사의 서비스가 인기 있고 누구나 액세스할 수 없다면 고소를 당할 수 있다는 것이다. 대한민국은 미국의 문화를 이어 받는(?) 경우가 많기 때문에 접근성을 높이는데 미리 참여할 수 있다.

마지막으로 접근성은 SEO 크롤러에게도 점점 중요해지고 있다.

실천 가이드라인

시멘틱 태그

모든 레이아웃을 div 태그로 만드는 대신 시멘틱 태그를 사용을 하도록 한다. 대표적으로 탐색에는 nav, 하단 글 영역에는 footer, 컨텐츠 영역을 래핑 하는 section, 기사는 article 등이 있다.

폰트

• 작은 폰트 사이즈를 사용하지 말자. 일반적으로 사용해야 하는 가장 작은 폰트 사이즈는 12px이지만 되도록 16px을 유지하려고 노력한다.

• px 대신 rem(em) 단위를 사용하여 폰트 사이즈를 지정하자. rem 단위를 사용하면 사용자가 장치 및 브라우저에서 폰트 사이즈를 조정할 수 있다. px을 사용하여 정의된 폰트사이즈는 사용자가 페이지를 명시적으로 크기 조절한 경우에만 조정된다.

포커스

일반적으로 포커스 상태는 개발자가 의도적으로 기능을 막지 않는 한 유효한 기능이다. 따로 표시를 추가해주지 않고는 outlint: 0을 주지 않도록 하여 포커스 상태를 명확하게 나타내도록 한다.

일반적으로 기본 포커스 상태를 유지하여 이에 의존하는 사용자가 다양한 사이트에서 일관된 경험을 할 수 있도록 하는 것이 좋다. 링크, 버튼, 입력 등, 모든 폼 컴포넌트에는 포커스에 대한 명확한 상태 표시가 있어야 한다.

버튼

• div를 버튼으로 사용하지 않는다. div는 포커스를 맞출 수 없으며 키 이벤트가 활성화되지 않는다. div 또는 외에 비대화형 태그를 반드시 이용해야 하는 경우 키를 누를 때 동일한 키보드 이벤트를 트리거 해야한다.

• 비대화형 요소를 포커스 가능하게 만들기 위해 어트리뷰트를 지정한다. <div id="myDiv" tabindex=0 role="button" enter>Dummy text</div> 이렇게 하면 컴포넌트를 탭으로 액세스할 수 있을 뿐만 아니라 .focus()을 이용해 개발자가 의도적으로 포커스를 맞출 수 있고, 태그를 유의미하게 만들 수 있다.

• 앵커를 버튼으로 사용하지 않는다. 링크는 버튼이 아닌 링크의 역할을 해야한다.

사용자가 실수로 이웃 요소를 잘못 클릭하지 않도록 탭은 최소 40x40px 간격을 유지하도록 한다.

• 텍스트가 없는 버튼에 aria-label을 추가한다. 버튼에 텍스트가 없으면 aria-label을 사용하여 버튼의 동작을 간략하게 설명해야한다. 예를들어 장바구니 페이지에서 상품을 지우는 버튼은 다음과 같이 작성할 수 있다. <button aria-label="장바구니에서 상품을 제거합니다." class="trash-icon" />

쿠팡 장바구니 삭제 버튼

링크

• a 태그를 버튼으로 사용하지 않는다. 반대도 마찬가지로 버튼을 링크로 사용하지 않는다.
• a 태그에 유효한 href가 있어야 한다. a 태그에 href 어트리뷰트가 없으면 태그 사용 이유를 다시 생각해 보자. 또한 href 가 포함되지 않은 a 태그는 SEO에 영향을 미칠 수 있다.

이미지 및 사진

• 이미지가 의미를 전달하는 경우 대체 텍스트를 사용한다. 대부분 이미지에는 이미지에 표시되는 내용을 설명하는 대체 텍스트가 있어야 한다. 예로 차트의 경우 대체 텍스트에서는 어떤 차트인지를 설명해야 한다.
• 이미지가 구분선 및 레이아웃처럼 의미를 가지지 않는다면 alt="" 어트리뷰트를 추가하여 의미를 전달하지 않는다는 의미를 전달해야 한다.

제목

• 단계를 건너뛰지 않고 순서대로 header를 사용해야 한다. 제목은 스타일을 지정하기 위한 것이 아니라 페이지의 개요를 만들기 위한 것이다.
• 페이지 상단에 h1 태그를 사용하고 각 섹션을 설명하기 위해 h2~h5 태그를 사용한다.
• 한 페이지에 하나의 h1 태그만 사용한다.
• MDN 예시를 참고할 수 있다.

건너뛰기(skip navigation)를 사용하는 자세한 방법은 WebAIM에서 확인할 수 있다.

마지막

접근성은 자칫 지엽적이라 생각할 수 있다. WCAG를 읽는데 부담을 느끼는 독자들에게 이 글이 유용했기를 바란다. 접근성은 아직도 활발한 논의가 이루어지고 있는 주제이다. 관심이 있다면 트위터에서 #a11y 해시태그를 팔로우해서 피드를 받아 볼 수 있고, 논제에 자유롭게 참여할 수도 있다.

필자 역시 더 나은 a11y 포스팅을 업데이트하기 위해 노력할 것이다.