스크린리더가 컴퓨터에서 일어나는 일을 알려줄 수 있는건, 일반 프로그램들과 스크린리더가 통신할 수 있는 인터페이스가 있기 때문입니다. 마이크로소프트 윈도우가 정의한 인터페이스가 있고, 응용프로그램들이 이 인터페이스를 구현하면, 스크린리더가 그 인터페이스를 이용해서 필요한 정보를 가져가지요.

.NET 프레임워크가 있기 전에는 COM 기반의 MSAA라는 인터페이스가 있었습니다. 하지만 COM이라는 까다로운 기술을 활용해서 접근성을 지원한다는건 비현실적인 일입니다. HTML과 CSS 표준을 지켜서 웹 접근성을 지원하자는 목소리도 외면당하는 마당에, 레퍼런스 카운트에 신경을 곤두세워야 하는 작업을 누가 하겠습니까? 포인터라도 잘못 건드렸다가는 프로그램이 뻗어버리는 재앙이 일어날텐데 말이죠.

MSAA와 UI Automation의 관계는 ActiveX와 Silverlight의 관계와 비슷합니다. 역할은 같으나 .NET프레임워크에서 제시하는 대안이지요. MSAA와 UI Automation은 두 가지 큰 차이점이 있습니다.

1. 관리되는(managed) 코드이기 때문에 포인터나 레퍼런스 카운트에 신경 쓸 필요가 없다.
2. 스크린리더와 같은 보조공학 뿐 아니라 UI를 테스트하는 용도로도 활용하도록 디자인했기 때문에 일석이조의 효과를 얻을 수 있다. 실제로 UI Automation으로 검색을 해 보면 접근성(accessibility)보다 테스트(test)에 관련된 결과들이 더 많다.
   

첫번째 변화가 지렛대의 받침점을 힘점으로 가까이 옮겨놓는 역할을 한다면, 두 번째 변화는 지렛대를 들어올리는 일 자체에 관심이 없던 사람들이 힘을 쓰도록 동기를 유발할 것으로 기대됩니다.


좋다는건 알아도, 마이크로소프트가 윈폼(WinForm)이나 WPF다 하면서 변화가 빨라서 시간을 쪼개가면서 UI Automation을 공부할 엄두가 나지 않더군요. 게다가 MSAA에서 UI Automation으로의 변화를 비판하는 글을 보고는 확 쫄아 있었는데, 최근에 올라온 UI Automation Community Promise Specification를 보고 마음이 놓였습니다. 공개적으로 약속을 했다는 점에서 안심이 되고, MSAA와의 호환에도 신경을 쓰고 있다는 점도 알게 된 덕분이죠.

여기 저기 뒤져보다가 TrackFocus 샘플 코드를 다운 받아서 Visual C# 2008 Express Editions에서 돌려봤습니다. 오.. 아직 UI Automation에 관련된 문서를 보지 않았지만 평범한 분량의 주석이 달린 코드를 읽는 것만으로도 직관적으로 이해가 됩니다. 포커스가 변할 때 마다 포커스가 위치한 컨트롤의 속성과 이름을 출력하는 프로그램인데,파이어폭스의 하이퍼링크, 라디오버튼, 체크박스도 인식하네요. 실행파일을 첨부합니다 (ScreenReader.exe, .NET 프레임워크를 설치하셔야 합니다.) 셈플 코드 주제에 이름 한번 거창하게 지었군요. ㅎㅎ 제가 정한게 아니고 셈플과 함께 제공되는 프로젝트 파일에서 지정한 이름입니다.

탄력을 받아서 콘솔 버전의 샘플을 WPF로 구현해 보려 했더니 여기 저기서 막히더군요. 레퍼런스(Reference)를 추가하지않아서 System.Windows.Automation 아래의 클래스들을 사용하지 못하는 문제에서 한참의 시간을 보내고, DataBinding에서 막혀서 WPF를 공부하고 다시 시도하기로 했습니다. 아직 조금 보다가 말았지만 WPF의 디자인은 정말우아합니다. UI Spy처럼 윈도우들의 구성을 트리 구조로 보여주는 프로그램을 만들어보고 싶네요.