웹 접근성(Accessibility)

이미지 출처 : https://blog.interactiveschools.com/

1. 웹 접근성

웹 접근성이란 웹사이트 및 웹과 관련한 도구나 기술들이 장애나 불편함을 가진 사람들이 쉽게 쓸 수 있는 방법으로 디자인되고 개발된 것을 이야기 합니다.

웹 접근성을 위해 고려해야하는 장애나 불편함은 인지장애와 같은 정신적 불편함부터, 팔을 쓸 수 없거나 시력이 없거나 저하된 신체적 불편함은 물론, 아이를 한 손에 업고 있어서 한 쪽 팔만 사용할 수 있다던가 하는 일시적인 불편함을 모두 포함합니다.

인터넷의 아버지라 불리는 Vint Cerf는 “인터넷은 모두를 위한 것이지만, 우리가 그렇게 만들지 않으면 인터넷은 그렇지 않을 것입니다.”라고 말했습니다. 팔의 사용이 불편한 사람들, 청각이나 시각이 불편한 사람들, 사용하는 언어가 다른 사람들 모두가 웹 사이트와 앱을 접근하고 사용할 수 있어야 합니다. 웹 기술에는 접근성을 위한 많은 기능들이 있으며, 우리 웹 개발자들은 이러한 기능들을 알고 있어야 특정 사용자를 배척하지 않을 수 있습니다.

웹 접근성을 향상시키기 위한 방법들은 주로 Semantic Web, 반응형 웹과 깊은 연관이 있으니 이에 대한 이해를 먼저 하고 접근성을 알아본다면 더 효과적일 수 있습니다.

"Semantic HTML 작성하기" 글 보러 가기 -> https://dong-x2.tistory.com/16

Semantic HTML 작성하기

1. Semantic(시맨틱) 이란? 시맨틱이란 단어의 뜻을 전반적으로 우리 말로 나타내자면 코드 조각에 내포된 의미라고 볼 수 있습니다. 예를 들어 Javascript의 경우, 특정 라인의 JS가 실행됐을 때 어떤

dong-x2.tistory.com

2. WCAG(Web Content Accessibility Guidelines)

W3C 웹 콘텐츠 접근성 가이드라인 표준 권고안이라고 부르며, 웹 표준을 제시하는 W3C에서 웹 사이트 및 웹 어플리케이션에서 충족해야 하는 기준을 정의해 다양한 사용자가 해당 웹 서비스를 쉽게 이용할 수 있도록 준수해야 하는 지침으로, 웹 서비스를 제작하는 사람들이 기획/디자인/개발 과정에서 고려해야 할 지침입니다.

WCAG 버전 2.0는 W3C이 2008년 발행했으며 2018년 6월에 WCAG 2.1로 업데이트되었습니다. 2012년 WCAG 2.0은 또한 국제 표준화 기구(ISO)가 ISO/IEC 40500:2012로 발행하기도 했습니다.

WCAG 2.0과 WCAG 2.1에 대해서는 한국어 번역 또한 아래 페이지에서 제공하고 있으니 참고하시면 좋을 것 같습니다.

http://www.kwacc.or.kr/WAI/wcag21/

WCAG 2.1 Korean Translation Version

접근성 지침 실무그룹(Accessibility Guidelines Working Group: AG WG) 참여에 대한 추가 정보는 실무그룹 홈 페이지에서 찾을 수 있다. A.2 다른 이전에 적극적인 WCAG WG 참가자와 WCAG 2.0, WCAG 2.1 또는 지원 자

www.kwacc.or.kr

3. W3C WAI(Web Accessibility Initiative) 가이드라인

W3C WAI(Web Accessibility Initiative)에서는 WCAG와 연관된 세부적인 HTML 문서 작성 지침을 소개하고 있는데 여기서 이에 대해 한 번 알아보겠습니다.

3-1. 모든 Form control에 <label>을 이용해 라벨링하십시오.

<label>의 for 속성을 이용해 form 요소의 id와 연결하여 form의 각 요소 대한 설명을 충분히 제공해야 합니다.

추가적인 설명을 제공하는 방법은 <label>뿐만 아니라 aria-label, <legend>등을 사용할 수도 있습니다.

WCAG Labels or Instructions 3.3.2 ( https://www.w3.org/WAI/WCAG21/quickref/#labels-or-instructions )에서 참고할 수 있는 내용입니다.

3-2. 모든 정보전달 및 기능적인 이미지에는 대체 텍스트를 포함하십시오.

HTML 문서에 포함될 수 있는 이미지에는 장식적인 이미지와 정보전달 혹은 기능적으로 중요한 이미지가 있습니다. 이 때 후자의 경우는 alt 속성을 통해 이미지를 볼 수 없는 사용자 및 상황에 대해 충분한 정보를 제공해야 합니다.

WCAG Non-text Content 1.1.1 ( https://www.w3.org/WAI/WCAG21/quickref/#non-text-content )에서 참고할 수 있는 내용입니다.

3-3. <html> 태그의 lang 속성을 이용해서 모든 페이지에 주 언어를 명시하십시오.

사용자는 웹 브라우저를 통해 웹 페이지에 접근할 때, lang 속성이 명시된 페이지를 만나면 브라우저를 통해 자동으로 해당 페이지의 주 언어를 인식하고 번역 기능을 제공받을 수 있습니다.

WCAG Language of Page 3.1.1 ( https://www.w3.org/WAI/WCAG21/quickref/#language-of-page )과 WCAG Language of Page 3.1.2 ( https://www.w3.org/WAI/WCAG21/quickref/#language-of-parts )에서 참고할 수 있는 내용입니다.

3-4. HTML5가 제공하는 시맨틱한 요소들을 사용해서 HTML 문서를 시맨틱하게 마크업하십시오.

시맨틱한 요소는 의미를 가진 요소라고 볼 수 있습니다. 110개의 HTML5요소중, <div>와 <span> 요소는 의미를 가지지 않습니다. 태그 자체만으로 설명할 수 있는게 아무것도 없다는 것이죠.

태그가 시맨틱한 태그라고 하더라도 오용해서는 안됩니다. 예를 들어 페이지 전환 버튼에 <button>태그를 쓰는 경우가 있는데 이는 이 지침에 어긋납니다. 페이지의 전환이 있다면 <a>태그를, 현재 페이지에서의 인터렉션은 <button>요소를 사용하는 것이 더 시맨틱하다고 할 수 있습니다. 버튼처럼 생긴 <a>태그 등, 스타일링은 상관없습니다. 역할이 중요합니다.

WCAG Info and Relationships 1.3.1 ( https://www.w3.org/WAI/WCAG21/quickref/#info-and-relationships )에서 참고할 수 있는 내용입니다.

3-5. 사용자가 form을 작성할 때, 충분한 지시사항과 에러 메시지, 알림을 제공하십시오.

사용자가 form 입력 중 문제가 일어난다면, 첫 번째로 어디에서 어떤 문제가 일어났는지 알려주고, 두 번째로 명확하고 알기 쉬운 설명을 제공하고, 세 번째로 수정 방법을 제안해야 합니다.

아래 form 예시 코드에서 사용자가 어떤 문제를 겪을 수 있고 어떻게 이 지침을 따라 안내를 제공할 수 있을지 생각해보세요.

<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel" pattern="^(\(?0[1-9]{1}\)?)?[0-9 -]*$" aria-describedby="phone-desc">
<p id="phone-desc">For example, (02) 1234 1234</p>

WCAG Error Identifications 3.3.1 ( https://www.w3.org/WAI/WCAG21/quickref/#error-identification )에서 참고할 수 있는 내용입니다.

3-6. 화면에 정보가 표시되는 순서와 코드에서 나타나는 요소들의 순서가 일치하도록 해야합니다.

코드상에서 위에서부터 아래 순서 그대로 최대한 화면에도 레이아웃이 펼쳐지는 것이 가장 좋습니다. 이를 위해선 CSS 스타일링을 모두 제거하고 나서 확인해보는 것 또한 좋은 방법입니다.

WCAG Meaningful Sequence 1.3.2 ( https://www.w3.org/WAI/WCAG21/quickref/#meaningful-sequence )에서 참고할 수 있는 내용입니다.

3-7. 유저의 기기나 기술 등에 적응할 수 있는 코드를 작성해야 합니다.

모바일 기기나 태블릿 등 여러 다른 뷰포트 사이즈와 다른 줌 상태에서 모두 잘 나타날 수 있는 반응형 디자인을 사용해야합니다. 폰트 사이즈가 최소 200%로 증가했을 때, 수평 스크롤이 없어야 하고 잘리는 콘텐츠가 있으면 안됩니다.

유저의 어떠한 기기나 기술에 의해 사용되고 있든 주요 기능과 내용들이 온전해야 합니다.

WCAG Resize text 1.4.4 ( https://www.w3.org/WAI/WCAG21/quickref/#resize-text )과 WCAG Consistent Identification 3.2.4 ( https://www.w3.org/WAI/WCAG21/quickref/#consistent-identification )에서 참고할 수 있는 내용입니다.

3-8. 비표준적인 상호작용을 위한 요소에는 의미를 제공해야 합니다.

커스텀 버튼이나 아코디언 등 커스텀 위젯에는 기능과 상태에 대한 정보를 WAI-ARIA를 사용해서 제공해야합니다.

아래 예시 코드에서 aria-* 속성을 통해 나타낸 것들과 같은 정보를 참고하세요.

<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>

WCAG Name, Role, Value 4.1.2 ( https://www.w3.org/WAI/WCAG21/quickref/#name-role-value )에서 참고할 수 있는 내용입니다.

3-9. 모든 상호작용을 위한 요소에 키보드가 접근가능하도록 해야합니다.

여러 이유에서 키보드만으로 웹 페이지를 탐색할 수 밖에 없는 상황이나 사용자가 있을 수 있습니다.

이에 메뉴, 마우스 오버 정보, 아코디언, 동영상 플레이어 같은 상호작용 요소를 개발할 때, <div>나 <span>처럼 보통 포커스를 받지 않는 요소를 tabIndex=“0” 을 통해 추가해야 합니다. 그리고 나서 키보드 이벤트를 감지하고 대응하기 위해선 스크립트를 사용합니다.

var buttonExample = document.getElementById('example-button');

buttonExample.addEventListener('keydown', function(e) {
  // Toggle the menu when RETURN is pressed
  if(e.keyCode && e.keyCode == 13) {
    toggleMenu(document.getElementById('example-button-menu'));
  }
});

buttonExample.addEventListener('click', function(e) {
// Toggle the menu on mouse click
  toggleMenu(document.getElementById('example-button-menu'));
});

WCAG Keyboard 2.1.1 ( https://www.w3.org/WAI/WCAG21/quickref/#keyboard )에서 참고할 수 있는 내용입니다.

3-10. 가능하면 CAPTCHA 사용을 피해야 합니다.

CAPTCHA를 써야한다면 다음과 같은 대안이 있습니다.

CAPTCHA를 통과할 수 있는 두 개 이상의 방법을 제공한다.
CAPTCHA를 우회할 수 있는 담당자에게의 접근을 제공한다.
인증된 사용자에겐 CAPTCHA를 활성화하지 않는다.

WCAG Non-text Content 1.1.1 ( https://www.w3.org/WAI/WCAG21/quickref/#non-text-content )에서 참고할 수 있는 내용입니다.

이외에도 많은 가이드라인이 있습니다.

4. W3C에서 추가적으로 제공하는 가이드라인

W3C에서 추가적으로 제공하는 세부적인 가이드 라인이 있는데 아래에서 간단히 정리해봤습니다. 예시별로 한 번 살펴보시면 더 이해가 쉬울 것 같습니다.

4-1. Semantic HTML 요소를 사용하기 힘든 경우

목적을 달성하기 위한 적절한 Semantic HTML 요소가 존재하지 않거나, 사용중인 라이브러리의 제약 등으로 현재 존재하는 Semantic HTML 요소로 구현하기엔 기술적인 어려움이 있는 경우, role, name, value 등의 속성을 적절히 활용하여 웹 브라우저 뿐만 아닌 스크린 리더 등의 보조적인 도구들이 그것을 이용할 수 있도록 커스텀해야 합니다.

단, 이미 적절한 Semantic 요소를 사용할 수 있는 경우 라면 그런 것들을 굳이 사용할 필요는 없습니다!

예를 들어 a태그의 role로 button을 지정한다던지, role에는 대체할 수 있는 semantic한 요소의 이름을 적습니다.

이 때, name은 컴퓨터가 읽을 수 있는 속성값으로, aria-label은 사람이 읽을 수 있는 속성값으로 지정합시다.

4-2. 디자인에서 명확한 대비를 사용해 시력 저하자나 햇빛 아래에서의 사용자 같은 유저 경험을 고려해야 합니다.

명암비에 대한 절대적인 가이드라인은 없지만 Apple에선 최소 7 정도가 선호되며, 못해도 4.5 이상이 되도록 해야합니다.

명암비를 판단하기 위해 좋은 사이트를 하나 제시해드리겠습니다. -> https://contrast-ratio.com/

Contrast Ratio: Easily calculate color contrast ratios. Passing WCAG was never this easy!

How to use As you type, the contrast ratio indicated will update. Hover over the circle to get more detailed information. When semi-transparent colors are involved as backgrounds, the contrast ratio will have an error margin, to account for the different c

contrast-ratio.com

이미지위에 텍스트가 올라갈 경우 이미지의 가장 밝은 부분과 텍스트의 가장 밝은 부분, 이미지의 가장 어두운 부분과 텍스트의 가장 어두운 부분을 비교해야 합니다.

Hover color effect과 같은 부분에서도 이를 고려해 컬러를 지정하는 것이 좋습니다.

4-3. 색상이 시각 요소의 전부가 아닙니다.

예를 들어 밑줄이나 경계선 없이 링크 스타일을 지정하는 경우 등, 색맹 혹은 그레이스케일 모드 사용자들을 위해 색상을 모든 시각적인 표시 요소로 생각하면 안됩니다.

4-4. 스크린 리더는 장식을 위한 이미지를 무시한다는 점을 고려하십시오.

장식을 위한 이미지와 기능 혹은 정보를 위한 이미지의 구분을 명확히 해야합니다. 제거해도 사용에 지장이 없다면 장식을 위한 이미지입니다.

장식을 위한 이미지에는 alt속성을 빈 값("")으로 설정하거나, CSS의 background-image 속성을 사용하거나, 태그의 aria-hidden=“true" 속성을 설정할 수 있습니다.

의미 있는 이미지에 대한 설명(alt 속성 사용)을 위해서는 친구에게 그 이미지에 대해 전화로 어떻게 설명할 수 있을지 생각해보세요.

아이콘이 유일한 버튼 요소인 경우 아이콘의 모양이 아닌 해당 버튼의 기능을 설명해야합니다.

4-5. 링크 상태 관련

단기기억상실이나 근육 사용의 문제가 있는 사람들을 위해 링크의 '미방문, 기방문, Hover, 활성, Focus' 상태를 잘 구분하도록 해야합니다. 이 때 또한 명암비 등의 요소를 고려해야합니다.

4-6. .sr-only

.sr-only 라는 CSS 속성을 사용해 스크린리더에게만 표시되는 콘텐츠를 설정할 수 있습니다.

4-7. 자동완성 기능을 적극 활용하십시오.

자동완성을 활용해 사용자들이 브라우저 등과 함께 Form을 더 쉽게 입력할 수 있도록 해야합니다. autocomplete 속성을 사용해 브라우저에 저장된 값으로 자동완성이 가능합니다.

4-8. 에러표시 원칙

글로 설명한다.
에러가 생긴 부분과 에러 메시지를 가깝게 위치시킨다.
주어지는 정보가 많을수록 좋다.
스크린리더를 위해 aria-invalid, aria-describedby 등의 속성을 적절히 활용
포커스를 이동시킨다.

4-9. 고정 크기 사용 지양

폰트 크기는 고정 px이 아닌 rem 사용, line-height 또한 고정 px이 아닌 배수 실수 사용, height 스타일 속성 지양을 통해 고정 크기 사용을 지양해야 여러 뷰포트 및 줌 상태에 대응할 수 있습니다.

이와 일맥상통하는 이야기로, 그래픽 요소엔 크기가 고정된 PNG보단 동적일 수 있는 SVG를 사용하는 것이 좋습니다.

5. 추가적으로 살펴보면 좋은 콘텐츠

https://web.dev/accessibility/

Accessibility

Improving accessibility for web pages

web.dev

https://developer.mozilla.org/en-US/docs/Web/Accessibility

Accessibility | MDN

Accessibility (often abbreviated to A11y — as in, "a", then 11 characters, and then "y") in web development means enabling as many people as possible to use websites, even when those people's abilities are limited in some way.

developer.mozilla.org

https://www.smashingmagazine.com/2021/03/complete-guide-accessible-front-end-components/

A Complete Guide To Accessible Front-End Components — Smashing Magazine

An up-to-date collection of accessible front-end components: accordions, form styles, dark mode, data charts, date pickers, form styles, navigation menu, modals, radio buttons, "skip" links, SVGs, tabs, tables, toggles and tooltips.

www.smashingmagazine.com

저작자표시 비영리 변경금지

'HTML' 카테고리의 다른 글

WAI-ARIA 란 무엇인가 (0)	2023.03.28
검색엔진최적화(SEO) 기초 (0)	2023.03.27
HTML Best Practice (0)	2023.03.20
HTML Forms (0)	2022.12.13
Semantic HTML 작성하기 (0)	2022.10.31