# 3. Accessibility

웹 개발자로서 '웹사이트에 차별없이 접근할 수 있도록' 웹 접근성을 고려해야 한다. 웹을 사용할 때 사용하는 서로 다른 도구들을 고려하여 가능한 한 많은 사람이 웹과 상호작용하는 데 일관된 경험을 제공할 수 있어야 한다. 웹 접근성을 제공하지 일관되게 제공하지 않는 것은 휠체어로 인해 물리적인 건물에 접근하지 못하는 것과 같다.

일부 국가에서는 접근성을 법으로 지정하고 있으며, 서비스 사용이나 제품 구매가 불가능했던 사람들을 중요한 서비스 소비자로 만들수 있다.

시각장애인을 위해 많은 브라우저와 소프트웨어에서 화면 확대경, 스크린 리더기 등을 제공한다. 청각장애의 경우 컴퓨터와 웹을 사용하기에 특화된 특별한 장치는 없다. 그러나 비디오와 함께 표시할 수 있는 대본이나, 오디오 컨텐츠에 대해 대체 텍스트를 제공하기 위해 염두할 수 있는 기술들이 있다. 세계 보건 기구의 자료에 따르면, 전 세계적으로 3억 6천만 명의 사람들이 청각 장애를 가지고 있다.

거동이 불편한 장애의 경우 마우스를 사용하기 위한 동작과 같이 컴퓨터와 상호작용하는 데 필요한 동작을 수행하는 데 제한될 수 있다. 마우스가 없는 하드웨어 제한으로 인해 발생하는 경우도 포함되는데, 이 경우 키보드로서 컨트롤을 수행할 수 있어야 한다는 요구 사항의 근간이다.

인지 장애는 가장 광범위하다. 인지 장애의 경우 정신 질환에서 학습 장애까지 다양한 장애를 광범위하게 포함하고 있는데, ADHD, 이해와 집중의 어려움, 자폐증 환자, 정신분열증 등이 포함된다. 이 경우 웹 사이트 접근 목적을 달성하기에 어려움을 겪을 수 있다. 해당 장애의 경우 다른 접근성 문제와는 달리 빠르게 수정하고 해결 방안을 찾기가 어려운 입장이다. 따라서 웹사이트를 최대한 논리적이고 일관되며 사용 가능하도록 디자인하는 것이 중요하다.

* 페이지는 일관되어야 한다. navigation, header, footer, main content는 항상 일반적인 같은 위치에 존재해야 한다.
* 여러 단계로 진행되는 프로세스의 경우, 해당 프로세스가 얼마나 진행되었는지, 얼마나 남았는지 정기적이고 논리적이게 세분화하여 상기시켜 주어야 한다.
* 사용자가 진행해야 하는 워크플로우는 논리적이고 단순해야 하며, 가능한 적은 상호 작용이 필요하다.
* 페이지에서 보여지는 정보가 지나치게 길거나, 밀집되지 않아야 한다.
* 가능한 한 평범하고 따라하기 쉬운 언어를 사용해야 한다. 불필요한 전문 용어와 속어는 지양해야 한다.
* 중요한 포인트나 내용은 강조되어야 한다.
* 사용자 에러는 명확하게 강조하며, 제안하는 해결 방안을 제공한다.

### Accessibility guidelines and the law

접근성 테스트의 기반으로 수많은 체크리스트와 가이드라인이 있어 언뜻 보면 과한 부담이 될 수 있다. 하지만, 가이드라인의 높은 수준에서 가이드라인의 구조를 이해하고, 챙겨야 하는 기본 영역이라는 점을 상기하고 익숙해질 필요가 있다.

* W3C에서 접근성 적합성에 대한 기술에 구애받지 않는 기준을 포함하는 크고 상세한 문서를 제공한다. ([WCAG](https://developer.mozilla.org/ko/docs/Learn/Accessibility))
  * 인식, 작동, 이해, 견고하게 만드는 법을 지정하고 문서화되어 있다.
* 각 국가에서 서비스를 제공하는 웹사이드의 접근성을 규제하는 특정 법률이 재정되어 있을 수 있다. ([예시](https://news.seoul.go.kr/gov/archives/47485))

컨텐츠에 접근하고자 하는 사용자를 위해 노력하지 않았을 때 불평등한 컨텐츠 접근성으로 인해 법적인 문제가 발생할 수 있기 때문에 실제로 웹 접근성은 웹 개발에 있어 주요 우선 순위 관행으로 고려해야 한다.

### Accessibility APIs

웹 브라우저는 보조 기술을 활용한 특별한 접근성 API를 사용하는데, 보조 기술은 주로 의미론적인 정보에 접근하여 사용하기 때문에 스타일이나 자바스크립트는 항목에서 제외된다. 이 정보는 접근성 트리라고 하는 정보 트리로 구성되어 보조 기술에게 제공된다. 웹의 시멘틱 정보가 부족한 경우, WAI-ARIA 기능을 통해 이를 보완할 수 있다.

### A good basis for accessibility

올바른 목적을 가지고 HTML 요소를 사용하는 것만으로도, 웹 컨텐츠의 접근성 향상에 큰 도움이 된다. 올바른 목적은 의미론적 HTML 요소를 적절한 의미를 표현해낼 수 있도록, 즉 제 역할을 할 수 있도록 개발자로서 신경써주어야 한다는 의미이다.

버튼을 만들고자 한다면, 충분히 `div` 태그를 통해 구현할 수 있지만, 기본적인 스타일링을 제공하고, 키보드 접근성 또한 내제되어 제공하고 있는 `button` 태그를 사용하는 것이 좋다는 것을 알 수 있다.

```html
<div onclick="...">Go</div>
<button onclick="...">Go</button>
```

시멘틱 태그는 시멘틱하지 않은 태그를 사용하는 것보다 개발이 오래 걸리는 것도 아니다. 오히려 개발 속도를 더 증진시켜 주는데,

* 의미를 내포하고 있는 시멘틱 태그는 가독성에 좋으며, 해당 역할을 담당하기에 필요한 일반적인 기능을 제공한다.
* 모바일 친화적인 태그로서 반응형 구현에 용이하다.
* 검색엔진에게 보다 중요한 키워드를 제공하여 사용자로 하여금 찾기 쉽도록 한다.

#### Text Content

좋은 컨텐츠 구조를 제공하는 것은 스크린 리더 사용자가 가질 수 있는 최고의 접근성을 제공할 수 있다.

```html
<h1>여행갈 수 있을까</h1>
<p>여행을 떠날 수 있을까 고민만 많아지는 저의 이야기입니다.</p>
<p>주절주절 이야기가 길어질 수 있어요.</p>

<ol>
  <li>여행</li>
  <li>여행가고 싶은 나</li>
  <li>내일 출근하는 나</li>>
</ol>>

<h2>여행</h2>

<p>여행은 일상의 사이클에서 잠시 벗어나는데 큰 도움이 됩니다.</p>
```

#### Using clear language

명확한 언어로서 컨텐츠를 표현해해는 것이 중요하다. 불필요한 전문 용어나 속어를 사용하는 것을 피하자. 이는 스크린 리더가 잘 읽어낼 수 있는 컨텐츠를 제공할 수 있다.

* 5-7 대신 5에서 7
* Jan 대신 January
* 줄임말을 사용하고자 한다면, 최소 한번에서 두번 원어를 언급하자.

#### Page layouts

과거 테이블 태그를 통해 레이아웃을 구성하던 나쁜 습관을 가진 개발자들이 있었다고 한다. 테이블을 통해 해더, 푸터, 메인 컨텐츠를 표현하곤 했는데, 이것은 좋은 아이디어가 아니다. 시멘틱 태그로서 스크린 리더가 레이아웃을 판독하고, 컨텐츠를 발췌하는 데 도움을 주어야 한다.

```html
<header>
  <h1>Header</h1>
</header>

<nav>
  <!-- main navigation in here -->
</nav>

<!-- Here is our page's main content -->
<main>

  <!-- It contains an article -->
  <article>
    <h2>Article heading</h2>

    <!-- article content in here -->
  </article>

  <aside>
    <h2>Related</h2>

    <!-- aside content in here -->
  </aside>

</main>

<!-- And here is our main footer that is used across all the pages of our website -->

<footer>
  <!-- footer content in here -->
</footer>
```

### Reference

* <https://developer.mozilla.org/ko/docs/Learn/Accessibility>

<details>

<summary>Give feedback</summary>

</details>

\\
