WCAG 규정 준수에 대한 접근성 감사를 수행하는 방법

WCAG(웹 콘텐츠 접근성 지침)는 W3C(월드 와이드 웹 컨소시엄)에서 만든 것으로 접근성에 대해 전 세계적으로 가장 인정받는 표준입니다.

이 기사에서는 WCAG 2.1 표준 준수를 확인하기 위해 감사를 수행하는 데 필요한 작업을 간략하게 설명합니다.

접근성은 더 많은 사람들이 웹사이트 콘텐츠와 기능에 액세스할 수 있도록 하는 것입니다.

예를 들어:

• 임시 접근성 장벽 – 누군가 안경을 분실했습니다!
• 장치 문제 - 휴대전화와 같이 제한적인 장치에 있습니다.
• 상황 - 밝은 햇빛, 어두운 방 등
• 영구 장애 – 시력, 청력, 인지 문제 등
• 대역폭 문제 – 매우 느린 연결

보시다시피 고려해야 할 장애의 형태는 많습니다.

WCAG 지침은 다음과 같이 분류됩니다.

각 섹션을 진행하기 전에 테스트를 수행하는 데 필요한 목록이 있습니다.

1. 인지 가능한

• 텍스트만 포함하는 브라우저 선택(예: Lynx)
• 대체 태그, 제목 등을 확인하기 위한 도구(예: ScreamingFrog)
• NVDA와 같은 스크린 리더
• 웹사이트 접근성 테스트 도구
• 크롬 개발 도구
• 기기 선택에 대한 액세스

다양한 형태로 콘텐츠에 접근할 수 있도록 하는 것입니다. 예를 들어, 누군가는 콘텐츠를 보고, 듣고, 터치를 사용하여 콘텐츠를 이해할 수 있습니다. 여기에는 메뉴 및 버튼과 같은 사용자 인터페이스 항목도 포함됩니다.

WAVE 접근성 도구는 이 영역에서 문제를 찾는 데 사용할 수 있는 많은 도구 중 하나입니다.

위의 예에서 페이지는 꽤 잘 작동합니다. 색상 대비 문제가 있는 1개의 오류와 5개의 오류만 있습니다.

한 가지 오류는 이 페이지에 언어가 표시되어 있지 않다는 것입니다.

그러나 페이지에는 좋은 것들이 많이 있습니다. 예를 들어 오른쪽 이미지에서 녹색으로 강조 표시된 2개의 요소가 모두 'ARIA' 레이블을 사용하여 스크린 리더가 이 콘텐츠를 이해할 수 있도록 합니다. 나중에 이에 대해 더 자세히 설명하겠습니다.

가이드라인과 성공 기준을 살펴보겠습니다.

지침 1.1 - 텍스트가 아닌 콘텐츠에 대한 텍스트 대안 제공

텍스트가 아닌 콘텐츠에 대한 텍스트 대안이 있습니까?

화면에 텍스트가 아닌 콘텐츠가 있는 경우 해당 요소 각각에 대한 설명이 있는지 확인해야 합니다.

예제를 제공하기 전에 요소에 추가 설명을 제공하고 표준 HTML이 불가능할 때만 사용해야 하는 ARIA에 대해 논의하고 싶습니다.

HTML을 사용하면 자동으로 키보드 제어, 포커스 등을 얻게 되며 이는 기본 설정이지만 ARIA를 백업으로 사용할 수 있습니다.

ARIA는 무엇입니까?

ARIA(Accessible Rich Internet Applications)는 표준 HTML을 사용하여 충분히 설명할 수 없는 콘텐츠를 설명하는 방법입니다. 주요 목적은 스크린 리더입니다. 표준 HTML을 사용할 수 있다면 자동으로 요소와 키보드 컨트롤에 포커스를 제공하기 때문에 이것이 가장 좋은 방법입니다. 이것이 불가능한 경우 ARIA가 대안입니다.

설명 이미지

묘사적 이미지는 어떤 의미를 묘사하는 것입니다. 예를 들어 Toyota Prius 자동차의 사진입니다.

그림을 볼 수 없다면 이 그림이 나타내는 것을 설명하는 방법이 있어야 하며 Alt 태그가 있는 위치에 있어야 합니다.

WordPress와 같은 플랫폼에서는 이미지를 업로드할 때 alt 태그를 추가할 수 있습니다.

꽤 자주 우리는 SEO 목적을 위해 관련 키워드가 포함되도록 이 alt 태그를 업데이트하지만 이 이상으로 넘어갈 필요가 있습니다.

Screaming Frog는 웹사이트의 모든 이미지를 분석하여 Alt 태그가 없는 이미지, 중복된 Alt 태그, 너무 긴 Alt 태그 또는 너무 짧은 Alt 태그를 표시합니다!

이미지의 세부 정보와 함께 이미지도 볼 수 있습니다.

장식 이미지

장식 이미지는 디자인을 돋보이게 하기 위해 존재하지만 이미지에 설명할 가치가 없는 이미지입니다!

장식 이미지는 'img' 태그를 사용해야 하는 합당한 이유가 없는 한 CSS 배경 속성을 사용해야 합니다. 스크린 리더가 CSS background 속성을 보면 이미지를 무시한다는 것을 알고 있습니다.

다음은 호주의 My Emergency Doctor 웹사이트에서 배경 이미지로 설명된 이미지의 예입니다.

다음은 이 코드 뒤에 있는 코드입니다.

이 이미지는 <img>로 나열되지 않기 때문에 role=img를 사용하여 화면 판독기에게 이것이 이미지임을 알립니다. 이미지에 대한 정확한 설명을 제공하기 위해 'Aria-label'을 사용합니다. 또한 이미지를 '배경 이미지'로 정의합니다.

참고: 배경 이미지에 'img' 태그를 사용하는 경우 null alt 태그를 정의해야 합니다(예: alt=" "

배경색 대신 <img>를 사용해야 하는 경우는 언제인가요?

이미지가 콘텐츠의 중요한 부분이라면 <img>를 사용하세요. 예를 들어, 제품 이미지가 있는 경우 이것은 <img> 입니다. 또한 장식 목적으로 사용되는 배경 이미지인 이미지를 가질 수 있으며 이러한 이미지를 이미지(Google에서 색인을 생성함)로 설명하는 것은 이치에 맞지 않습니다.

위의 예에서 표시되는 이미지가 img로 정의되어야 하는지 질문할 수 있지만 스톡 사진이고 그들은 그것을 대신 배경 이미지로 정의하기로 결정했습니다.

참고: <img>는 HTML 태그이지만 background-image는 사용하는 CSS 스타일입니다.

UI 컨트롤

그것이 무엇인지 설명하기 위해 약간의 텍스트가 필요한 다양한 UI 컨트롤이 있습니다.

예를 들어 버튼이나 양식 컨트롤이 있습니다.

버튼은 기능을 완료하는 데 사용됩니다. 아이콘만 있는 버튼과 버튼에 텍스트가 있는 버튼일 수 있습니다. 둘 다 다르게 처리될 수 있습니다.

ARIA를 사용하면 'role=button'을 정의할 수 있지만 표준 HTML에서는 <button> 태그를 사용할 수 있습니다. 어느 것을 사용해야 합니까?

다음은 버튼의 기능을 설명하기 위해 'aria-label'을 생성해야 하는 X가 있는 버튼의 예입니다.

<button aria-label="닫기" onclick="myDialog.close()">X</button>

다음은 테스트해야 하는 일반적인 UI 컨트롤 목록입니다.

양식을 사용하는 경우 각 필드에 레이블이 올바르게 지정되었는지 확인해야 합니다. 다음은 좋은 라벨링의 예입니다.

<label for="fname">이름:</label><br>

<입력 유형=”텍스트” id=”fname” 이름=”fname”><br>

<label for="lname">성:</label><br>

<입력 유형=”텍스트” id=”lname” 이름=”lname”>

</form>

참고: 양식의 경우 다음 사항도 확인해야 합니다.

• 필수 필드를 명확하게 표시하십시오. 필드가 필수인 경우 html에서 레이블도 올바르게 지정해야 합니다.
• 사용자를 위한 지침이 있습니다(일반적으로 양식 상단에 있음).
• 사용자는 양식 필드를 완성하는 동안 오류를 범할 때 도움을 받습니다(예: 잘못된 날짜 형식, 입력해야 하는 형식).

보안문자

이것은 구현 방법에 따라 매우 문제가 될 수 있습니다. 예를 들어, 사진이 표시되고 신호등이 포함된 사진을 식별하도록 요청받는 경우입니다!

구현을 검토하고 관련 제안을 드리겠습니다.

멀티미디어 콘텐츠

비디오/오디오는 비디오/오디오의 내용을 식별하기 위해 최소한 설명이 필요합니다.

연결

링크가 페이지에서 명확하게 눈에 띄는지 확인하고(예: 다른 색상) 관련 앵커 텍스트와 링크 설명을 사용하고 싶습니다.

지침 1.2 – 시간 기반 미디어

이 영역은 더 쉽게 접근할 수 있도록 해야 하는 비디오 및 오디오 콘텐츠에 대한 케이터링에 관한 것입니다.

사전 녹음된 오디오 전용 또는 비디오 전용 트랜스크립션이 있습니까?

비디오 트랜스크립션은 비디오의 오디오를 텍스트로 번역하는 것입니다. 동영상에 표시되는 영상과 같은 내용을 설명하는 오디오 정보는 전사에 포함되지 않습니다. 이것은 별도로 처리됩니다.

번역 팁!

Rev.com은 오디오/비디오에 대한 캡션/스크립트를 생성하는 훌륭한 서비스입니다. Zoom 비디오에 대한 라이브 캡션 서비스도 제공합니다.

사전 녹음된 오디오에 사용할 수 있는 캡션이 있습니까?

캡션은 사용자에게 그 사람이 말하는 내용을 알려주기 위해 비디오 내에 표시되는 텍스트입니다.

오디오 설명 또는 미디어 대안(사전 녹음)이 있습니까?

비디오를 시청할 때 캡션은 비디오에 표시되는 내용을 설명하기에 충분하지 않을 수 있습니다. 여기에 오디오 설명도 필요합니다.

예를 들어 오디오 설명은 누군가가 말할 때 배경에서 일어나는 일을 설명하여 사용자에게 약간의 컨텍스트를 제공할 수 있습니다.

다음은 오디오 설명이 포함된 전사의 예입니다.

이것은 웹사이트 방문자에게도 좋지만 SEO에도 좋습니다!

접근 가능한 플레이어 선택에 대한 팁:

사용하는 비디오 플레이어가 접근성에 필요한 것을 지원하는지 확인하고 싶습니다.

1. 자막 지원
2. 오디오 설명을 켜고 끌 수 있습니다.
3. 미디어 플레이어에서 키워드 컨트롤을 사용할 수 있습니다.
4. 미디어 플레이어는 다양한 장치와 브라우저에서 작동합니다.
5. 모든 컨트롤에 액세스할 수 있습니다.

라이브 오디오에 대한 캡션이 있습니까?

일반적으로 웹사이트에 라이브 비디오 또는 오디오 콘텐츠가 없을 것입니다. 하지만 그렇다면 동시 캡션 생성이 있어야 사용자가 말하는 대로 캡션이 표시되는 것을 볼 수 있습니다.

라이브 비디오 및 오디오에 자동으로 캡션을 지정하는 데 사용할 수 있는 도구가 있습니다.

사전 녹음된 동기화 미디어에 대한 오디오 설명이 있습니까?

이것은 비디오와 오디오가 포함된 미디어용입니다. 우리는 미디어와 함께 제공되는 오디오 정보를 원합니다.

지침 1.3 – 적응 가능 – 소프트웨어가 이해할 수 있는 형식으로 정보를 제공합니다.

화면 판독기와 같은 소프트웨어에서 올바르게 해석할 수 있도록 무언가를 보고 시각적으로 해석할 수 있는 내용이 프로그래밍 방식으로 설명되어 있는지 확인해야 합니다.

콘텐츠에 논리적 구조가 있고 그 구조 내에서 각 콘텐츠의 관계를 이해하기 쉽습니까?

웹 페이지를 볼 때 일반적으로 제목, 단락, 굵게 표시된 내용, 표 등이 표시됩니다. 표의 세부 정보를 볼 때 제목이 표시되고 어떤 행이 어떤 제목과 관련이 있는지 명확하게 알 수 있습니다.

검토해야 할 사항은 다음과 같습니다.

• 콘텐츠가 하위 제목으로 분류되어 있습니까?
• 적절한 경우 목록, 표 등이 사용됩니까?
• 콘텐츠 전체에 걸쳐 다른 구조적 요소에 올바른 HTML이 사용되었습니까?
• 필요에 따라 레이블과 대체 텍스트가 사용됩니까(예: 양식에?)

팁

좋은 출발점은 유효한 html(예: W3.org html 유효성 검사기)을 확인하는 검사기 도구를 사용하여 웹사이트를 테스트하는 것입니다.

다음은 필수 필드를 빨간색으로 표시하는 양식의 예입니다. 이것은 시각적 사용자에게는 괜찮지만 점자 디스플레이를 사용하는 사람은 어떻습니까?

이 문제를 해결하기 위해 '필수'라는 단어가 필수 필드인 성의 레이블에도 추가됩니다.

 <label for="lastname" class="required">성(필수): </label>
<입력 유형="텍스트" 크기="25" 값=""/>
<스타일 유형="텍스트/css">
  .필수의 {
    색상:빨간색;
  }
</스타일>

의미 있는 콘텐츠 순서가 있습니까?

• 웹 페이지를 볼 때 탐색 모음이 표시된 다음 일부 콘텐츠, 제목, 하위 제목, 텍스트 단락이 표시됩니다. 이것이 의미 있는 순서로 제시되었는지 확인하고 싶을 것입니다.
• 제목 스타일을 사용하여 섹션의 중요성을 나타냅니다. 일반적으로 콘텐츠 페이지를 식별하기 위해 <h1> 스타일이 하나만 있고 H2, H3 등이 여러 개 있을 수 있습니다.
• 탐색을 콘텐츠와 분리합니다(예: <nav>를 사용하여 탐색 정의).
• 유효한 html 사용

다음은 의미 있는 표제의 일반적인 구조입니다.

사용자가 모양, 크기를 인지하지 못하거나 공간 모양 또는 크기에 대한 정보를 사용할 수 없는 경우 콘텐츠를 이해할 수 있습니까?

이것을 설명하는 가장 쉬운 방법은 예를 들면 다음과 같습니다.

소프트웨어 제품 기능의 비교 테이블이 있고 제품에 기능이 있는 경우 이 열에 다이아몬드 이미지가 표시된다고 가정해 보겠습니다. 이것으로 충분하지 않습니다. 이 다이아몬드가 나타내는 내용을 나타내는 텍스트를 추가해야 합니다.

웹사이트가 세로 및 가로 모드에서 잘 작동합니까?

웹사이트는 의미를 잃지 않고 세로 또는 가로 모드에 적응할 수 있어야 합니다.

웹사이트가 반응형 디자인을 올바르게 구현했다면 방향을 변경할 때 다른 뷰포트에 맞게 조정됩니다(즉, 화면 크기에 따라 더 적합한 디스플레이 선택).

양식에 대한 입력이 올바르게 설명되어 있습니까?

이것의 목적은 프로그래밍 방식으로 양식에서 완료해야 하는 필드에 대한 충분한 정보가 있는지 확인하는 것입니다.

그리고 가능하다면 사용자가 모든 것을 완료할 필요가 없도록 자동 채우기를 활성화하십시오!

페이지에 있는 요소의 목적을 프로그래밍 방식으로 파악할 수 있습니까?

이에 대한 예는 웹사이트 섹션에 ARIA 'role' 요소를 사용하는 것입니다.

예를 들어 로고/회사 이름 등이 포함된 배너는 'role=banner'로 설명할 수 있습니다.

또는 이메일, 이름, 주소 등의 양식에 입력 레이블을 사용합니다.

이것은 HTML에서 볼 수 있는 방법입니다.

<입력 유형=”이메일>

그래프의 텍스트 버전이 있습니까?

그래프 유형 콘텐츠가 있는 경우 이 콘텐츠의 내용을 요약한 표가 필요합니다.

지침 1.4 – 콘텐츠 보기 및 듣기

이것은 사람들이 콘텐츠를 보고 듣기 쉽게 하기 위한 것입니다.

정보를 전달하기 위해 색상을 사용할 때 대체 텍스트가 있습니까?

양식이 있고 필수 필드가 빨간색으로 표시되어 있다고 상상해 보십시오.

이것은 스크린 리더에게 큰 의미가 없습니다!

그러나 아래 예와 같이 '필수'라는 단어를 테이블에 추가할 수 있습니다.

<label for=”lastname” class=”required”>성(필수): </label> <input id=”lastname” type=”text” size=”25″ value=””/> <style type= ”텍스트/css”> .required { 색상:빨간색; } </스타일>

오디오가 3초 이상 재생되는 경우 오디오를 일시 중지하거나 중지하는 메커니즘이 있습니까?

스크린 리더를 사용 중이고 비디오가 자동으로 동시에 재생되는 경우 두 가지 음성을 들을 수 있습니다!

이상적으로는 이 문제를 해결하는 비디오 자동 재생이 없습니다.

자동 재생이 있는 경우 3초 미만인지 확인하고 그렇지 않은 경우 재생되는 비디오의 오디오를 제어하는 ​​방법이 있는지 확인하십시오.

배경의 텍스트와 이미지/색상 사이에 좋은 대비가 있습니까?

우리 모두는 디자인과 브랜딩에서 색상이 얼마나 중요한지 알고 있지만 시각 장애가 있는 방문자의 경우 색상이 경험에 큰 영향을 미치지 않습니다.

예를 들어, 색맹인 사람들은 빨강, 주황, 노랑, 초록의 차이를 느끼지 못하기 때문에 그들에게도 음식을 제공해야 합니다.

여기서 핵심은 웹사이트에서 발견되는 가장 일반적인 접근성 문제 중 하나인 명암비를 염두에 두는 것입니다.

텍스트 색상과 배경 사이에 충분한 대비가 있습니까? 색상 대비 검사기와 같은 도구를 사용하면 찾을 수 있습니다!

배경색은 왼쪽에 있고 텍스트 색상은 오른쪽에 있습니다. 점수는 중간입니다.

텍스트가 클 경우(예: 18포인트 또는 14포인트 굵게) 대비가 최소 4.5:1 또는 3.1이 되도록 권장합니다.

또한 색상 이외의 도구를 사용하여 사이트의 중요한 콘텐츠와 정보를 전달해야 합니다.

예를 들어 기본 CTA는 일반적으로 사용자가 알아차리게 만드는 색상으로 인해 페이지에서 튀어 나옵니다. CTA에 더 쉽게 접근할 수 있도록 크기, 배치, 굵기, 대비를 사용하여 색맹이 있는 사람들이 눈에 띄게 만들 수 있습니다.

텍스트를 크게 해도 웹사이트가 정상적으로 작동합니까?

분명한 것은 시각 장애가 있는 사람을 돕기 위해 화면의 텍스트를 확대하는 것입니다.

그러나 사용자가 텍스트 크기를 늘리면 웹사이트가 정상적으로 작동하기를 원합니다.

예를 들어 사용자가 텍스트를 최대 400%까지 확대할 때 정보가 손실되지 않도록 해야 합니다.

다음은 W3.org에서 가져온 이미지입니다. 나는 당신이 텍스트를 확대할 때 당신의 웹사이트가 오른쪽과 같이 보이는 것을 원하지 않을 것이라고 확신합니다.

WCAG 2.1 요구 사항은 문제 없이 200%까지 확대할 수 있어야 한다는 것입니다.

필요한 경우가 아니면 텍스트 이미지를 피합니까?

텍스트(예: 회사 이름)가 포함된 로고가 있을 수 있습니다.

그러나 텍스트 이미지는 어떻습니까?

텍스트 이미지가 있는 경우 최소한 해당 이미지를 설명하는 레이블을 제공해야 합니다.

그러나 다음과 같은 경우가 아니면 이러한 유형의 이미지를 피하는 것이 좋습니다.

• 필수입니다
• 그것은 사용자 정의

웹사이트가 반응형입니까?

전체 웹 페이지를 보려면 아래로 스크롤하지만 오른쪽이나 왼쪽으로 스크롤하지 않는 것이 정상입니다.

데스크탑에서 더 작은 장치로 이동할 때 화면이 자동으로 조정되어 여전히 오른쪽이나 왼쪽으로 스크롤할 필요가 없습니다.

텍스트가 아닌 콘텐츠에 대한 대비가 충분합니까?

인접한 색상의 명암비는 3:1 이상이어야 합니다.

이 요구 사항은 상대적으로 시력이 낮은 사람들을 위한 것입니다.

성능 저하 없이 간격/줄 ​​높이를 조정할 수 있습니까?

• 줄 높이(줄 간격)는 글꼴 크기의 1.5배 이상이어야 합니다.
• 다음 단락의 간격은 글꼴 크기의 2배 이상이어야 합니다.
• 문자 간격(자간)은 글꼴 크기의 0.12배 이상이어야 합니다.
• 단어 간격은 글꼴 크기의 0.16배 이상이어야 합니다.

호버 또는 포커스에 콘텐츠가 올바르게 표시됩니까?

요소에 초점을 맞추거나(예: 탭으로 이동) 요소 위로 마우스를 가져가면 추가 콘텐츠가 표시됩니다.

예를 들어 버튼 위로 마우스를 가져가면 팝업이 나타납니다.

… 또는 하위 메뉴가 표시됩니다.

이 콘텐츠는 다음과 같아야 합니다.

해제 가능 – 예를 들어 Escape를 클릭하면 콘텐츠가 더 이상 표시되지 않습니다.

Hoverable – 콘텐츠 위로 마우스를 가져가면 마우스가 트리거 위에 있는 동안 콘텐츠가 표시됩니다.

Persistent – ​​이것은 둘 다의 조합입니다. 사용자가 콘텐츠를 닫거나, 사용자가 마우스를 멀리 이동하거나, 콘텐츠에 더 이상 중요한 정보가 포함되지 않을 때까지 콘텐츠가 계속 표시됩니다.

참고: 이는 이미지(예: 이미지) 위로 마우스를 가져갈 때 제목과 같은 HTML 요소가 표시되는 경우에는 적용되지 않습니다.

글꼴을 읽을 수 있습니까?

일부 글꼴/서체는 다른 글꼴/서체보다 읽기 쉽습니다. 세리프체나 산세리프체를 선호하지만 필수는 아닙니다. 중요한 부분은 읽을 수 있다는 것입니다.

2. 작동 가능

이는 사용자가 탐색 및 사용자 인터페이스와 상호 작용하여 사용할 수 있어야 함을 의미합니다. 예를 들어, 키보드를 사용하여 사용자 인터페이스를 '조작'할 수 있습니다.

지침 2.1 – 키보드 액세스 가능

이동성 접근성 장벽이 있는 사용자나 스크린 리더를 사용하는 사용자를 포함하여 많은 사용자가 마우스나 트랙패드 대신 키보드를 사용합니다.

이것이 바로 웹사이트의 모든 기능에 키보드(링크, 버튼, 양식 및 기타 컨트롤)를 통해 액세스할 수 있어야 하는 이유입니다.

모든 것이 키보드를 통해 액세스할 수 있습니까?

이제 마우스 사용을 중단하고 키보드만 사용할 때입니다.

확인 중:

모든 것이 앞으로 또는 뒤로 가는 논리적 순서를 따릅니다(탭을 사용하여 앞으로 이동하고 Shift 탭을 사용하여 뒤로 이동).

특정 버튼, 섹션 등에 있을 때 이 요소가 강조 표시되어 있습니까? 다음 예에서는 '기사'로 탭을 지정했음이 분명합니다.

탭 키를 사용하여 모든 것에 액세스할 수 있고 포커스가 있을 때 Enter 키를 누르면 작업이 활성화됩니까?

참고: 팝업이 나타나면 이 항목도 탐색할 수 있어야 합니다.

헤더를 건너뛸 수 있습니까?

스크린 리더를 사용할 때 모든 페이지에서 동일한 헤더를 읽는 것을 원하지 않습니다. 그것은 당신을 미치게 만들 것입니다. 따라서 '콘텐츠 링크로 건너뛰기'로 탭을 이동하고 Enter 키를 누르면 다음 탭에서 해당 섹션을 건너뛸 수 있습니다.

아래 웹사이트에 처음 도착했을 때 탭을 클릭하면 '콘텐츠로 건너뛰기' 링크가 표시됩니다. 엔터를 누르시면 바로 내용으로 넘어갑니다.

두 번째 탭을 누르면 '네비게이션으로 건너뛰기' 링크로 이동합니다. 여기에서 엔터를 누르면 내비게이션으로 이동합니다.

다시 탭을 누르면 '네비게이션으로 건너뛰기'로 이동합니다. 이것을 선택하면 바로 탐색으로 이동합니다.

바로 가기로 사용되는 문자, 구두점, 숫자 또는 기호가 있는 경우 이 바로 가기를 비활성화하거나 하나 이상의 인쇄할 수 없는 문자로 변경할 수 있는 방법이 있어야 합니다. 유일한 다른 예외는 바로 가기가 요소에 포커스가 있을 때만 사용할 수 있는 경우입니다.

2.1.2 키보드로 막다른 골목(키보드 트랩)을 치는 상황이 있습니까?

웹 사이트의 한 장소로 이동하며 앞으로 또는 뒤로 탭할 수 없습니다.

이것은 키보드 트랩으로 알려져 있습니다. 노래가 진행되면서…

문자를 사용하여 구현된 키보드 단축키에 대한 대안이 있습니까?

탐색을 위해 키보드에 의존하는 사람과 함께 문자 키 단축키를 사용하는 것은 실수로 키를 눌렀을 수 있기 때문에 좋지 않습니다.

그래서 대안을 제시해야 합니다.

a) 이 캐릭터를 다른 단축키로 다시 매핑하는 기능

비). 꺼

씨). 이것에 집중할 때만 활성화됩니다. 따라서 바로 가기를 사용하면 실제로 사용하지 않는 한 아무 일도 일어나지 않습니다!

지침 2.2 – 충분한 시간

양식 작성에 시간 제한을 설정했지만 접근성 요구 사항이 없는 사용자만 고려한다고 상상해 보십시오. 이 시간 제한이 너무 짧을 수 있습니다.

타이밍 조절이 가능한가요?

시간을 끄는 것이 이상적이지만 시간을 연장하거나(즉, 시간 제한에 거의 도달했을 때) 새로운 시간으로 조정할 수 있는 것은 괜찮습니다.

웹사이트 사용자가 이동, 깜박임 또는 자동 업데이트 콘텐츠를 일시 중지, 중지 또는 숨길 수 있습니까?

움직이거나 깜박이거나 소리를 지르며 다음과 같은 경우:

ㅏ). 자동으로 시작

비). 5초 이상 지속

씨). 다른 콘텐츠와 병행하여 표시됩니다.

그런 다음 일시 중지, 중지 또는 삭제를 위한 메커니즘이 있습니다.

콘텐츠 자동 업데이트와 동일한 문제입니다.

지침 2.3 – 발작 및 신체 반응

이 지침은 발작이나 신체 반응을 유발할 수 있는 것이 없도록 고안된 것입니다.

화면의 '깜박임'이 지침을 충족합니까?

첫 번째 규칙은 깜박이는 물체를 피하는 것이지만 이것이 불가능할 경우 1초에 3번 이상 깜박이거나 일반 또는 빨간색 깜박임 임계값 아래에서 깜박이지 않는지 확인하십시오.

지침 2.4 – 탐색 가능

이것은 웹 사이트를 쉽게 탐색할 수 있도록 하기 위한 것입니다.

반복되는 블록을 건너뛸 수 있습니까?

스크린 리더를 사용하여 새 페이지에 도달할 때마다 탐색 내용을 읽는다고 상상해 보십시오. 이제 재미가 없을 것입니다. 따라서 이것들을 건너뛸 수 있어야 합니다. 나는 앞서 이것의 예를 들었다.

모든 페이지의 제목이 올바르게 지정되었습니까?

모든 페이지에 좋은 설명 제목이 필요합니다. 이것은 접근성에도 좋지만 SEO에도 좋습니다.

Screaming Frog를 사용하여 한 곳에서 페이지 제목을 모두 볼 수 있습니다.

초점 순서가 의미를 보존합니까?

콘텐츠를 탭핑하지만 의미가 없는 순서로 탭하면 이 문제를 수정해야 합니다.

링크 텍스트에서 링크의 목적을 알 수 있습니까?

'여기를 클릭하세요'는 그다지 유용한 앵커 텍스트가 아닙니다. 링크의 내용을 설명하는 단어가 있어야 합니다.

앵커 텍스트란 무엇입니까?

웹 사이트 또는 외부 웹 사이트의 다른 페이지에 링크할 때 앵커 텍스트는 사람들을 보내는 페이지와 관련된 보이는 텍스트입니다. 링크만 표시하는 것보다 실제 텍스트를 표시하는 것이 좋습니다.

웹 페이지를 찾는 방법이 한 가지 이상 있습니까?

여기 몇 가지 예가 있어요.

• 사이트맵 – 사이트맵의 모든 페이지 목록이 있습니다.
• 빠른 링크 – 중요한 페이지로 이동할 수 있는 빠른 링크가 있습니다.
• 검색 – 관련 페이지를 찾기 위해 검색

키보드 포커스가 보이나요?

질문이 모든 것을 말해줍니다! 이것은 이전 지침 중 하나에서도 다루어졌습니다. 어딘가로 탭할 때 초점이 해당 영역에 있는지 시각적으로 볼 수 있어야 합니다.

머리글, 본문, 바닥글이 명확하게 정의되어 있습니까?

보조 기술은 머리글, 바닥글 및 본문을 명확하게 식별할 수 있어야 합니다. 이러한 영역을 정의하는 html 태그가 있습니다.

지침 2.5 입력 양식

이 지침은 키보드나 마우스를 사용하여 탐색할 수 없는 최신 인터페이스에 관한 것입니다. 예를 들어 스마트폰에서는 스와이프, 핀치 및 줌, 탭 등을 할 수 있습니다.

다지점 또는 경로 기반 제스처를 사용하는 기능을 제스처를 사용하지 않고 단일 포인터로 작동할 수 있습니까(필수적인 경우 제외)?

경로 기반 제스처는 특정 경로로 이동해야 하는 위치입니다. 예를 들어 특정 기능에 액세스하려면 위로 스와이프하고 다른 기능에 액세스하려면 아래로 스와이프합니다. 다중 지점 제스처는 두 개 이상의 접점을 사용하여 기능에 액세스하는 곳입니다(예: 두 손가락을 사용하여 핀치 및 확대/축소).

단일 포인터에 의해 시작된 작업에서 쉽게 벗어날 수 있는 방법이 있습니까?

단일 포인터란 무엇입니까?

여기에서 탭, 클릭, 길게 누르기 등과 같이 화면과 상호 작용하는 한 지점으로 기능에 액세스할 수 있습니다.

다음 중 적어도 하나는 참이어야 합니다.

• 다운 이벤트 없음 – 버튼을 누를 때 트리거가 구현됩니다.
• Abort or Undo – up 이벤트를 사용하고(즉, 포인터를 놓으면 기능이 활성화됨) 중단하는 방법이 있습니다. 예를 들어, 손가락으로 무언가를 누르고 손가락을 똑바로 들어 올리는 대신 화면의 다른 부분으로 슬라이드하면 기능이 중단됩니다.
• 상향 반전 – 상향 이벤트는 하향 이벤트를 반전시킵니다.
• 필수 - 다운 이벤트의 기능을 완료하는 것이 필수적입니다.

구성 요소의 보이는 레이블이 해당 구성 요소의 프로그래밍 방식 이름과 일치합니까?

시력 사용자가 텍스트를 음성으로 변환하는 경우 프로그래밍 방식 이름이 읽혀지고 이것이 보이는 레이블과 일치하면 더 나은 경험을 할 수 있습니다.

모션이나 제스처로 작동되는 기능을 다른 UI 컨트롤에서도 작동할 수 있습니까?

제어하기 위해 무언가를 흔들거나 기울이면 다른 UI 컨트롤을 사용하여 이 기능에 액세스할 수 있습니까?

이해할 수 있는

이것은 페이지에 사용된 언어를 이해할 수 있는지 확인하는 것입니다.

3.1 가독성

다음을 다룹니다.

페이지 또는 페이지 섹션의 언어를 프로그래밍 방식으로 결정할 수 있습니까?

모든 페이지의 시작 부분에 이와 같은 내용이 표시되어야 합니다. 'Lang'은 페이지의 언어를 나타냅니다.

<html class="ie7" lang="en-US">

페이지의 언어가 변경된 경우에도 이를 식별할 수 있어야 합니다.

3.2 예측 가능

UI가 예상 가능한 방식으로 작동하기를 원합니다. 놀랍지 않습니다!

페이지에서 탐색 순서가 동일합니까?

사용자가 탐색을 변경하지 않는 한 한 페이지의 탐색 위치는 다른 모든 페이지에서 동일해야 합니다.

구성 요소, 이미지 등의 이름이 페이지 간에 일관되게 지정됩니까?

한 페이지에 이미지가 있고 다른 페이지에 동일한 이미지가 있는 경우 이미지 이름을 동일하게 지정하고 싶습니다.

게시물의 여러 페이지가 있고 페이지 이름을 페이지 1, 페이지 2, 페이지 3으로 지정하면 일관성이 있습니다. 라벨링이 의미가 없다면 동일할 필요는 없지만 일관성은 있어야 합니다.

3.3 입력 지원

이것은 사용자가 실수를 피하거나 복구할 수 있도록 돕는 것입니다.

입력 오류 – 무언가를 잘못 입력하는 경우 시각적으로 잘못된 것을 볼 수 있지만 문제를 식별하는 텍스트도 있어야 합니다.

레이블 – 사용자가 텍스트를 입력해야 하는 경우 필드를 설명하는 연관된 레이블이 있습니다.

입력 오류 – 사용자가 오류를 범하면 수정 방법에 대한 제안이 있습니다.

오류 방지 – 오류를 되돌리거나 오류에 대한 피드백을 받거나 제출하기 전에 확인할 수 있어야 합니다.

4. 견고함

액세스 가능한 것 외에도 콘텐츠는 다양한 브라우저, 기술 등을 지원해야 합니다.

지침 4.1 호환

여기에는 다양한 사용자 에이전트 및 보조 기술을 사용한 테스트가 포함됩니다. 이에 대한 좋은 초기 테스트는 W3C 마크업 유효성 검사 도구를 사용하여 오류가 있는지 확인하는 것입니다(즉, html, xhml 등의 구조/구문이 올바른지 확인).

다음은 출력의 예입니다.

또한 콘텐츠가 올바르게 로드되었는지 확인하기 위해 여러 브라우저에 대해 테스트해야 합니다.

또한 텍스트 전용 브라우저(예: Lynx)에서 페이지를 로드할 가치가 있습니다.

모든 데이터를 올바르게 구문 분석할 수 있습니까?

섹션이 시작하고 끝나는 위치를 쉽게 식별할 수 있도록 콘텐츠 섹션 내에 적절한 시작 및 종료 태그가 있습니까?

요소가 올바르게 중첩되어 있습니까?

요소를 구별하기 어렵게 만드는 중복 속성이나 ID가 있습니까?

모든 사용자 인터페이스 컨트롤을 보조 기술로 이해할 수 있습니까?

다음은 컨트롤의 몇 가지 예와 알아낼 수 있어야 하는 사항입니다.

• 체크박스 - 체크가 되어있나요?
• 초점 – 어떤 요소에 초점이 있으며 시각적으로 뿐만 아니라 프로그래밍 방식으로 이해할 수 있습니까?

사용자는 작업을 반드시 방해하지 않는 방식으로 포커스가 주어지지 않은 상태 메시지를 인지하고 있습니까?

당신이 페이지를 탐색하고 있고 그 페이지에 있는 동안 배너가 웹사이트 상단을 가로질러 판매를 발표한다고 상상해 보십시오.

양식이 올바른 방식으로 설계되었습니까?

양식에 액세스할 수 있도록 하려면 다음이 활성화되어 있는지 확인해야 합니다.

• 탭을 사용하여 양식을 탐색하는 기능
• 탭을 사용하여 양식을 탐색하는 기능

<형태>

<label for="fname">이름:</label><br>

<입력 유형=”텍스트” id=”fname” 이름=”fname”><br>

<label for="lname">성:</label><br>

<입력 유형=”텍스트” id=”lname” 이름=”lname”>

</form>

• 명확하게 표시된 필수 필드. 필드가 필수인 경우 html에서 레이블도 올바르게 지정해야 합니다.
• 사용자를 위한 지침이 있습니다(일반적으로 양식 상단에 있음).
• 사용자는 양식 필드를 완성하는 동안 오류를 범할 때 도움을 받습니다(예: 잘못된 날짜 형식, 입력해야 하는 형식).

요약

보시다시피 포괄적인 접근성 감사를 실행할 때 다루어야 할 근거가 많습니다. 그러나 긍정적인 브랜드 이미지 구축에서 더 많은 청중에게 도달하고 SEO 개선에 이르기까지 모든 것이 효과가 있으며 비즈니스에 가져다주는 이점은 많습니다.