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

포괄적인 브라우저 확장 구축:단계별 접근성 디자인

포괄적인 브라우저 확장 구축:단계별 접근성 디자인

브라우저 확장 프로그램을 구축하는 것은 쉽지만 모든 사람이 액세스할 수 있도록 하려면 세심한 주의와 기술이 필요합니다.

확장 프로그램은 데이터를 완벽하게 가져오고 아름다운 인터페이스를 갖추고 있지만 스크린 리더 사용자나 키보드 탐색기가 확장 프로그램을 사용할 수 없다면 의도치 않게 많은 잠재 사용자를 제외시킨 것입니다.

이 문서에서는 Chrome 브라우저 확장 프로그램의 접근성 문제를 감사하고 이를 모든 사람에게 적합한 포괄적인 환경으로 변환할 것입니다.

목차

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

  • 수동 브라우저 확장 접근성 테스트를 수행하는 방법

  • 브라우저 확장 접근성 개선을 구현하는 방법

  • 자동화된 브라우저 확장 접근성 테스트를 수행하는 방법

  • 접근 가능한 브라우저 확장에 대한 모범 사례

  • 결론

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

브라우저 확장 프로그램을 클릭할 때마다 사용자에게 권한을 부여하거나 접근성이 디자인의 일부가 아닌 경우 사용자를 배제할 수 있는 기회가 됩니다.

브라우저 확장 프로그램은 고유한 접근성 인터페이스를 유지하면서 기존 웹 페이지에 기능을 주입해야 하기 때문에 고유한 접근성 문제에 직면해 있습니다. 이는 잠재적인 장벽을 초래할 수 있는 이중 책임입니다. 예를 들어, 키보드 사용자를 가두는 팝업이나 스크린 리더와의 통신에 실패하면 확장 프로그램을 사용할 수 없게 될 수 있습니다.

세계보건기구(WHO)에 따르면 10억 명 이상의 장애인이 살고 있는 가운데 접근성 높은 디자인은 광범위한 사용자 기반을 확보하고 모두를 위한 더 나은 경험을 제공합니다.

포괄적인 브라우저 확장 구축:단계별 접근성 디자인

브라우저 확장의 경우 접근성 장벽은 일반적으로 다음과 같이 나타납니다.

  • 키보드 탐색 막다른 골목 :키보드 사용자를 가두거나 배제하는 팝업 및 인터페이스.

  • 조용한 상호작용 :스크린 리더에서 '라벨이 없는 버튼'으로 표시되는 아이콘만 있는 버튼과 같이 라벨과 설명이 누락되어 사용자가 해당 목적을 추측하게 됩니다.

  • 예고되지 않은 동적 콘텐츠 업데이트 :로드 상태 또는 오류에 대한 피드백 누락을 포함하여 화면 리더에게 변경 사항을 알리지 않고 견적을 업데이트하는 등 보조 기술 인식 없이 발생하는 콘텐츠 변경

  • 컨텍스트 통합 충돌 :기존 웹페이지를 수정하는 확장 프로그램은 실수로 페이지의 접근성 기능을 손상시키거나 기존 탐색 패턴과 충돌하는 요소를 도입할 수 있습니다.

이러한 장벽을 이해함으로써 개발자는 확장 프로그램의 접근성을 테스트하고 개선하기 위한 목표 단계를 수행할 수 있습니다.

수동 브라우저 확장 접근성 테스트를 수행하는 방법

자동화된 도구는 명백한 문제를 포착하지만 수동 테스트는 실제 사용자 경험을 드러냅니다. 확장 프로그램의 접근성을 체계적으로 평가하는 방법은 다음과 같습니다.

키보드 탐색 테스트

마우스를 분리하고 키보드만으로 확장 기능을 완전히 사용해 보십시오. Tab를 사용하여 탐색 요소 사이를 이동하려면 Enter 또는 Space 구성 요소 내의 버튼과 화살표 키를 활성화합니다.

  • 어떤 요소에 초점이 있는지 항상 명확합니까?

  • Enter로 버튼을 활성화할 수 있나요? 또는 Space 예상대로?

  • 사용자가 모달 대화상자나 드롭다운 메뉴를 종료할 수 있나요?

막다른 골목이나 혼란스러운 지점에 직면하게 되면 키보드 사용자도 동일한 장벽에 직면하게 됩니다.

포괄적인 브라우저 확장 구축:단계별 접근성 디자인

스크린 리더 평가

운영 체제에 내장된 화면 판독기를 사용하여 확장 프로그램을 탐색하고 발표되는 내용을 들어보세요. macOS에서는 VoiceOver를 활성화합니다. Windows에서는 내레이터를 사용하세요. Linux에서는 Orca를 사용해 보세요.

  • 단순한 '버튼'이 아닌 '새로운 조언 생성'이라는 버튼이 표시되는 등 각 요소의 목적이 명확하게 전달됩니까?

  • 제목, 목록 및 기타 구조가 올바르게 전달됩니까?

  • 콘텐츠가 로드되거나 선택되거나 변경되는 시점을 사용자가 이해합니까?

이 테스트 단계에서는 전달하려는 내용과 실제로 사용자에게 도달하는 내용 사이의 격차가 드러나는 경우가 많습니다.

시각적 접근성 검토

다양한 시각적 컨텍스트에서 확장을 검토하세요. WebAIM의 대비 검사기와 같은 개발자 도구를 사용하여 텍스트가 가독성을 위해 WCAG의 4.5:1 대비율을 충족하는지 확인하세요. 시스템 고대비 설정에서 확장 프로그램이 어떻게 표시되는지 테스트하세요. 다음을 확인하세요:

  • 200% 확대/축소에서도 기능을 계속 사용할 수 있습니다.

  • 색상으로 구분된 표시기와 함께 텍스트 라벨을 사용하는 등 색상만으로는 정보가 전달되지 않습니다.

이러한 수동 테스트는 중요한 접근성 문제를 밝혀내고 확장 프로그램을 포괄적으로 만들기 위한 목표 개선의 길을 열어줍니다.

브라우저 확장 접근성 개선을 구현하는 방법

무슨 일이 일어났는지 알지 못한 채 페이지를 새로 고치거나 명확한 목적 없이 버튼을 클릭한다고 상상해 보세요. 위에서 수행한 수동 테스트를 통해 다음 세 가지 주요 접근성 문제 중 확장 프로그램의 화면 판독기 사용자 경험이 밝혀졌습니다.

  • 버튼 라벨 누락 :주사위 버튼에는 대체 텍스트 "주사위 아이콘"이 포함된 이미지만 있으며 화면 리더에 필요한 컨텍스트가 부족합니다.

  • 자동 동적 업데이트 :새로운 조언이 로드되면 스크린 리더는 내용이 변경되었음을 알 수 없습니다.

  • 로드 상태 없음 :조언을 가져올 때 사용자는 어떤 일이 일어나고 있다는 피드백을 받지 못합니다.

자동화된 테스트를 수행하기 전에 문제를 해결해 봅시다.

누락된 버튼 라벨 및 대체 텍스트를 해결하는 방법

aria-label를 추가하겠습니다. 버튼의 목적을 명확하게 설명하고 아이콘에 대한 설명 대체 텍스트를 제공합니다. 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');
 }
}

수동 테스트 문제가 해결되었으므로 이제 동일한 확장 프로그램에 대한 자동 테스트를 수행할 수 있습니다.

자동화된 브라우저 확장 접근성 테스트를 수행하는 방법

수동 테스트는 중요한 통찰력을 제공하지만 자동화된 도구는 일반적인 문제를 효율적으로 포착하고 지속적인 모니터링을 제공할 수 있습니다.

이 확장 접근성 검사기는 WCAG 준수를 위해 팝업 및 콘텐츠 스크립트와 같은 브라우저 확장 인터페이스를 분석하여 테스트를 단순화하고 팝업 제약 조건 및 콘텐츠 삽입 충돌과 같은 고유한 문제를 해결합니다.

포괄적인 브라우저 확장 구축:단계별 접근성 디자인

확장 접근성 검사기를 사용하려면:

  1. 브라우저 확장 폴더를 .zip 파일로 압축하세요

  2. https://extensiona11ychecker.vercel.app/에 .zip 파일을 업로드하세요.

  3. 특정 접근성 위반에 대해 생성된 보고서를 검토하고 제안된 수정 사항을 구현하세요.

위의 GIF에서 볼 수 있듯이 이 워크플로는 접근성을 나중에 고려하는 것이 아니라 개발 프로세스의 일상적인 부분으로 설정하는 데 도움이 됩니다.

자동화된 테스트를 통해 개발 전반에 걸쳐 확장 프로그램에 계속 액세스할 수 있도록 모범 사례를 살펴보겠습니다.

액세스 가능한 브라우저 확장에 대한 모범 사례

우리는 기능적이지만 액세스할 수 없는 도구에서 모든 사람에게 작동하는 포괄적인 도구로 샘플 조언 생성 브라우저 확장을 변형했습니다.

개선 사항을 바탕으로 접근 가능한 브라우저 확장 프로그램을 설계하기 위한 네 가지 주요 원칙은 다음과 같습니다.

  1. 의미 있는 HTML과 명확하고 설명적인 라벨

ARIA 속성을 추가하기 전에 항상 적절한 요소(예:"조언 생성" 작업, 적절한 제목 계층 구조)를 사용하여 적절한 HTML 구조로 시작하세요.

aria-label을 통해 모든 상호작용 요소가 명확한 목적을 갖고 있는지 확인하세요. , aria-labelledby , 또는 해당 작업을 설명하는 눈에 보이는 텍스트입니다.

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

모든 상호작용 요소는 목적을 효과적으로 전달해야 합니다. 사용자는 다음 사항을 이해해야 합니다.

    • 무슨 일이 일어나고 있나요(예:상태 로드에 대한 "새 조언 로드 중…")

      • 무엇이 잘못됐나요(예:오류에 대한 "조언을 로드하지 못했습니다")

      • 변경된 사항(예:업데이트된 콘텐츠의 aria-live 영역)

  1. 완벽한 키보드 접근성

모든 기능은 키보드 탐색을 통해 사용할 수 있어야 합니다. Tab로 테스트해야 합니다. , Enter , Space , 및 화살표 키를 적절하게 사용하세요.

모달이나 복잡한 상호 작용을 종료하는 명확한 방법을 통해 인터페이스를 통해 예측 가능하게 이동하는 명확하고 사려 깊은 초점 표시기를 제공하세요.

  1. 사용자 기본 설정 및 콘텐츠 스크립트 고려 사항

시스템 글꼴 크기 설정을 지원하고 사용자 정의 색 구성표를 불필요하게 재정의하지 않음으로써 사용자 선택을 존중합니다.

확장 프로그램이 기존 웹 페이지를 수정하는 경우 페이지의 설정된 접근성 기능, 포커스 관리 및 탐색 패턴을 손상시키지 않는지 확인하세요. 삽입하는 새로운 요소가 접근성 표준을 준수하는지 확인하세요.

결론

조언 생성 확장 프로그램에서 살펴본 것처럼 접근성 문제를 해결하면 기능적 도구가 포괄적인 도구로 변환됩니다.

그러나 기존 확장 프로그램의 문제를 해결하는 것도 도움이 되지만, 가장 효과적인 접근 방식은 코드 첫 줄부터 접근성을 통해 디자인 및 개발 결정을 내리는 것입니다.

다음 브라우저 확장 프로젝트를 시작할 때 다음을 물어보세요:

  • 키보드만 사용하여 어떻게 탐색할 수 있을까요?

  • 모든 대화형 요소의 목적이 스크린 리더에게 즉시 명확해 집니까?

  • 사용자는 로드 상태 중에 무슨 일이 일어나고 있는지 어떻게 이해할 수 있나요?

다음은 유용한 자료입니다.

  • Chrome 확장 프로그램 접근성 문서

  • 확장 프로그램 접근성 검사기

  • 웹 콘텐츠 접근성 지침(WCAG) 2.1

무료로 코딩을 배우세요. freeCodeCamp의 오픈 소스 커리큘럼은 40,000명 이상의 사람들이 개발자로 취업하는 데 도움을 주었습니다. 시작하세요