Computer >> 컴퓨터 >  >> 소프트웨어 >> 브라우저

모두가 사용할 수 있는 브라우저 확장 프로그램 만들기: 접근성 개선 단계별 가이드

모두가 사용할 수 있는 브라우저 확장 프로그램 만들기: 접근성 개선 단계별 가이드

브라우저 확장 프로그램을 만드는 일 자체는 어렵지 않습니다. 하지만 모든 사용자가 불편 없이 이용할 수 있도록 접근성까지 챙기는 것은 세심한 주의와 노하우가 필요한 영역입니다.

확장 프로그램이 데이터를 완벽하게 불러오고 인터페이스가 아무리 멋져도, 스크린 리더 사용자나 키보드로 탐색하는 사용자가 이용할 수 없다면 의도치 않게 수많은 잠재 사용자를 배제하는 셈입니다.

이 글에서는 크롬 브라우저 확장 프로그램의 접근성 문제를 진단하고, 누구나 편하게 사용할 수 있는 포용적인 경험으로 바꾸어 보겠습니다.

목차

  • 브라우저 확장 프로그램에서 접근성이 중요한 이유
  • 수동 접근성 테스트 수행 방법
  • 접근성 개선 사항 구현하기
  • 자동화된 접근성 테스트 수행 방법
  • 접근성 좋은 브라우저 확장 프로그램을 위한 모범 사례
  • 마치며

브라우저 확장 프로그램에서 접근성이 중요한 이유

확장 프로그램 내에서 일어나는 모든 클릭은 접근성이 설계에 반영되어 있는지에 따라 사용자에게 힘을 실어줄 수도, 사용자를 배제할 수도 있는 기회입니다.

브라우저 확장 프로그램은 고유한 접근성 과제를 안고 있습니다. 기존 웹 페이지에 기능을 삽입하면서 동시에 자체 인터페이스의 접근성도 유지해야 하기 때문에, 잠재적인 장벽이 생길 수 있는 이중의 책임을 지는 것이죠. 예를 들어 팝업이 키보드 사용자를 가두어 버리거나 스크린 리더와 소통하지 못하면, 확장 프로그램 자체를 사용할 수 없게 됩니다.

세계보건기구(WHO)에 따르면 전 세계적으로 10억 명 이상이 장애를 겪고 있습니다. 접근성 있는 디자인은 이 방대한 사용자층에게 문을 열어줄 뿐만 아니라, 모든 사람에게 더 나은 경험을 제공합니다.

모두가 사용할 수 있는 브라우저 확장 프로그램 만들기: 접근성 개선 단계별 가이드

브라우저 확장 프로그램에서 흔히 나타나는 접근성 장벽은 다음과 같습니다.

  • 키보드 내비게이션 막다른길: 팝업이나 인터페이스가 키보드 사용자를 가두거나 배제하는 경우
  • 소리 없는 상호작용: 레이블과 설명이 없어서, 아이콘만 있는 버튼을 스크린 리더가 '레이블 없는 버튼'이라고 읽어 사용자가 용도를 추측해야 하는 경우
  • 알림 없는 동적 콘텐츠 변경: 보조 기술이 변화를 인지하지 못한 채 콘텐츠가 바뀌는 경우. 예를 들어 명언이 바뀌어도 스크린 리더에 알리지 않거나, 로딩 중이거나 오류가 발생했을 때 피드백이 전혀 없는 경우
  • 컨텍스트 통합 충돌: 기존 웹 페이지를 수정하는 확장 프로그램이 해당 페이지의 접근성 기능을 망가뜨리거나, 기존 내비게이션 패턴과 충돌하는 요소를 추가하는 경우

이러한 장벽을 이해하면 개발자가 표적화된 방식으로 확장 프로그램의 접근성을 테스트하고 개선할 수 있습니다.

수동 접근성 테스트 수행 방법

자동화 도구는 눈에 띄는 문제를 잡아주지만, 실제 사용자 경험은 수동 테스트를 통해야 드러납니다. 다음은 확장 프로그램의 접근성을 체계적으로 평가하는 방법입니다.

키보드 내비게이션 테스트

마우스를 치워두고 확장 프로그램을 오직 키보드만으로 사용해 보세요. Tab 키로 요소 간에 이동하고, Enter 또는 Space 키로 버튼을 활성화하고, 컴포넌트 내부에서는 방향키를 사용하세요.

  • 현재 포커스가 어느 요소에 있는지 항상 명확하게 보이나요?
  • 버튼을 Enter 또는 Space 키로 기대대로 활성화할 수 있나요?
  • 모달 대화상자나 드롭다운 메뉴에서 빠져나올 수 있나요?

막다른길이나 혼란스러운 지점을 발견했다면, 키보드 사용자도 똑같은 장벽에 부딪힌다는 뜻입니다.

모두가 사용할 수 있는 브라우저 확장 프로그램 만들기: 접근성 개선 단계별 가이드

스크린 리더 평가

운영체제에 내장된 스크린 리더로 확장 프로그램을 탐색하면서 어떤 내용이 읽히는지 들어보세요. macOS에서는 VoiceOver, Windows에서는 내레이터(Narrator), Linux에서는 Orca를 사용할 수 있습니다.

  • 각 요소의 용도가 명확하게 전달되나요? 예를 들어 단순히 "버튼"이 아니라 "새 조언 생성"처럼 읽히는지 확인하세요.
  • 제목, 목록 등의 구조가 올바르게 전달되나요?
  • 사용자가 콘텐츠가 로딩 중인지, 선택되었는지, 변경되었는지 알 수 있나요?

이 테스트 단계에서는 개발자가 전달하려던 의도와 실제로 사용자에게 도달하는 내용 사이의 간극이 자주 드러납니다.

시각적 접근성 검토

다양한 시각 환경에서 확장 프로그램을 살펴보세요. WebAIM의 Contrast Checker 같은 개발자 도구를 활용해 텍스트가 WCAG 권장 명도 대비율 4.5:1을 충족하는지 확인하고, 시스템의 고대비 설정에서도 어떻게 보이는지 테스트하세요. 다음 사항도 점검해야 합니다.

  • 200% 확대해도 기능이 정상적으로 동작하나요?
  • 정보가 색상만으로 전달되지 않나요? 색상으로 구분된 표시 옆에 텍스트 레이블을 함께 두는 식으로 확인하세요.

이러한 수동 테스트는 핵심적인 접근성 문제를 찾아내고, 확장 프로그램을 포용적으로 만들기 위한 표적화된 개선 작업의 길을 열어줍니다.

접근성 개선 사항 구현하기

페이지 새로고침이 일어났다는 사실조차 모른 채 지나가거나, 목적을 알 수 없는 버튼을 클릭하는 상황을 상상해 보세요. 앞서 진행한 수동 테스트 결과, 우리 확장 프로그램의 스크린 리더 사용자는 바로 이런 경험을 하고 있었습니다. 핵심 접근성 문제는 세 가지입니다.

  • 버튼 레이블 누락: 주사위 버튼에 alt 텍스트가 "주사위 아이콘"인 이미지만 있어서, 스크린 리더가 필요로 하는 맥락이 부족함
  • 소리 없는 동적 업데이트: 새 조언이 로드되어도 스크린 리더는 콘텐츠가 바뀐 사실을 알지 못함
  • 로딩 상태 부재: 조언을 가져오는 동안 무슨 일이 일어나고 있는지 사용자에게 어떤 피드백도 제공되지 않음

자동화 테스트를 진행하기 전에 먼저 이 문제들을 해결해 보겠습니다.

버튼 레이블 및 alt 텍스트 문제 해결하기

버튼의 용도를 명확히 설명하는 aria-label을 추가하고, 아이콘에는 설명적인 alt 텍스트를 제공하겠습니다. role="presentation" 속성을 지정하면 스크린 리더가 해당 이미지를 장식용으로 취급합니다.

<!--Before: Unclear Button Purpose and icon alt text-->
<button class="dice-button" id="generate-advice-btn">
 <img src="/icons/icon-dice.png" alt="Dice icon">
</button>
<!--After: Clear, Accessible Button and icon alt text-->
<button class="dice-button" id="generate-advice-btn" aria-label="Generate new advice">
 <img src="/icons/icon-dice.png" alt="A dice icon with green background" role="presentation">
</button>

소리 없는 동적 업데이트 해결하기

스크린 리더가 새 조언을 읽어주도록 aria-live="polite"를 추가하고, 명언 전체가 통째로 읽히도록 aria-atomic="true"를 지정하겠습니다.

<!--Before: Silent Dynamic Updates-->
<p class="advice-quote" id="advice-quote">
 "It is easy to sit up and take notice, what's difficult is getting up and taking action."
</p>
<!--After: Announced Content Changes-->
<p class="advice-quote" id="advice-quote" aria-live="polite" aria-atomic="true">
 "It is easy to sit up and take notice, what's difficult is getting up and taking action."
</p>

로딩 상태 부재 문제 해결하기

로딩 표시기를 제공하는 setLoadingState 함수를 추가하여, 콘텐츠를 가져오는 동안 스크린 리더 사용자에게 알림이 전달되도록 하겠습니다.

// Before: No Loading Feedback
function requestNewAdvice() {
 chrome.runtime.sendMessage({ action: "fetchAdvice" }, (response) => {
 // No loading indicators...
 });
}
// After: Accessible Loading States
function requestNewAdvice() {
 setLoadingState(true); 
 chrome.runtime.sendMessage({ action: "fetchAdvice" }, (response) => {
 setLoadingState(false);
 // Handle response with proper announcements...
 });
}
function setLoadingState(isLoading) {
 if (isLoading) {
 // Disable button and show loading text
 generateAdviceBtn.disabled = true;
 generateAdviceBtn.setAttribute('aria-label', 'Loading new advice...');
 // Show loading text in the advice quote element
 adviceQuoteElement.textContent = "Loading new advice...";
 } else {
 // Re-enable button
 generateAdviceBtn.disabled = false;
 generateAdviceBtn.setAttribute('aria-label', 'Generate new advice');
 }
}

수동 테스트에서 발견된 문제를 모두 해결했으니, 이제 동일한 확장 프로그램으로 자동화 테스트를 진행해 보겠습니다.

자동화된 접근성 테스트 수행 방법

수동 테스트는 중요한 통찰을 제공하지만, 자동화 도구를 활용하면 흔한 문제를 효율적으로 잡아내고 지속적인 모니터링도 가능합니다.

Extension Accessibility Checker는 팝업이나 콘텐츠 스크립트 같은 브라우저 확장 프로그램 인터페이스를 분석해 WCAG 준수 여부를 점검하며, 팝업 제약이나 콘텐츠 삽입 충돌 같은 확장 프로그램 특유의 문제까지 다룹니다.

모두가 사용할 수 있는 브라우저 확장 프로그램 만들기: 접근성 개선 단계별 가이드

Extension Accessibility Checker 사용 방법은 다음과 같습니다.

  1. 브라우저 확장 프로그램 폴더를 .zip 파일로 압축합니다.
  2. https://extensiona11ychecker.vercel.app/ 에 .zip 파일을 업로드합니다.
  3. 생성된 보고서에서 구체적인 접근성 위반 항목을 확인하고, 제시된 수정 방안을 적용합니다.

위 GIF에서 볼 수 있듯이, 이런 워크플로는 접근성을 개발 후에 붙이는 부가 요소가 아니라 개발 프로세스의 일상적인 부분으로 자리 잡는 데 도움이 됩니다.

자동화 테스트 체계를 갖췄으니, 이제 개발 전반에 걸쳐 확장 프로그램의 접근성을 유지하기 위한 모범 사례를 살펴보겠습니다.

접근성 좋은 브라우저 확장 프로그램을 위한 모범 사례

우리는 예제로 만든 조언 생성 확장 프로그램을, 기능은 하지만 접근성이 떨어지는 도구에서 누구나 사용할 수 있는 포용적인 도구로 바꾸어 놓았습니다.

이번 개선 경험을 바탕으로, 접근성 좋은 브라우저 확장 프로그램을 설계하기 위한 네 가지 핵심 원칙을 정리해 보았습니다.

  1. 시맨틱 HTML과 명확한 레이블

    ARIA 속성을 추가하기 전에 항상 올바른 HTML 구조부터 시작하세요. 적절한 요소(예: '조언 생성' 액션에 맞는 버튼, 올바른 제목 계층 구조)를 사용하는 것이 우선입니다.

    모든 인터랙티브 요소는 aria-label, aria-labelledby, 또는 동작을 설명하는 보이는 텍스트를 통해 그 용도가 명확히 드러나야 합니다.

  2. 모든 단계에서의 명확한 소통

    모든 인터랙티브 요소는 자신의 용도를 효과적으로 전달해야 합니다. 사용자는 다음을 이해할 수 있어야 합니다.

    • 지금 무슨 일이 일어나고 있는지 (예: 로딩 상태의 "새 조언을 불러오는 중...")
    • 무엇이 잘못되었는지 (예: 오류 시 "조언을 불러오지 못했습니다")
    • 무엇이 바뀌었는지 (예: 업데이트된 콘텐츠를 위한 aria-live 영역)

  3. 완전한 키보드 접근성

    모든 기능은 키보드만으로 이용할 수 있어야 합니다. 이를 위해서는 상황에 맞게 Tab, Enter, Space, 방향키로 직접 테스트해야 합니다.

    인터페이스를 예측 가능한 순서로 이동하는 명확하고 세심한 포커스 표시기를 제공하고, 모달이나 복잡한 상호작용에서 빠져나갈 수 있는 뚜렷한 방법을 마련하세요.

  4. 사용자 설정과 콘텐츠 스크립트 고려 사항

    시스템 글꼴 크기 설정을 지원하고, 사용자가 지정한 색상 구성을 불필요하게 덮어쓰지 않음으로써 사용자의 선택을 존중하세요.

    확장 프로그램이 기존 웹 페이지를 수정할 때는 해당 페이지의 접근성 기능, 포커스 관리, 내비게이션 패턴을 깨뜨리지 않도록 주의해야 합니다. 삽입하는 모든 새 요소가 접근성 표준을 따르도록 하세요.

마치며

조언 생성 확장 프로그램 사례에서 본 것처럼, 접근성 문제를 해결하면 단순히 기능만 하는 도구가 누구나 사용할 수 있는 포용적인 도구로 거듭납니다.

다만 기존 확장 프로그램의 문제를 고치는 것도 유용하지만, 가장 효과적인 방법은 코드 한 줄을 작성하는 순간부터 접근성이 디자인과 개발 결정을 이끌도록 하는 것입니다.

다음 브라우저 확장 프로그램 프로젝트를 시작할 때 스스로에게 물어보세요.

  • 키보드만으로 이 기능을 어떻게 사용할 수 있을까?
  • 모든 인터랙티브 요소의 용도가 스크린 리더 사용자에게 즉시 명확할까?
  • 사용자는 로딩 중에 무슨 일이 일어나고 있는지 어떻게 알 수 있을까?

아래 자료들도 도움이 될 것입니다.

  • Chrome Extension Accessibility 공식 문서
  • Extension Accessibility Checker
  • 웹 콘텐츠 접근성 가이드라인(WCAG) 2.1

freeCodeCamp의 오픈소스 커리큘럼은 4만 명 이상이 개발자로 취업하는 데 도움을 주었습니다. 무료로 코딩을 배워 보세요.