UI Automation Viewer Progress
The past few weeks have reaveled much about the UI Automation framework and how powerful it has proved.
The UI Automation Viewer tool we have been creating has made great progess. It allows the user to choose what type of element view they desire. Right now it can present three different views:
Currently, the Reconstruction View can reconstruct the following types of controls:
Everything else is reconstructed as a text box. This accounts for about 60% of the different types of controls. Some of them only allow the information to be read, while others allow interaction.
For example, a reconstructed button can actually be clicked which causes the real button to be clicked. However, changing the selection in a list does not actually do anything to the original list.
Last week, I figured out how easy it is to overcome the lack of a provider for certain controls:
The MenuStrip control of .Net 2.0 does not have any UI Automation Provider. Therefore, the UIA cannot access anything but its name. However, I was able to overcome this limitation by providing a client side provider - more on that in a later post. The point is, in a short time, I was able to make my own provider to make an application accessible WITHOUT changing the program.
Let me say that again:
I made an application accessible without changing anything about the application itself.
This is pretty revolutionary because it would be easy to create new UI Automation providers that are external to both the application and the accessibility technology. Neither the application nor the screen reader would need any modifications to make the application more accessible.
Awesome!
The UI Automation Viewer tool we have been creating has made great progess. It allows the user to choose what type of element view they desire. Right now it can present three different views:
- Outline View - Creates an easy to see outline of the screen or an application
- Reconstruction View - The main goal of the UIA Viewer which reconstructs the UI in order to present what is actually visible with the UIA
- Auditory Layout View - An experiment that uses stereo audio, pitch changing, and volume to help a blind user visuallize the layout of the screen
Currently, the Reconstruction View can reconstruct the following types of controls:
- Buttons
- Hyperlinks
- ComboBoxes
- ListBoxes/ListViews
- TreeViews
- ScrollBars
- Sliders
- Menus (In Progress)
- Progress Bars (In Progress -Ironic)
Everything else is reconstructed as a text box. This accounts for about 60% of the different types of controls. Some of them only allow the information to be read, while others allow interaction.
For example, a reconstructed button can actually be clicked which causes the real button to be clicked. However, changing the selection in a list does not actually do anything to the original list.
Last week, I figured out how easy it is to overcome the lack of a provider for certain controls:
The MenuStrip control of .Net 2.0 does not have any UI Automation Provider. Therefore, the UIA cannot access anything but its name. However, I was able to overcome this limitation by providing a client side provider - more on that in a later post. The point is, in a short time, I was able to make my own provider to make an application accessible WITHOUT changing the program.
Let me say that again:
I made an application accessible without changing anything about the application itself.
This is pretty revolutionary because it would be easy to create new UI Automation providers that are external to both the application and the accessibility technology. Neither the application nor the screen reader would need any modifications to make the application more accessible.
Awesome!
posted by Rick at 9:39 AM
0 Comments:
Post a Comment
<< Home