접근성이란 장애에 관계없이 모든 사람이 동등하게 웹을 사용할 수 있어야 한다는 원칙이다. 웹 기술에는 접근성을 위한 많은 기능이 내장되어 있으며 웹 개발자는 사용자를 배제하지 않도록 이를 알아야 한다.
위에서 말한것 처럼 HTML에는 접근성을 위한 대단히 많은 기능이 내장되어 있다. 어지간한 규모의 회사가(그 회사도 잘 모르겠다)아니라면 웹 개발시에 접근성을 크게 신경쓰진 않을것이다. 아마 콘텐츠 소비자가 콘텐츠 기획, 디자인, 개발을 한 사람과 동등한 위치라고 생각하기 때문일 것이다.
이 글에서는 접근성 기능에 대해 아주 깊이있게 다루진 않고 쉽게 지킬수 있는 몇가지 내용에 대해 다루고자 한다. JSX와, ESLint를 사용할 수 있는 프로젝트를 진행한다면 몇몇 플러그인을 통해 해결할 수도 있는 내용도 포함 되어있다.
간단하게 사용가능한 몇가지 접근성 관련 HTML
1. 레이블을 모든 폼 컨트롤과 연결
대부분의 경우 모든 독자가 필요한 입력을 이해하는 데 도움이 되도록 레이블이 필요함
<label for="username">사용자 이름</label>
<input type="text" id="username" name="username" />
2. 모든 이미지에 대체 텍스트 포함
모든 정보 및 기능 역할을 하는 이미지에 대체 텍스트 (alt
)가 포함되어있는지 확인. 장식용 이미지의 경우 빈 텍스트라도 입력한다. 그러면 스크린 리더가 해당 이미지는 장식용 이미지라고 판단한다.
또한 단순 장식용 이미지라면 CSS의 background 속성을 사용해도 무방하다.
<img src="clear_sky.png" alt="맑게 개인 하늘입니다." />
3. 페이지에 언어 속성값 추가
검색 엔진과 브라우저를 지원하기 위해서 이며, 검색 엔진과 브라우저는 해당 lang
값에 맞게 여러가지 지원을 해준다.
<html lang="ko-KR"></html>
4. Semantic HTML로 적절한 마크업
올바름에 가깝게 작성된 Semantic(의미론적) HTML일수록 스크린 리더가 구문 분석을 더 잘 할수 있으며, SEO 측면에서도 많은 도움이 된다. 별도 포스트에서 자세히 다뤄보겠다.
<html>
<head>
<title>Semantic HTML 문서</title>
</head>
<body>
<header>
<nav>
<ul>
<li><a href="#">Link 1</a></li>
<li><a href="#">Link 2</a></li>
<li><a href="#">Link 3</a></li>
</ul>
</nav>
</header>
<main>
<article>
<h1>Article heading</h1>
<section>
<h2>Content heading</h2>
<p>article content</p>
</section>
</article>
</main>
<section>
<h1>Section heading</h1>
<p>Section content</p>
</section>
<aside>Auxiliary content</aside>
<footer>
<figure>
<img src="logo.png" alt="" />
<figcaption>Slogan</figcaption>
</figure>
</footer>
</body>
</html>
5. 사용자가 실수를 방지하고 수정할 수 있도록 지원
사용자가 사이트에서 양식을 작성할 때, 명확한 지침 및 오류 메시지 그리고 알림을 제공한다.
사용자가 양식을 입력하다 오류가 발생하는 경우에 다음과 같은 지원을 할 수 있다.
- 사용자가 문제의 위치를 찾을 수 있도록 지원
- 구체적이고 이해하기 쉬운 설명 제공
- 어떻게 수정하면 되는지 제안 표시
<label for="phone">휴대폰 번호</label>
<input
id="phone"
name="phone"
type="tel"
pattern="^01([0|1|6|7|8|9])-?([0-9]{3,4})-?([0-9]{4})$"
aria-describedby="phone-desc"
/>
<p id="phone-desc">예) 010-1234-1234</p>
6. 코드내의 엘리먼트 순서가 논리적으로 전개되는지 확인
제공하려고 하는 정보가 코드내의 엘리먼트 순서와 일치하는지 확인, 좋은 방법은 CSS를 제거하고 비교해보는 것이다.
7. 사용자의 상황에 맞게 바뀌는 레이아웃 작성
사용자의 여러 장치나 상황에 맞게 레이아웃이 적절히 변경되도록 작성. 폭 넓게 보면 반응형 레이아웃을 작성하는 것이다.
8. 비표준 대화형 엘리먼트에 대한 의미 제공
WAI-ARIA를 사용하여 아코디언과 같은 커스텀 버튼과 같은 커스텀 위젯의 기능 및 상태에 대한 정보를 제공한다.
아래는 아코디언과 같은 버튼을 구현할때의 예시이다. HTML 코드가 온전히 작성하려면 추가적인 JavaScript나 CSS코드가 필요하다. (아코디언이 접히거나 펴질때때, 키보드 이벤트에 반응할때 등)
<nav aria-label="Main Navigation" role="navigation">
<ul>
<li><a href="...">Home</a></li>
<li><a href="...">Shop</a></li>
<li class="has-submenu">
<a aria-expanded="false" aria-haspopup="true" href="...">SpaceBears</a>
<ul>
<li><a href="...">SpaceBear 6</a></li>
<li><a href="...">SpaceBear 6 Plus</a></li>
</ul>
</li>
<li><a href="...">MarsCars</a></li>
<li><a href="...">Contact</a></li>
</ul>
</nav>
9. 모든 대화형 엘리먼트가 키보드로 접근 가능한지 확인
키보드 액세스는 메뉴, 마우스 오버 정보, 접혔다 펴지는 아코디언 또는 미디어 플레이어와 같은 대화형 요소를 개발할 때 꼭 고려해야 한다. tabindex=0
을 사용하여 일반적으로 포커스를 받지 않는 엘리먼트 (일반적으로 <div>나 <span>
)을 상호작용에 사용할 때 포커스를 받도록 순서에 추가한다. 온전하게 동작하게 하기 위해서는 JavaScript 코드가 필요하다.
10. <button>
과 <a>
현재 페이지에서 상호작용 작업을 하는 모든 곳에 <button>
을 사용한다.
다른 페이지로 이동하는 상호작용을 하는 곳에 <a>
를 사용한다.
<a>
의 경우 별 문제가 없지만 <button>
의 경우 하고자 하는 것에 대해 구현하기가 힘든 경우가 있다. <button>
은 기본적으로 인라인 엘리먼트 이므로 태그 안에 <p>
<div>
등의 블록 수준 엘리먼트를 사용할 수가 없다. 가령 버튼 내부에 텍스트, 이미지, 또 다른 버튼등이 중첩되어 있는 엘리먼트를 만들기 위해선 어떻게 해야할까? 구현하고자 하는데 적절한 시멘틱 태그가 없다면?
두 경우 모두 커스텀 컨트롤을 작성해야 한다. 중요한 접근성 원칙은 커스텀 컨트롤에 역할과 이름이 필요하다는 것이다.
HTML는 글로벌 속성중 name
이라는 속성이 있다. 이 name
은 컴퓨터가 읽기 위한 값이며 보통 데이터가 제출될 때 키값으로 사용된다. 이 이름은 사용자에게 도움이 되지 않는다. 즉, 접근성 기술이 아닌 것이다.
접근 가능한 이름을 지정하려면 aria-label
속성을 사용해야 한다. 위에서 얘기한 아코디언 버튼을 하나 만든다고 가정하면 아래처럼 작성할 수 있다.
<div role="button" aria-label="Open Arcodian">아코디언 버튼!</div>
role="button"
을 통해 div
에 구조와 의미를 부여하고 aria-label="Open Arcodian"
으로 접근 가능한 이름을 부여했다. 아코디언은 처음에 접혀있으므로 다음 속성을 통해 접힘 상태에 접근 가능하게 할 수 있다.
<div role="button" aria-label="Open Arcodian" aria-expanded="false">
아코디언 버튼!
</div>
아래처럼 아이콘이 이미지가 아닌 폰트인 경우
<i class="navbarIcon" role="img" aria-hidden="true"></i>
이미지 역할을 하지만 접근성 API에는 노출되지 않도록 aria-hiddn="true"
를 사용했다. 이런 경우 아이콘 밑에 텍스트 캡션이 있어야 함을 잊지 말자.
이외에도 aria-
속성은 굉장히 많으니 접근성에 대해 깊이 공부중이라면 아래 URL로 들어가 참조해보자.
MDN - ARIA states and properties
11. 색상이 유일한 시각적 지표가 되어서는 안됨
색맹, 색약 등의 시각적 장애가 있는 사용자에게는 의도한 색상대로 보이지 않을 것이므로 색상이 유일한 시각적 지표가 되선 안된다.
12. outline을 제거하지 말것
무엇을 하든 outline을 제거하지 말것. 아래의 CSS 한줄은 수많은 접근성을 해치고 있다.
outline: 0;
대부분의 브라우저는 outline 속성을 사용하여 대화형 요소의 시각적 포커스를 표시한다. 두 가지 선택지가 있다. 그대로 두거나 브라우저의 기본 스타일이 싫다면 커스텀 하자. 제거하는 것은 옵션이 아니다.
13. autocomplete 속성
몇몇 폼 컨트롤 엘리먼트에는 autocomplete
속성을 사용할 수 있는데 이것은 모든 사람에게 편리하다. 이것은 운동 장애나 인지 장애가 있는 사용자에게 매우 유용하다. 이들이 양식을 작성하는 것은 어려울 수 있으며 autocomplete
속성은 종종 도움의 손길을 제공한다. 요새의 브라우저는 매우똑똑하게 양식을 자동으로 채워주므로 사용하지 않을 이유가 거의 없다.
그 외 추가적으로 읽어보면 좋은 내용
접근성 랜드마크