[tech] 프론트엔드의 웹 접근성

 

✅ A11Y가 무엇을 의미할까?

바로 접근성 영단어인 “accessibility” 의 축약어

여기서 숫자 11은 단어의 첫 문자와 마지막 문자 사이에 생략 된 문자의 수

웹의 창시자 팀 버너스 ( 영국의 컴퓨터 과학자, www,URL,HTTP등을 고안하여 웹을 탄생 시킨 아버지로 유명 )

 

✅ 웹 접근성:

일반적으로 웹에 접근할 수 있다는 것은 웹에서 제공하는 컨텐츠 및 기능을 사용할 수 있다는 것이다. 즉 누구나 기능을 사용할 수 있어야 한다. 개발자는 모든 사용자가 키보드, 마우스 또는 터치를 사용하여 서비스와 상호 작용할 수 있다 가정하고는 한다. 이러한 생각은 일반적으로는 잘 작동하는 사용자 경험으로 이어질 수 있지만 누군가에게는 단순한 성가심에서 서비스와 상호작용을 중단하는 문제를 발생 시킨다. 예를 들어 마우스로만 상호작용 하도록 만들었는데 마우스가 갑자기 고장 나면 아예 사용하지 못함.

주로 접근성에 대한 논의를 신체적 장애가 있는 사용자에게 초점을 맞추는 경향이 있지만, 우리 모두는 어떠한 이유든 액세스할 수 없는 인터페이스를 접할 수 있다. 특정 지역, 네트워크 환경, 접근 장치에 따라 제대로 동작하지 않는 경우를 본 적이 있을 것이며 모두 접근성 문제이다.

 

✅ 웹 접근성의 중요성:

웹 접근성이 꼭 장애인만을 위한 것이 아니라는 점! !

계단 옆 경사로를 만든 까닭은 처음에는 장애인을 위한 것이었지만 무거운 짐을 실은 사람, 다리 아파서 계단 오르기 힘든 사람, 유모차를 미는 사람 등 모두 이용할 수 있습니다.

웹도 마찬가지로 웹접근성 지침에 "키보드만으로도 웹 콘텐츠가 제공하는 모든 기능을 수행할 수 있어야 한다" 라는 지침이 있는데 이것은 마우스 사용이 힘든 장애인뿐만 아니라, 갑자기 마우스가 고장났을 때나 없을 때, 누구나 편리하게 사용할 수 있습니다. 이처럼 누가 언제 어느 상황에서 써도 좋게 만드는 것이 웹 접근성이라고 할 수 있겠습니다

웹 접근성은 장애를 가진 사용자뿐만 아니라, 인터넷 속도가 느린 사용자나 특정 기기를 사용하는 사용자에게도 유익합니다. 또한, 접근성을 고려한 웹사이트는 SEO(검색엔진 최적화)에 유리하고, 법적인 문제를 예방할 수 있습니다.

캐나다에서는 WCAG에 따른 지침을 충족하도록 법으로 지정하여 많은 기업들이 웹 접근성에 대한 많은 투자를 하고 있다. 옆 나라 미국 역시 관련 고소 건은 매해 늘어나고 있고, 서비스가 인기 있고 누구나 액세스할 수 없다면 고소를 당할 수 있다는 것이다.

 

 

**접근성 지침 가이드라인 https://www.w3.org/TR/WCAG20/**

 

✅ WCAG 원칙 :

웹 콘텐츠의 접근성을 위한 지침으로, 웹 사이트가 누구나 이용할 수 있도록 만드는 원칙

• 인지 가능(Perceivable): 사용자가 컨텐츠를 인지할 수 있는가? 이는 시각과 같은 특정 감각으로 무언가를 인지할 수 있다고 해서 모든 사용자가 인지할 수 있다는 의미는 아니라는 점을 기억하자
• 작동 가능(Operable): 사용자가 UI 컴포넌트를 사용하고 컨텐츠와 상호작용할 수 있는가? 예로 호버 인터렉션이 필수적으로 필요하다면 마우스나, 터치가 불가능한 사용자는 조작할 수 없다.
• 이해 가능(Understandable): 사용자가 컨텐츠를 이해할 수 있는가? 사용자가 인터페이스를 이해하는데 어려움 없으며, 일관성을 가지고 있도록 한다.
• 견고함(Robust): 다양한 환경(브라우저, 장치 등)에서 컨텐츠를 사용할 수 있어야 한다.

✅ 실천 가이드라인

• 모든 레이아웃을 div 태그로 만드는 대신 시멘틱 태그를 사용하기
• 작은 폰트 사이즈를 사용하지 말자
• px 대신 rem 단위를 사용하여 폰트 사이즈를 지정하자
  • em 단위를 사용하면 사용자가 장치 및 브라우저에서 폰트 사이즈를 조정
  • px는 페이지를 명시적으로 크기 조절한 경우에만 조정된다.
• 앵커를 버튼으로 사용하지 않는다
  • 사용자가 실수로 이웃 요소를 잘못 클릭하지 않도록 탭은 최소 40px 40px 간격을 유지하도록 한다.

✅ Toast

• 토스트는 짧은 시간에 나타났다가 사라지는 알림 컴포넌트
• ex)지도 앱에서 검색 버튼을 누르면 결과가 나오기 전까지 표시되는 “위치 검색 중”과 같은 메세지

모달과 차이점: 모달은 닫기 버튼 등 상호작용이 필요하지만, 토스트는 자동으로 사라짐.

기본적으로 5초 유지 + 5단어당 1초 추가 → 최소 6초 이상 유지하는 것이 적절함.

WCAG AA 레벨 접근성 지침

(WCAG 2.0 AA 기준 50개 지침 중 12개가 토스트에 적용됨.)

 

  1) 일관된 식별 & 위치

• 특정 아이콘에 대체 텍스트 제공.
• 메시지의 헤더(제목) 역할을 하는 단어 반복적으로 사용.
• 토스트가 나타나는 위치를 일관되게 배치해야 함.

 2) 키보드 접근성

• 갑자기 건전지 이슈로 마우스를 못 쓰는 경우도 있기 때문에 사용자가 키보드로 토스트에 접근할 수 있어야 함.
• 포커스 이동 시 순서(tabindex)를 강제로 지정하면 안 됨.

 3) 스크린 리더(Screen eader) 지원

• role="alert" 또는 aria-live 속성을 사용하여 토스트를 보조 기술(스크린 리더기)에서 읽을 수 있도록 설정.

✅  aria-live 속성 (실시간 알림 영역 설정)

polite	현재 진행 중인 작업이 끝난 후 변경 내용을 사용자에게 전달 (가장 일반적)
assertive	스크린 리더가 즉시 중단하고 변경 내용을 안내 (긴급한 오류 메시지 등에 사용)
off	실시간 업데이트 비활성화

 

예제 코드

<!-- 🚨 접근성 문제 발생 -->
<div class="status">메세지가 전송되었습니다.</div>

<!-- ✅ 문제 개선 -->
<div class="status" aria-live="polite">메세지가 전송되었습니다.</div>

• aria-live="polite": 사용자가 현재 작업 중이라면 방해하지 않고, 끝난 후 메시지를 읽어줌.

 

✅ 인사이트 & 코멘트

• 배운 점: 아티클을 통해 얻은 교훈 및 인사이트 🌟
• 작은 UI 요소도 접근성을 고려해야 한다
• 접근성은 장애인을 위한 것이 아니라, 모든 사용자의 편의를 위한 것이라는 점을 기억하자!
• 자동으로 사라지는 정보는 사용자 친화적이지 않을 수도 있다.
• 이러한 접근성은 사이트마다 다르게 구현되지만, 이를 반영한 일관된 스타일 가이드를 만들고 시작하면 프로젝트 전반에서 품질을 유지하기 쉬울 거라 생각됨오늘의 한줄평 : 접근성을 고민하는 과정에서 배려하는 UI가 결국 더 나은 UX를 만든다
• ⇒ 디자인, 개발, 접근성 팀이 협업하여 최적의 구현 방안을 고민하는 것이 중요할 듯