WPF + UISpy = Accessibility testing

29 במאי 2007

תגובה אחת

[This blog was migrated. You will not be able to comment here.
The new URL of this post is http://khason.net/blog/wpf-uispy-accessibility-testing/]


Well, some of Doron's scripts make commenting to this post(hebrew) disabled, however today I want to write about WPF accessibility issues. Someone who writes code really know what is it? I'm pretty sure, that do not. Let's make small test case. Execute regular WinForms application and Accessibility Speech engine (you can find it under Start->Accessories->Ease of Access->Narrator). Try to open calculator and go to application menu. You'll hear something like: "Menu Item Edit. Three menu items. Copy Menu Item, shorkey Control C". Where it comes from. Does narrator understand every control? How to know or control what should say? Open SpyUI from Windows SDK. Find "Calculator" node in elements tree and expand it. You'll find everything that Narrator speaking. This discovered by windows API in regular win forms.


image


Well. Now let's create simple WPF application with menu bar, button and listbox and let UISpy detect it.


image


Well, it works. But not so good. "Edit" menu item has Copy menuitem inside, but UISpy do not know about it. It's detects the containment of listbox, so it works until we have no data binded. Let's bind and see what we have.


image


Please see, that instead of what we actually see, there are System.Xml.XmlElement items are displayed. Actually, UISpy is right. We are using data, that WPF engine renders into UI. But we can not leave it this way. What to do? Make it accessible. Here the way.


First of all, we have to set TextSearch.TextPath property to our actual text. Next, override ItemContainerStyle to set its AutomationProperties.Name value to be binded to the source of text, we want to make accessible. Here the code.


    <ListBox ItemTemplate="{StaticResource template}"
DataContext="{StaticResource data}" ItemsSource="{Binding}"
TextSearch.TextPath="@value">
<
ListBox.ItemContainerStyle>
<
Style>
<
Setter Property="AutomationProperties.Name" Value="{Binding XPath=@value}"/>
</
Style>
</
ListBox.ItemContainerStyle>
</
ListBox>

 


If you'll bind Automation Name property inside data template it will not work, 'cos for real WPF engine do not render text objects, so the only way to do it is by overriding those properties externally. How we can tell? Right property in wrong place 🙂


And here the result of such approach in UISpy. Now you can run Narrator or any other accessibility application and everything will work fine.


image


The conclusions are as following:


1) UISpy is extremely important tool for accessibility check
2) WPF is not very friendly from this point of view in current version, but I'm sure, that next release will fix those issues.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

תגובה אחת

  1. doronbd29 במאי 2007 ב 21:20

    It is mostly imporant to pay attention to those things.
    In one of the project I've participated in (C&C for military platform) we were creating a GIS based system with polyline drawing option. Unfortantly, the programming team was responsible of the coloring (Tamir was talking today about what happens when programmers are responsible of GUI..) – which later was discovered as a major problem.
    Some of the soldiers which were the operators of this system were daltonists, which mean – they couldn't see any difference between the green polylines and the red ones.
    The system had no support for templating nor color configuration, and it caused us deploying another set of assemblies.

    The ambiguity in projects' accessibility is a bummer indeed.

    הגב