접근성 관련 자주 묻는 질문!

툴팁 형태의 말풍선을 버튼 위에 제공할 때, 본문 콘텐츠를 가리지 않아야 하는 기준이 어떻게 되나요?

• 마우스 오버 또는 포커스 이동 시 말풍선이 발생하는 실제 툴팁으로 마크업된 경우에는 화면을 가려도 마우스 오버를 해제하거나 포커스 적용을 해제하여 툴팁이 닫히기 때문에 상관 없습니다.
• 접근성에 문제가 되는 부분은 툴팁과 동일하거나 비슷한 형태의 말풍선이 항상 화면에 노출되어 있어서 본문 콘텐츠를 가리는 경우 본문 콘텐츠를 가리지 않도록 말풍선의 위치를 재배치하거나, 말풍선을 닫을 수 있는 매커니즘(닫기 버튼, 열고 닫을 수 있는 확장/축소 버튼)이 필요합니다.
• 다만, 키보드 또는 마우스를 사용하여(페이지 스크롤 등) 말풍선에 가려진 본문 콘텐츠를 볼 수 있다면 본문 영역을 가리고 있어도 예외 사항으로 볼 수 있습니다.

요소의 디자인과 포커스가 겹쳐서 포커스 라인의 일부가 보이지 않는데, 이런 경우 2.4.7 Focus Visible 항목에 위배되나요?

• 브라우저 확대하지 않은 상태에서는 포커스 라인이 온전하게 구분되어야 합니다.
• 다만, 아래와 같이 Case by case에 따라서 위배 여부인지 확인이 필요합니다.
  1. 브라우저 확대하지 않은 상태에서 포커스 라인이 추가 콘텐츠(펼침 영역 등)에 일부 또는 전체가 소실되는 경우 위배
  2. 브라우저 확대하지 않은 상태 및 확대 상태(200%, 400%)에서 포커스 라인의 일부가 텍스트와 겹치는 경우 위배
  3. 브라우저 특정 해상도에서 포커스 라인 전체가 소실되는 경우 위배
  4. 브라우저 확대하지 않은 상태 및 확대 상태(200%, 400%)에서 포커스 라인의 일부가 특정 영역 또는 콘텐츠에 의해 소실되는 경우 위배
  5. 브라우저 확대하지 않은 상태 및 확대 상태(200%, 400%)에서 포커스 라인이 디자인 요소에 의해 일부가 겹치는 경우 위배
  6. 브라우저 확대 상태(200%, 400%)에서 포커스 라인이 화면에 일부 소실되면 상관 없으나, 콘텐츠(텍스트, 버튼 등)와 함께 화면에서 소실되면 위배
  7. 브라우저 확대 상태에서(200%, 400%)에서 포커스 라인 전체가 화면에 소실되는 경우 위배

요소의 디자인과 포커스가 겹쳐서 포커스 라인의 일부가 보이지 않는데, 이런 경우 2.4.7 Focus Visible 항목에 위배되나요?

• 브라우저 확대하지 않은 상태에서는 포커스 라인이 온전하게 구분되어야 합니다.
• 다만, 아래와 같이 Case by case에 따라서 위배 여부인지 확인이 필요합니다.
  1. 브라우저 확대하지 않은 상태에서 포커스 라인이 추가 콘텐츠(펼침 영역 등)에 일부 또는 전체가 소실되는 경우 위배
  2. 브라우저 확대하지 않은 상태 및 확대 상태(200%, 400%)에서 포커스 라인의 일부가 텍스트와 겹치는 경우 위배
  3. 브라우저 특정 해상도에서 포커스 라인 전체가 소실되는 경우 위배
  4. 브라우저 확대하지 않은 상태 및 확대 상태(200%, 400%)에서 포커스 라인의 일부가 특정 영역 또는 콘텐츠에 의해 소실되는 경우 위배
  5. 브라우저 확대하지 않은 상태 및 확대 상태(200%, 400%)에서 포커스 라인이 디자인 요소에 의해 일부가 겹치는 경우 위배
  6. 브라우저 확대 상태(200%, 400%)에서 포커스 라인이 화면에 일부 소실되면 상관 없으나, 콘텐츠(텍스트, 버튼 등)와 함께 화면에서 소실되면 위배
  7. 브라우저 확대 상태에서(200%, 400%)에서 포커스 라인 전체가 화면에 소실되는 경우 위배

선택할 수 없는(disabled) 버튼에 CSS 스타일로 cursor : not-allowed; 속성을 삽입해야 하나요?

• 웹 접근성 기준(WCAG 2.1 - 2.2)에서 마우스 호버 상태일 때 포인터 가시성에 대한 요구 사항은 없습니다. 따라서 disabled 상태인 버튼에 CSS 커서가 not-allowed로 지정되어 있지 않아도 접근성에 위배되지 않습니다.
• 다만, UX 디자인 측면에서 마우스를 사용하는 일반 사용자 및 저시력 사용자에게 사용할 수 없음에 대한 시각적 표시를 제공하기 위해서 비활성화된 요소에 CSS cursor: not-allowed 속성을 사용하는 것이 좋습니다.

다이얼로그의 X(닫기) 버튼을 선택했을 때 다음 동작이 반드시 다이얼로그를 발생시킨 요소로 포커스를 이동해야 하나요?

• 기본적으로 다이얼로그의 X(닫기) 버튼을 선택한 후 브라우저 URL 입력 박스 또는 최상단 영역인 ‘본문 바로가기’ 로 포커스가 이동하는 경우 접근성 위배이기 때문에 다이얼로그가 발생한 요소로 키보드 포커스를 이동시켜야 합니다.
• 다만, 로직상 논리적으로 의도한 포커스 처리(확인 또는 닫기 버튼을 누르면 이전 페이지가 세션 만료되어 메인 페이지로 포커스 이동, 첫번째 다이얼로그 안의 버튼으로 발생한 두번째 다이얼로그 닫기 버튼 선택 시 첫번째와 두번째 다이얼로그가 모두 닫히는 경우 등)는 예외로 볼 수 있습니다.

컴포넌트 사용에 대한 마우스 동작과 키보드의 동작이 항상 동일해야 하나요?

• 접근성에서는 기본적으로 마우스 사용은 가능하다는 전제이므로 키보드 사용자(상지지체 장애인, 시각장애인 등)도 동일하게 컴포넌트를 키보드를 사용하여 이용할 수 있으면 접근성에 위배되지 않습니다.
• 컴포넌트 사용에 대한 마우스와 키보드의 동작하는 방식 또는 CSS 스타일이 다르다고 접근성에서 문제되지 않습니다.

로딩 화면이 매우 짧은 경우 또는 의미 없는 Fake loading의 경우 스크린리더 사용자에게 로딩 안내가 필요한가요?

• 로딩, 부분 로딩과 같이 실제 데이터를 불러오거나 페이지가 이동하여 발생하는 로딩과 다르게 화면의 전환 역할로서 Fake loading이 발생하는 경우 스크린리더 사용자에게 aria-live로 별도 안내하지 않아도 됩니다.
• Fake loading인지 실제 데이터 로딩인지 사용자 입장에서 구분할 수 없기 때문에 1초 이내 바로 사라지는 로딩은 Fake loading으로 간주하여 스크린리더로 안내하지 않도록 합니다.

모바일앱(AOS/iOS)에서 화면을 이동한 후 초점은 어떤 요소로 이동해야되나요?

• 모바일 스크린리더(TalkBack, VoiceOver) 이용 시 앱에서 화면을 이동했을 때, 첫번째 요소인 ‘뒤로 가기’ 버튼으로 이동하는 것이 기본적인 원칙입니다.
• 다만, 사용자가 화면을 이동했을 때 어떤 화면인지 먼저 확인할 수 있도록 제목 영역으로 초점을 이동시킬 수 있으며 이때 초점은 [제목 → 뒤로 가기 → 닫기 → 본문 영역] 순서로 이동해야 합니다.
• 정리하면 화면 이동 후 어떤 요소로 초점이 이동 되어도 상관없으나, 초점이 적용되는 첫번째 요소가 되어야 합니다.

모바일앱(AOS/iOS)에서 WebView 콘텐츠의 스크린리더 초점이 나뉘어지는 현상은 어떻게 수정할 수 있나요?

• 모바일 OS에 따라서 해결 방법이 달라지며, 마크업 형태에 따라서도 방법이 다르므로 아래 내용을 참고하여 수정할 수 있습니다.
• 동일한 콘텐츠 영역에서 스크린리더의 초점이 세 번이상 분리되는 경우 하나의 초점으로 인식할 수 있도록 수정합니다.
• PC View에서는 해당 속성이 삽입되지 않도록 주의하며, 모바일 View에서만 해당 속성이 적용되었는지 확인이 필요합니다.

Android 해결 방법

HTML5 Tags	수정 방안	비고
포커서블하지 않은 요소(<span>, <div> 등)	① 전체를 감싸는 Tag에 taindex=”-1” 속성 삽입함.
② 문단이 시작되는 곳에 role="paragraph" 속성을 삽입함.	Android 버그로 인해 경우에 따라 속성 적용이 안될 수 있음
포커서블한 요소(<a>, <button> 등)	하위 포커서블한 요소에는 role=”none”, aria-hidden=”true” 속성을 삽입하고, 전체를 감싸는 Tag에 aria-label 속성값으로 전체 내용을 삽입함.

iOS 해결 방법

HTML5 Tags	수정 방안	비고
모든 요소(<span>, <div> 등)	전체를 감싸는 Tag에 role=”text” 속성 삽입함.	iOS 버그로 인해 경우에 따라 속성 적용이 안될 수 있음

Firefox에서 <select>의 기본 동작 중 스페이스 선택 후 방향키로 동작하지 않는 것은 접근성 위배인가요?

• <select>의 <option> 목록이 hidden 처리되어 있는 경우 스페이스 선택 후 방향키 위/아래 동작이 적용되지 않는 Firefox 버그가 있습니다.
• 브라우저 버그로서 방향키 위/아래로 선택은 되기 때문에 접근성 위배 내용은 아니지만, <option>에 hidden 대신 disabled 속성으로 변경하여 이슈를 해결할 수 있습니다.

<video> 태그에 삽입된 controlList 속성에 대한 마크업 오류가 발생하는데 대체 가능한 속성이 있나요?

• 결론부터 말하면 대체 가능한 속성이 없습니다. (마크업 오류의 예외)
• 비디오 플레이어의 기능인 동영상 다운로드 버튼을 삭제하기 위해서는 구글에서 제공하는 ControlsList API 를 사용(e.g. controlsList=”nodownload”)할 수 밖에 없는데 HTML5에 등록된 <video>의 속성이 아니기 때문에 W3C Markup Validation 오류가 발생하게 됩니다.

<input>에 삽입된 비밀번호를 표시 기능에 대한 마크업 순서는 어떻게 해야 되나요?

• 통상적으로 <input> 다음에 ‘비밀번호 표시’ 버튼이 위치해 있어서 <input>에 비밀번호 입력 후 제대로 입력되었는지 확인하기 위해서 사용하지만, 스크린리더 사용자 입장에서는 입력하기 전에 비밀번호 표시 여부를 설정하고 <input>에서 입력한 내용이 올바르게 입력되고 있는지 바로 확인하는 방식이 더 유용합니다.
• 그러므로 ‘비밀번호 표시’ 버튼을 <input> 상단에 배치하고, 버튼에 aria-pressed의 속성값(true/false)으로 선택된 여부를 제공합니다.
• 다른 형태의 Reference
  • 영국 정부 컴포넌트 가이드
  • MagentaA11y
  • Password Forms — 3 Ways to Make Them More Accessible