수동 테스트와 보조기술 테스트

키보드 수동 테스트 프로토콜

The Keyboard Testing Protocol

수동 테스트의 첫 단계는 마우스를 치우는 것입니다. 점검 항목: Tab으로 모든 인터랙티브 요소에 도달 가능한가, 포커스 순서가 시각적·논리적 순서와 일치하는가, 포커스 표시가 항상 명확히 보이는가, Enter/Space로 버튼·링크가 작동하는가, 복합 위젯 내부는 화살표 키로 이동되는가, Esc로 모달·메뉴가 닫히는가, 키보드 트랩이 없는가.

Step one of manual testing: put the mouse away. Check that Tab reaches every interactive element, focus order matches the visual and logical order, the focus indicator is always clearly visible, Enter/Space activate buttons and links, arrow keys move within composite widgets, Esc closes modals and menus, and there are no keyboard traps.

자주 발견되는 결함 패턴: 마우스 호버로만 열리는 드롭다운(키보드로 열 수 없음), 커스텀 체크박스가 Space에 반응하지 않음, 캐러셀 다음 슬라이드로 포커스가 따라가지 않음, 무한 스크롤 뒤 푸터에 도달 불가. 키보드 테스트는 도구 없이 몇 분 만에 심각한 결함을 드러내는 가장 가성비 높은 검사입니다.

Common defect patterns: dropdowns that open only on mouse hover, custom checkboxes ignoring Space, carousels whose focus doesn't follow the next slide, footers unreachable behind infinite scroll. Keyboard testing is the highest-value check there is — minutes, no tools, and it exposes severe defects.

화면낭독기 테스트

Screen Reader Testing

주요 조합과 기본 조작: NVDA(Windows, 무료)는 Insert+Space로 탐색/포커스 모드 전환, H로 제목 이동, D로 랜드마크 이동. JAWS(Windows, 유료)는 Insert+F6 제목 목록, Insert+F7 링크 목록. VoiceOver(macOS)는 Cmd+F5로 켜고 VO키(Ctrl+Option)+방향키로 탐색, VO+U로 로터 메뉴. 권장 조합: NVDA+Chrome/Firefox, JAWS+Chrome/Edge, VoiceOver+Safari.

Key pairings and basics: NVDA (Windows, free) — Insert+Space toggles browse/focus mode, H moves by heading, D by landmark. JAWS (Windows, commercial) — Insert+F6 headings list, Insert+F7 links list. VoiceOver (macOS) — Cmd+F5 to toggle, VO key (Ctrl+Option)+arrows to navigate, VO+U for the rotor. Recommended pairings: NVDA+Chrome/Firefox, JAWS+Chrome/Edge, VoiceOver+Safari.

탐색 모드와 포커스 모드의 구분이 중요합니다. 탐색(browse) 모드에서는 H·D·K 같은 단축키가 문서 탐색에 쓰이고, 입력 필드에 들어가면 포커스(forms) 모드로 전환되어 키 입력이 필드로 전달됩니다. 커스텀 위젯이 모드 전환을 방해하면 낭독기 사용자는 입력을 못 하거나 탐색을 못 하게 됩니다.

The browse-versus-focus mode distinction matters. In browse mode, keys like H, D, and K navigate the document; entering an input switches to focus (forms) mode where keystrokes go to the field. Custom widgets that break mode switching leave users unable to type — or unable to navigate.

확인할 것: 모든 정보가 음성으로 전달되는가, 이미지·버튼의 이름이 의미 있는가, 동적 변경(오류, 알림, 결과 갱신)이 낭독되는가, 표는 행·열 헤더와 함께 읽히는가. 첫 화면낭독기 테스트라면 눈을 감거나 화면을 끄고 과업을 수행해보는 것이 가장 배우는 것이 많습니다.

Verify: is all information conveyed in speech; do images and buttons have meaningful names; are dynamic changes (errors, notifications, updated results) announced; are tables read with row and column headers? For your first screen reader test, closing your eyes or turning off the display while completing a task teaches the most.

확대·대비·표시 설정 점검

Zoom, Contrast, and Display Checks

저시력 관점 수동 점검: 브라우저 확대 200%에서 콘텐츠와 기능이 유지되는가(1.4.4), 400%(320px 폭 상당)에서 가로 스크롤 없이 리플로우되는가(1.4.10), 텍스트 간격을 사용자 스타일로 키워도 잘리지 않는가(1.4.12), OS 고대비 모드에서 UI가 살아있는가.

Low-vision manual checks: does content survive 200% browser zoom (1.4.4); does it reflow without horizontal scrolling at 400% (equivalent to 320px width, 1.4.10); does text remain intact when user styles increase text spacing (1.4.12); does the UI hold up in OS high-contrast modes?

그 밖의 수동 체크리스트: 이미지 대체 텍스트의 적절성, 제목 계층의 논리성, 폼 레이블 연결, 색상 단독 정보 전달 여부, 자동 재생 콘텐츠 정지 수단, prefers-reduced-motion 반영 여부. 이 항목들이 자동 도구가 놓치는 60~70%의 핵심입니다.

The rest of the manual checklist: appropriateness of alt text, logical heading hierarchy, form label association, color-only information, means to stop auto-playing content, and honoring prefers-reduced-motion. These items are the heart of the 60–70% that automation misses.

장애인 사용자 테스트

Testing with Disabled Users

실제 장애인 사용자가 참여하는 테스트가 가장 가치 있습니다. 시각·청각·운동·인지 등 다양한 장애 유형과 보조기술 사용자를 포함하고, 과업 기반 시나리오(회원가입 완료하기, 상품 결제하기)로 진행합니다. 참가자가 5명 안팎이어도 주요 사용성 문제의 대부분이 드러납니다.

Testing with actual disabled users is the most valuable. Include diverse disability types — visual, auditory, motor, cognitive — and AT users, and run task-based scenarios (complete signup, check out a product). Even around five participants surface most major usability problems.

운영 시 유의점: 참가자의 자기 기기·자기 보조기술 사용을 우선하고(익숙한 설정이 실제 사용을 반영), 보상·모집 문서·테스트 장소의 접근성을 보장하며, '사용자를 테스트하는 것이 아니라 제품을 테스트한다'는 점을 명확히 합니다. 발견 사항은 적합성 위반이 아니어도 개선 백로그에 담을 가치가 있습니다.

Operational notes: prefer participants' own devices and assistive technologies (familiar settings reflect real use), ensure the accessibility of compensation, recruitment materials, and venues, and make clear you are testing the product, not the user. Findings deserve a place in the improvement backlog even when they aren't conformance violations.