접근성 테스트란 무엇입니까? (예시)

접근성 테스트란 무엇입니까?

접근성 테스트 이는 시각, 청각, 운동, 인지 및 노화 관련 장애를 포함한 장애인이 애플리케이션을 사용할 수 있는지 확인하기 위해 수행되는 소프트웨어 테스트 유형입니다. 이는 소프트웨어 개발의 하위 범주입니다. 사용성 테스트 또한 해당 제품이 사용자들이 매일 사용하는 보조 기술과 호환되는지 확인합니다.

보조 기술은 장애가 있는 사람들이 소프트웨어 제품을 사용할 수 있도록 도와줍니다. 일반적인 예로는 다음과 같은 것들이 있습니다.

• 음성 인식 소프트웨어 – 음성을 컴퓨터 입력으로 사용할 수 있는 텍스트로 변환합니다.
• 스크린 리더 소프트웨어 – 화면에 표시된 텍스트와 인터페이스 요소를 읽어줍니다.
• 화면 확대 소프트웨어 - 시력이 낮은 사용자가 읽기 쉽도록 모니터의 일부를 확대합니다.
• 특수 키보드 - 운동 조절에 어려움이 있는 사용자를 위해 설계되었습니다.ping 쉬워집니다.
• 스위치와 눈-trac킹 디바이스 - 심각한 운동 장애가 있는 사용자가 인터페이스 요소를 탐색하고 선택할 수 있도록 합니다.

왜 접근성 테스트인가?

이유 1장애인 사용자를 대상으로 시장을 공략합니다.

세계보건기구에 따르면 전 세계적으로 약 1.3억 명, 즉 6명 중 1명꼴로 심각한 장애를 안고 살아가고 있습니다.

• 10명 중 1명은 심각한 장애를 가지고 있습니다.
• 65세 이상 인구의 절반은 신체 기능이 저하되어 있습니다.

장애에는 시각 장애, 청각 장애, 운동 장애, 인지 장애 및 기타 장기적인 건강 문제가 포함됩니다. 접근성을 고려하여 개발된 제품은 이러한 거대한 시장에 진출할 수 있으며, 접근성 테스트를 일반적인 소프트웨어 테스트 수명 주기에 포함시키면 대부분의 접근성 결함을 예방할 수 있습니다.

이유 2접근성 관련 법규를 준수하십시오.

전 세계 정부는 장애인이 IT 제품에 접근할 수 있도록 요구하는 법률을 제정했습니다. 주요 사례는 다음과 같습니다.

• 미국: 장애인 차별 금지법(ADA, 1990) 및 재활법 제508조.
• 영국: 2010년 평등법(1995년 장애인 차별금지법을 대체함).
• 유럽 ​​연합: 2025년 6월부터 많은 제품 및 서비스에 적용되는 유럽 접근성법(European Accessibility Act) 및 EN 301 549 표준.
• 호주: 장애인 차별 금지법 1992.
• 아일랜드: 장애인법 2005.
• 캐나다: 접근성 높은 캐나다 법 2019.

접근성 테스트는 제품이 판매되는 모든 시장에서 법적 규정을 준수하는 데 필수적입니다.

이유 3소송 가능성을 피하세요.

대기업들은 자사의 디지털 제품에 대한 접근성이 부족하다는 이유로 여러 차례 소송을 당했습니다. 대표적인 사례로는 다음과 같은 것들이 있습니다.

• 전미맹인연맹(NFB) 대 Target (2006년, 2008년 정착).
• NFB 대 AOL 합의 (1999).
• Robles v. Domino's Pizza (2019), 미국 Suprem법원은 ADA가 웹사이트와 모바일 앱에도 적용된다는 판결을 유지했습니다.
• Gil v. Winn-Dixie(2017)는 접속 불가능한 웹사이트를 수정하도록 요구하는 최초의 미국 재판 판결입니다.

미국에서 웹 접근성 관련 소송은 매년 증가하고 있으며, 2022년 이후 매년 4,000건 이상의 ADA(미국 장애인법) 제3조 디지털 접근성 관련 소송이 제기되고 있습니다. 처음부터 접근성이 뛰어난 제품을 개발하면 이러한 비용을 절감하고 브랜드 가치를 보호할 수 있습니다.

어떤 장애를 지원해야 합니까?

해당 애플리케이션은 다음과 같은 장애인을 지원해야 합니다.

장애 유형	무능 Descript이온
시각 장애	완전 실명, 색맹 또는 저시력. 시각적 섬광 및 점멸 효과에 대한 민감성.
신체 장애	한 손으로 마우스나 키보드를 사용할 수 없음. 운동 기능 저하, 예를 들어 손 움직임 제한 또는 근육 운동 완만.
인지 장애	학습 장애, 기억력 저하 또는 복잡한 상황을 이해하는 데 어려움.
읽고 쓰는 능력 장애	난독증과 같은 읽기 어려움.
청각 장애	청각 장애, 특히 난청 및 청력 손상과 같은 청각 관련 문제. 소리를 듣지 못하거나 소리를 명확하게 듣지 못하는 상태.

접근성 표준 및 지침

접근성 테스트 프로그램은 널리 채택된 소수의 표준에 의존합니다. 테스트 계획을 수립하기 전에 먼저 해당 시장에 적용되는 표준을 파악하는 것이 중요합니다.

• WCAG 2.2 2023년 10월 W3C에서 발표한 웹 콘텐츠 접근성 지침 2.2는 현재 전 세계적인 기준입니다. 이 지침은 A(기본), AA(대부분의 국가에서 법적 최소 기준), AAA(최고 수준)의 세 가지 준수 수준을 정의합니다.
• WCAG 3.0 – 결과 기반 점수 모델을 도입한 W3C 워킹 드래프트입니다. 아직 개발 중이며 WCAG 2.2를 대체하지는 않습니다.
• 제 508 - 미국 연방 조달 규정으로, 연방 기관이 구매하는 전자 및 정보 기술은 WCAG 2.0 레벨 AA 기준을 충족해야 합니다.
• 301 549 - 유럽 접근성법 준수 여부를 입증하는 데 사용되는 ICT 접근성 관련 유럽 통합 표준.
• ADA 제3장 - 공공시설 웹사이트 및 모바일 앱에 적용되는 미국 민권법; 법원에서는 일반적으로 WCAG 2.1 또는 2.2 AA를 기준으로 사용합니다.

대부분의 팀은 WCAG 2.2 레벨 AA 그것이 공통적인 법적 기준선이자 실질적인 엔지니어링 목표이기 때문에 그들의 업무 목표로 삼는 것입니다.

접근성 테스트를 수행하는 방법은 무엇입니까?

접근성 테스트는 두 가지 방법으로 수행할 수 있습니다.

1. Manual
2. 자동화

장애에 익숙하지 않은 테스터에게는 접근성 테스트가 어려울 수 있습니다. 실제 사용 환경에서 발생할 수 있는 어려움을 설명해 줄 수 있는 장애인 사용자 또는 접근성 전문가를 참여시키는 것이 가장 좋습니다. 아래의 기법들은 주요 장애 유형을 다룹니다.

1) 시각장애

시각 장애가 있는 상태에서 XYZ 웹사이트를 이용해야 한다고 상상해 보세요. 이 경우 유일하게 현실적인 선택지는 화면 낭독기입니다. 화면 낭독기는 시각 장애인이 웹 페이지의 텍스트, 링크, 라디오 버튼, 이미지, 비디오 등의 콘텐츠를 읽어주는 소프트웨어로, 웹사이트 인터페이스를 인지할 수 있도록 도와줍니다. 인기 있는 화면 낭독기로는 다음과 같은 것들이 있습니다. 입 부분, NVDA애플 보이스오버, 그리고 Android 토크백.

JAWS를 실행한 다음 브라우저를 열면 JAWS가 페이지 제목을 읽어줍니다. 주소 표시줄에 포커스를 맞추면 JAWS가 "주소 표시줄"이라고 말한 후 사용자가 입력하는 각 문자를 읽어줍니다. 예를 들어, typing google.com에서는 다음과 같은 공지사항을 표시합니다.

Address Bar, w, w, w, period, g, o, o, g, l, e, period, c, o, m.
When the page finishes loading, JAWS announces "Google.com home page".
When focus reaches the search field, JAWS announces "Google search, edit".

스크린 리더는 텍스트 필드 안의 내용을 단어 단위로 읽어주고, 링크는 "링크"라고, 버튼은 "버튼"이라고 읽어주어 시각 장애인 사용자가 각 요소를 식별할 수 있도록 돕습니다. 하지만 웹사이트가 제대로 구축되지 않은 경우, 스크린 리더가 요소를 잘못 인식할 수 있습니다. 예를 들어, 일반 텍스트로 스타일링된 링크가 콘텐츠로 인식되어 사용자가 중요한 작업을 수행할 수 없게 될 수 있습니다. 이러한 문제는 기업에게 실질적인 매출 손실로 이어질 수 있습니다.

2) 색맹

색맹이란 사용자가 특정 색상을 정확하게 인지하지 못하는 것을 의미합니다. 적록색맹이 가장 흔한 유형입니다. 웹사이트가 의미 전달에 빨간색을 많이 사용하는 경우, 적록색맹 사용자는 해당 메시지를 놓칠 수 있습니다.

디자인 팀은 정보를 전달할 때 색상만 사용해서는 안 됩니다. 빨간색 오류 버튼은 테두리가 있고 아이콘으로 레이블이 지정되어 있으며 설명 텍스트가 함께 제공될 때 접근성이 훨씬 높아집니다. 흑백은 여전히 ​​가장 안전하고 보편적인 색상 조합이며, Stark 플러그인이나 브라우저 색맹 시뮬레이터와 같은 도구를 사용하면 문제를 조기에 발견할 수 있습니다.

3) 저시력

시력이 약하거나 기타 망막 질환이 있는 사용자는 사이트를 이용하기 위해 추가적인 지원이 필요합니다.

1. 너무 작은 글씨는 피하세요. WCAG에서는 확대/축소 없이도 보기 좋게 크기가 조절되는 기본 본문 크기를 권장합니다.
2. 텍스트 크기를 최대 200%까지 확대했을 때 레이아웃이 깔끔하게 재배치되는지 확인하십시오(WCAG 2.2 성공 기준). 줄 바꿈이 발생하거나 콘텐츠가 겹치지 않아야 합니다.
3. 일반 텍스트의 경우 최소 4.5:1, 큰 텍스트의 경우 최소 3:1의 명암비를 유지하십시오.

4) 운동 및 기타 장애

접근성 관련 주요 요구 사항 중 하나는 사이트 전체를 마우스 없이 조작할 수 있어야 한다는 것입니다. 모든 링크, 버튼, 라디오 버튼, 체크박스, 팝업, 드롭다운 및 컨트롤은 키보드만으로 접근하고 조작할 수 있어야 합니다.

예를 들어손의 움직임이 제한적인 사용자는 마우스를 사용하지 못할 수 있습니다. 탭 키로 체크박스나 링크에 접근할 수 없는 경우, 사용자는 해당 기능을 사용할 수 없게 됩니다.

Alternative text should be provided for every image, audio file, and video so that screen readers can convey their meaning. Keyboard shortcuts should be available for important actions, and skip-to-content links should let keyboard users bypass repeated navigation.

포커스는 항상 눈에 띄어야 합니다. 사용자가 Tab 키를 누르면 강조 표시된 컨트롤이 명확하게 드러나야 합니다. 눈에 띄는 포커스는 시력이 약하거나 색맹인 사용자가 페이지의 흐름을 쉽게 파악할 수 있도록 도와주고, 모든 사용자에게 예측 가능한 탐색 환경을 제공합니다.

청각 장애가 있는 사용자 일반적으로 웹사이트의 시각적 콘텐츠는 볼 수 있지만, 오디오와 비디오는 문제가 될 수 있습니다. 모든 비디오에는 자막이 포함되어야 하고, 모든 오디오 파일에는 스크립트 또는 설명 텍스트가 포함되어야 합니다. 예를 들어 항공권 예약 방법에 대한 튜토리얼 비디오는 청각 장애 사용자가 내용을 이해할 수 있도록 정확한 자막과 함께 제공되어야 합니다.

접근성 테스트를 위한 샘플 테스트 케이스

아래 체크리스트는 일반적인 웹 애플리케이션의 접근성 테스트를 완료하고 승인하는 데 사용됩니다. 이를 시작점으로 삼아 제품에 맞는 WCAG 2.2 성공 기준을 추가하여 확장하십시오.

1. 마우스 조작 및 대화창에 해당하는 키보드 동작이 모두 제공되나요?
2. 사용자 설명서에 보조 기술을 사용하여 애플리케이션을 작동하는 방법이 설명되어 있습니까?
3. 탭 순서가 논리적이어서 자연스러운 탐색이 가능한가요?
4. 주요 메뉴에 대한 단축키가 제공되나요?
5. 해당 애플리케이션은 대상 운영 체제 및 화면 판독기를 모두 지원합니까?
6. 각 화면이나 페이지의 응답 시간이 명확하게 표시되어 사용자가 얼마나 기다려야 하는지 알 수 있습니까?
7. 모든 레이블이 올바르게 작성되었고 프로그램적으로 해당 컨트롤에 연결되어 있습니까?
8. 색상 선택이 유연하고 색맹 시뮬레이터를 통해 검증되었습니까?
9. 이미지, 아이콘, 이모티콘은 최종 사용자가 이해할 수 있는 방식으로 사용되고 있습니까?
10. 해당 애플리케이션은 필요한 경우 음성 알림을 제공합니까?
11. 사용자가 오디오 및 비디오 제어 기능을 조정하거나 음소거할 수 있습니까?
12. 사용자가 인쇄 및 화면 텍스트에 대한 기본 글꼴을 재정의할 수 있습니까?
13. 사용자가 깜빡임, 회전 또는 움직이는 디스플레이를 조정하거나 비활성화할 수 있습니까?
14. 색상이 정보를 전달하는 유일한 수단으로 사용되지 않도록 확인하십시오.
15. 시스템 색상을 반전시켰을 때 강조 표시된 부분이 여전히 보이는지 확인해 보세요. 명암비를 변경하면서 테스트해 보십시오.
16. 청각 장애가 있는 사용자를 위해 오디오 및 비디오 스크립트 또는 자막이 제공되나요?
17. 장애가 있는 사용자가 애플리케이션에 익숙해질 수 있도록 교육이 제공되나요?
18. 모든 대화형 컨트롤에 키보드만 사용하여 접근하고, 조작하고, 닫을 수 있습니까?

AI가 접근성 테스트를 어떻게 변화시키고 있는가

AI는 레샤입니다ping 접근성 테스트는 세 가지 실용적인 방식으로 이루어집니다. 첫째, 머신러닝 스캐너는 컴퓨터 비전 모델과 함께 렌더링된 DOM을 읽어 규칙 기반 도구가 놓치는 문제, 예를 들어 부적절한 대체 텍스트나 실제 레이아웃에서 제대로 작동하지 않는 색상 조합 등을 감지합니다. 둘째, 생성형 AI는 더 나은 대체 텍스트, 명확한 오류 메시지, 사용자 정의 구성 요소에 대한 ARIA 속성 등 사람이 읽기 쉬운 수정 사항을 제안합니다. 셋째, AI는 사용자에게 미치는 영향을 기준으로 발견 사항의 우선순위를 지정하므로 팀은 가장 중요한 문제에 예산을 집중할 수 있습니다. Deque axe AI, Evinced, UserWay, Siteimprove와 같은 도구에는 이제 AI 기능이 포함되어 있습니다. AI는 수동 스크린 리더 테스트나 장애인을 대상으로 한 사용자 연구를 대체하는 것은 아니지만, 수동 분류 작업량을 크게 줄이고 접근성을 개발 주기 초기에 반영할 수 있도록 지원합니다.

접근성 테스트에 대한 오해

다음은 접근성 테스트에 대한 일반적인 오해와 사실입니다.

신화: 접근성 좋은 웹사이트를 만드는 데는 비용이 많이 듭니다.

것: 그렇지 않습니다. 설계 단계에서 접근성을 고려하고 기본적인 테스트를 수행하면 나중에 개조하는 것보다 비용을 절감하고 값비싼 재작업을 줄일 수 있습니다.

신화: 접근성이 떨어지는 웹사이트를 접근성 있는 웹사이트로 바꾸는 것은 시간과 비용이 너무 많이 듭니다.

것: 모든 수정 사항을 한 번에 적용할 필요는 없습니다. 장애가 있는 사용자에게 가장 큰 영향을 미치는 변경 사항부터 시작하고 나머지는 추후 릴리스에서 적용하세요.

신화: 접근성은 평범하고 지루하다.

것: 페이지는 여전히 시각적으로 풍부할 수 있습니다.tracWCAG 2.2 가이드라인을 준수하면서 접근성을 높였습니다. W3C는 모든 사람에게 단일 접근성 환경을 제공하기 위해 텍스트 전용 버전을 명시적으로 권장하지 않습니다.

신화: 접근성 기능은 시각 장애인 및 기타 장애인 사용자만을 위한 것입니다.

것: 접근성 지침을 준수하면 전반적인 사용성이 향상되고 모바일 기기 사용자, 밝은 햇빛 아래 사용자, 시끄러운 환경 사용자 등 모든 사용자에게 도움이 됩니다.

자주 묻는 질문