널리

들어가며

안녕하세요. 엔비전스입니다.

지금까지 여정을 통해 1부에서 UIA의 개념을 살펴보고, 2부에서 WinUI 3로 접근성을 구현하고, 3부와 4부에서 Win32 API로 UIA Provider를 직접 구현해보았습니다. 이번 마지막 글에서는 구현한 접근성이 올바르게 동작하는지 검증하는 방법을 다룹니다.

검증에 앞서 반드시 이해해야 할 개념이 있습니다. 앱의 Visual Tree와 UIA 접근성 트리는 다릅니다. Visual Studio의 Live Visual Tree나 Spy++는 앱의 시각적 요소 계층을 보여주지만, 스크린 리더가 실제로 사용하는 UIA 요소 트리, 속성, Control Patterns, 이벤트를 확인하려면 UIA 전용 검사 도구가 필요합니다.

이 글에서는 두 가지 핵심 도구를 중점적으로 다룹니다. 일상적인 접근성 점검에 가장 적합한 Accessibility Insights for Windows와 UIA 트리 구조를 깊이 분석할 때 유용한 Inspect.exe입니다.

Accessibility Insights for Windows

Accessibility Insights for Windows는 Microsoft가 개발하고 오픈소스로 공개한 접근성 검증 도구입니다. 2026년 현재까지 업데이트되고 있으며, Microsoft도 Windows 앱 접근성 테스트 문서에서 이 도구를 가장 먼저 사용할 것을 권장합니다.

설치 및 실행

공식 사이트에서 MSI 설치 파일을 다운로드하여 설치합니다. 한 가지 주의할 점은 관리자 권한으로 실행 중인 앱을 검사하려면 Accessibility Insights도 관리자 권한으로 실행하거나, 설치 디렉터리의 UIAccess.cmd Enable을 관리자 명령 프롬프트에서 실행해야 합니다. 가능하다면 대상 앱을 일반 권한으로 실행하는 것이 간편합니다.

Live Inspect: 실시간 속성 확인

Live Inspect는 가장 자주 사용하게 될 기능입니다. 대상 앱의 요소 위에 마우스를 올리거나 키보드 포커스를 이동하는 것만으로, 해당 요소의 UIA 속성을 실시간으로 확인할 수 있습니다.

사용 방법은 다음과 같습니다. Accessibility Insights를 실행하면 기본적으로 Live Inspect 모드로 진입합니다. 상단의 "What to select"를 Element로 설정한 뒤, 검사할 앱의 요소 위로 마우스를 이동합니다. 선택된 요소가 시각적으로 강조되며, 오른쪽 Details 탭에 ControlType, Name, Properties, Patterns 정보가 표시됩니다. 특정 요소를 고정하여 살펴보고 싶다면 상단의 "Pause UIA Tree" 버튼을 누릅니다.

기본 화면에서는 컨트롤 타입에 따른 주요 속성만 표시됩니다. 더 많은 속성을 보려면 UIA Tree Properties Settings에서 "Include all properties that have values"를 선택합니다. 특정 속성을 항상 표시하도록 고정하는 것도 가능합니다.

Details의 Patterns 영역에서는 해당 요소가 지원하는 Control Pattern을 확인합니다. 예를 들어 슬라이더 위젯이라면 RangeValuePattern이 표시되어야 하고, 커스텀 버튼이라면 InvokePattern이 노출되어야 합니다. 예상 패턴과 실제 노출된 패턴이 일치하는지 대조하는 것이 검증의 핵심입니다.

Note: 스크린 리더 사용자를 위한 팁

Accessibility Insites for Windows는 크게 네 영역으로 분할됩니다. 첫째 영역은 인스펙트 모드를 실행하거나, FastPass 테스트 모드, 명도대비 검사 모드, 설정이 있는 메인입니다. 두 번째 영역은 요소 단위를 검사할지 아니면 전체 앱을 검사할지를 선택하는 검사 유형 영역입니다. 세 번째는 현재 열려있는 애플리케이션의 UI 트리로 보여주는 트리 화면 영역입니다. 마지막으로 선택한 요소의 속성 즉, Accessible Name, Pattern, 키보드 접근 여부 등을 표시하는 Details 영역이 위치하고 있습니다. 이 영역 사이를 이동할 때는 일반적인 Tab 키와 Shift + Tab 키가 아닌 f6 키와 Shift + f6 키를 사용해야 합니다.

또한, 특정 앱의 구간을 이동하면서 이벤트를 캡처하는 접근성 검사 시 캡처/중지에 따른 별도의 사운드 피드백이 제공됩니다. Shift + f7 키로 이벤트 기록 시작과 중지를 토글할 수 있습니다.

FastPass: 자동 접근성 검사

FastPass는 60개 이상의 접근성 규칙을 자동으로 검사하여 주요 문제를 빠르게 찾아주는 기능입니다. 두 단계로 구성되어 있습니다. 첫째는 자동 검사(Automated checks)로, Name 속성 누락이나 잘못된 속성 값 같은 일반적인 문제를 탐지합니다. 둘째는 Tab stops 검사로, 키보드 탐색 순서가 올바른지 시각적으로 확인할 수 있습니다.

앱 전체를 검사하려면 "What to select"를 Entire app으로 설정하고 대상 앱 위에서 Shift+F8을 누릅니다. 특정 요소와 그 하위 트리만 검사하고 싶다면 Element 모드에서 동일한 방법으로 실행합니다. 검사 결과 화면에서는 실패 규칙, 해당 요소의 UIA 트리 위치, 수정 방법 안내까지 제공됩니다. 결과는 .a11ytest 파일로 저장하여 추후 확인하거나 팀원과 공유할 수 있습니다.

이벤트 모니터링

3부와 4부에서 UiaRaiseAutomationPropertyChangedEvent 등으로 이벤트를 발생시키는 코드를 구현했습니다. 이 이벤트가 실제로 올바르게 발생하는지 확인하려면 이벤트 모니터링 기능을 사용합니다.

UIA Tree에서 검사할 요소를 선택한 뒤 "More options > Listen to Events"를 선택하면 Events 보기가 열립니다. 기본적으로 해당 컨트롤 타입에 맞는 이벤트가 캡처되며, "My Events"에서 다른 UIA 이벤트를 추가할 수도 있습니다. 이 기능은 포커스 변경(FocusChanged), 선택 변경(SelectionChanged), Live Region 알림(LiveRegionChanged), 속성 변경(PropertyChanged) 같은 이벤트 검증에 특히 유용합니다.

예를 들어 양방향 동기화를 검증한다면, 마우스로 슬라이더를 클릭한 후 RangeValue.Value 속성에 대한 PropertyChanged 이벤트가 발생하는지 확인할 수 있습니다. 이벤트가 보이지 않는다면 컨트롤의 이벤트 발생 코드에 문제가 있는 것입니다.

주요 단축키

효율적인 검증을 위해 다음 단축키를 알아두면 좋습니다. Shift+F9는 Accessibility Insights 창을 전면에 표시합니다. Shift+F8은 선택된 요소에 대해 자동 검사를 실행합니다. Shift+F7은 이벤트 기록을 시작하거나 중지합니다. Shift+F5는 UIA Tree 업데이트를 일시정지하거나 재개합니다. 더 많은 단축키는 메뉴에 있는 앱 설정에서 확인하실 수 있습니다. 그리고 단축키 변경도 가능합니다.

Inspect.exe

Inspect는 Windows SDK에 포함된 UIA 인스펙터입니다. Microsoft는 Accessibility Insights로의 전환을 권장하고 있지만, Inspect만의 고유한 강점이 있어 실무에서 여전히 유용합니다.

설치 및 실행

별도 설치가 필요 없습니다. Visual Studio 등을 통해 Windows SDK가 설치되어 있다면 C:\Program Files (x86)\Windows Kits\10\bin\<SDK 버전>\x64\Inspect.exe 경로에서 실행할 수 있습니다. SDK 버전이란 예를 들면 “10.0.26100.0”과 같습니다.

장점: Raw / Control / Content View 전환

Inspect의 가장 큰 강점은 UIA 트리를 세 가지 뷰로 전환하며 볼 수 있다는 점입니다.

Raw View는 모든 UIA 요소를 포함하는 완전한 트리입니다. 장식용 요소, 스크롤바 내부 구성 요소 등 보조 기술이 일반적으로 무시하는 요소까지 모두 표시됩니다.

Control View는 Raw View에서 UI 구조를 이해하는 데 필요한 요소만 남긴 뷰입니다. 대부분의 보조 기술이 이 뷰를 기준으로 동작합니다.

Content View는 사용자에게 실질적인 정보를 전달하는 요소만 남긴 가장 간결한 뷰입니다. 레이블이나 장식 요소는 제외됩니다.

이 세 가지 뷰를 비교하면 "왜 스크린 리더가 이 요소를 읽지 않는가", "왜 예상과 다른 순서로 읽히는가" 같은 문제의 원인을 파악할 수 있습니다. 특히 3부와 4부에서 구현한 Win32 커스텀 컨트롤이 UIA 트리에 올바르게 편입되었는지 확인할 때 유용합니다.

Inspect는 Options 메뉴에서 MSAA 모드와 UI Automation 모드를 전환할 수 있고, 지원되지 않는 속성 표시, 강조 사각형 표시 등 세밀한 설정이 가능합니다.

Accessibility Insights와의 역할 분담

일상적인 접근성 점검과 자동 검사는 Accessibility Insights가 적합합니다. Inspect는 UIA 트리 구조 자체를 Raw/Control/Content 뷰로 비교 분석해야 할 때, 또는 Accessibility Insights에서 원인을 파악하기 어려운 복잡한 트리 구조 문제를 디버깅할 때 사용합니다.

실전 검증 워크플로

실무에서 권장하는 검증 순서는 다음과 같습니다.

먼저 Accessibility Insights의 Live Inspect로 각 요소의 Name, ControlType, Patterns를 확인합니다. 그다음 FastPass로 자동 검사를 실행하여 누락되거나 잘못된 속성을 찾습니다. 동적 동작에 문제가 의심되면 이벤트 모니터링으로 이벤트 발생 여부를 확인합니다. 트리 구조 자체가 의심되면 Inspect.exe에서 Raw/Control/Content 뷰를 비교합니다.

검사 시 반드시 확인해야 하는 핵심 속성은 Name, ControlType, AutomationId, IsKeyboardFocusable, BoundingRectangle, 그리고 지원하는 Patterns입니다. 이후 필요에 따라 Selection, Value, RangeValue, Toggle, ExpandCollapse 등 패턴별 세부 속성을 확인합니다.

마지막으로 가장 중요한 점을 강조합니다. 도구 검사만으로는 충분하지 않습니다. 반드시 NVDA 같은 실제 스크린 리더를 켜고 키보드만으로 앱을 사용해보아야 합니다. 도구는 속성과 패턴의 존재 여부를 확인할 수 있지만, 실제 사용자 경험의 자연스러움과 논리적 흐름은 스크린 리더로만 검증할 수 있습니다.

기타 SDK 도구

Windows SDK에는 위 두 도구 외에도 접근성 검증에 사용할 수 있는 도구들이 포함되어 있습니다. 모두 레거시로 분류되지만, 특정 상황에서 여전히 유용합니다.

AccEvent (Accessible Event Watcher)는 UIA 이벤트 모니터링에 특화된 도구입니다. Accessibility Insights의 이벤트 모니터링 기능으로 대부분 대체 가능하지만, 이벤트 흐름만 집중적으로 분석하고 싶을 때 더 직관적일 수 있습니다.

AccScope는 Narrator가 앱을 어떻게 인식하는지를 시각적으로 보여주는 도구입니다. 읽기 순서, 요소 그룹화, 누락된 요소를 시각적으로 확인할 때 유용합니다.

UIA Verify와 AccChecker는 규칙 기반의 자동화 테스트 도구로, 회귀 테스트나 CI 통합에 활용할 수 있습니다. 다만 신규 프로젝트에서는 Accessibility Insights를 우선 사용하는 것이 권장됩니다.

글을 마치며

이 글을 끝으로 "접근성있는 Windows 데스크톱 앱 만들기" 시리즈를 마무리합니다.

1부에서 UIA의 개념과 세 가지 핵심 요소를 살펴보았고, 2부에서는 WinUI 3의 AutomationProperties와 Automation Peer를 통해 프레임워크 수준의 접근성 구현을 경험했습니다. 3부와 4부에서는 Win32 API로 IRawElementProviderSimple부터 Fragment Provider까지 직접 구현하며 UIA가 내부적으로 어떻게 동작하는지 깊이 이해했습니다. 그리고 이번 5부에서는 이 모든 구현이 올바르게 동작하는지 검증하는 방법을 다루었습니다.

어떤 프레임워크를 사용하든, UIA의 본질은 같습니다. 컨트롤의 이름과 역할과 상태를 보조 기술에 전달하고, 변경 사항을 이벤트로 알리는 것입니다. 그리고 접근성은 개발이 끝난 후 한 번 하는 것이 아니라, 개발 과정 전체에 걸쳐 지속적으로 수행해야 합니다. Accessibility Insights의 Live Inspect를 항상 켜두고 개발하는 습관을 들이면, 접근성 문제를 초기에 발견하고 수정하는 데 큰 도움이 됩니다.

그동안 긴 시리즈를 읽어주셔서 감사합니다. 이 글이 접근성있는 Windows 데스크톱 앱 개발에 실질적인 도움이 되었으면 좋겠습니다.