1.MSAA自從windows 95以來到今天的windows 的任何版本，我們這些開發人都還可以使用MSAA來操作windows的UI。
MSAA是由誰來實現的呢？是COM，即組件對象模型。COM其實就是用來溝通的，負責操作系統與應用程序的溝通。用原文的話說就是COM定義了操作系統與應用程序的機制、方式、方法。
這個COM是誰呢？是IAccessible. 沒錯它就是COM，看起來像.NET的API，它是MSAA的核心接口，這個接口需要一個參數就是ChildId.有了這個接口，就能夠暴露應用程序的UI了，以樹型結構來暴露，它是系統組件(component), 在Oleacc.dll裏面。
它不僅支持IE瀏覽器，還支持firefox等多種瀏覽器的UI操作，不光可以訪問使用瀏覽器來展現的web application，還可以訪問許多商業和用戶應用程序。
MSAA作爲一項技術使用，已經被應用到測試自動化軟件中，例如QuickTest Pro, Functional Tester, and SilkTest.
2.Microsoft UI Automation簡稱UIA，MSAA的下一代產品（或稱爲技術）是UIA，但是基於MSAA技術的應用程序仍然可以使用，（這句話是說我們仍然可以使用MSAA來訪問現在的UI），那麼這是怎麼做到的呢？
因爲它們應用程序的交流溝通是通過一些“橋”來完成的，所以在基於UIA開發的應用程序能夠與MSAA開發的應用程序互操作。
所以從MSAA到UIA，有代理幫助完成；從UIA到MSAA有橋來實現。前者是一個組件，它消費MSAA的信息並且通過UIA的客戶端API使這些信息可用。後者能夠讓客戶程序使用MSAA來訪問由UIA開發的應用程序的UI。
3.Windows Automation API: 從 Windows7以來，微軟在努力把它的accessibility technologies放進一個framework裏面，稱之爲Windows Automation API, MSAA仍然存在在這個framework裏。
下面我們想想要獲取一個程序的UI需要知道哪幾個信息，這個信息不包括標示元素的ID。
State， Name, Value, Role.
Role就是告訴系統這個元素是一個按鈕或是一個表，etc. 就好比.NET裏的類型Type的概念。
Name可以理解成在界面元素上顯示的內容。
Value是界面元素裏面的值，比如一個textbox裏面的值。當然不是所有的UI element都有Value.
State:就是表明這個控件當前是獲取焦點狀態還是選中狀態或是其他狀態。
現在談談他們的缺點或者稱爲限制：
先拿這4個指標中的role來說，首先不能夠新的UI 行爲，其次現在往往需要把2個狀態信息合併來表現新控件的狀態，比如rich text,
另外一個限制是界面元素（或者成爲對象模型）的導航，（PS:我們人們看到的應用程序在MSAA裏面稱之爲servers,因爲它提供關於UI信息。 可訪問性的工具例如屏幕稱之爲client,因爲它消費和操作來自於應用程序的UI信息), servers暴露UI的方式是給出一個可訪問對象及其所有的孩子節點的相關屬性，所以要導航一個server的UI element，需要通過遍歷；clients的導航是是通過接口和方法來訪問一個可訪問對象，再訪問另外一個對象的。client必須能夠把servers的所有的途徑都能夠走通，在所有通路中必然或偶然的存在着同名的元素，這樣就造成了歧義。歧義會給解析界面元素的工具（client implenters）帶來額外的工作，這種工作給用戶代碼反覆無常、不可預期的問題，最簡單的問題就是等待查找元素的時間過長，造成自動化測試的不穩定。
第三個限制是擴展MSAA的屬性或方法不能夠打破或改變IAccessible COM的聲明。這導致我們不能通過這個對象模型來暴露新的屬性或方法，這個對象模型既是靜態又是不變的。
另外，IAccessible 有一些設計和API的不規範， 讓開發者難以使用它或者去實現它；在擴展IAccessible的時候，必須當心這個擴展的接口必須與IAccessible是完全兼容的，
病卻一些實現要先通過法律法規能夠在允許使用纔行。
最後標註下，此文翻譯自維基百科 Link: http://en.wikipedia.org/wiki/Microsoft_Active_Accessibility
另外推薦一篇博文，寫的很好 http://shanchunf.blog.163.com/blog/static/1577048020104565759612/