• Screen readers and other assistive technologies.
• High contrast mode.
• Large fonts.
• and anything else I may have missed.

We'd love the opportunity to discuss how we can improve your experience with Visual Studio on an ongoing basis.

Please leave a comment on this weblog, or email me directly at abreth@microsoft.com.

Thanks!
Aaron

Getting Started

New to Accessibility?  So was I three years ago.  Get caught-up by reading my MSDN whitepaper on Testing for Accessibility.  Also, remember that Accessibility isn’t a feature.  Just like localization, globalization, security, performance, and so forth, it is a standard that must be addressed.

MSAA / IAccessible

If you want your feature to be accessible, you’ll need to implement IAccessible.

Must Read:  Explanation of each of the IAccessible Properties

http://blogs.msdn.com/saraford/archive/2004/08/25/220499.aspx

Must Read:  Which Control-Types Support Which Properties

http://blogs.msdn.com/saraford/archive/2004/08/20/217941.aspx

Must Read:  How To Really Support MSAA Names

http://blogs.msdn.com/saraford/archive/2004/01/25/62669.aspx

Commonly Asked Questions regarding Invisible, Offscreen and Unavailable States

http://blogs.msdn.com/saraford/archive/2004/01/06/48091.aspx

Which Properties Must Be Localized

http://blogs.msdn.com/saraford/archive/2004/04/16/114809.aspx

Must Read:  MSAA / IAccessible Samples 

Fiona, one of the devs on my team VSCore, has put together a really nice sample on how to implement IAccessible for a Custom Push Button http://blogs.msdn.com/saraford/archive/2004/06/18/159730.aspx

Must Read:  MSAA Testing Tools

Have you ever used AccExplorer or Inspect and wondered whether the information presented was correct? Have you ever wanted to know which controls really need Names, Keyboard Shortcuts, Descriptions, and so forth? It's time to MsaaVerify! MsaaVerify will verify 9 Microsoft Active Accessibility properties for 10 Microsoft Active Accessibility Role types.

http://blogs.msdn.com/saraford/archive/2004/05/11/130002.aspx

Updated!  How To Really Do Screen Reader Testing.

In the past, I’ve focused on testing MSAA Properties.  Now we’re ready to take screen reading testing to the next level by adding Events into the algorithm.  It is not only essential that a control support the correct MSAA properties, but it is also essential that the control fire the right event for these properties.

http://blogs.msdn.com/saraford/archive/2004/08/20/218078.aspx

Accessibility Macros

As demo’ed at CSUN, these macros allow users to tweak the Visual Studio .NET 2003 IDE by easily increasing and decreasing font size, toggling colors in the editor to pure black on white (or vice versa), and maximizing tool windows.

http://blogs.msdn.com/saraford/archive/2004/05/14/132296.aspx

Bugs to look out for

A listing of unpopular bugs given to me by an Assistive Technology Vendor

http://blogs.msdn.com/saraford/archive/2004/01/06/48090.aspx

What the High Underline Letters Checkbox Actually Does

http://blogs.msdn.com/saraford/archive/2004/04/16/114935.aspx

http://blogs.msdn.com/saraford/archive/2004/04/27/121810.aspx

Why Radio Buttons don’t resize

http://blogs.msdn.com/saraford/archive/2004/05/25/141462.aspx

Channel 9 Video

My Channel 9 Interview on Accessibility and Visual Studio

https://channel9.msdn.com/ShowPost.aspx?PostID=5382

more at http://blogs.msdn.com/saraford/archive/2004/04/30/123993.aspx

CSUN

Presenting at CSUN

http://blogs.msdn.com/saraford/archive/2004/02/17/75295.aspx

Getting Ready

http://blogs.msdn.com/saraford/archive/2004/03/14/89611.aspx

References

http://blogs.msdn.com/saraford/archive/2004/03/17/91255.aspx

Blogging and Accessibility Presentation

http://blogs.msdn.com/saraford/archive/2004/06/14/155479.aspx

• The Fundamentals of Accessibility
• Testing for Accessibility: Keyboard, High Contrast, and Assistive Technology Compatibility  
• Watch Out for these Unpopular Accessibility Bugs
• Normal, Unavailable, Offscreen, and Invisible AA States Explained
• Questions and answers about AA-Naming your control  
• Usability and Accessibility - are they the same thing?
• Book Report on "Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements"
• "Testing for Accessibility" article moved to new location
• What do you think about desktop customization?
• What does IAccessible::get_accKeyboardShortcut() return?

When I first started Accessibility testing two years ago, I had never heard of Accessibility in terms of software.  Sure, I had seen the Accessibility Options icon in my Control Panel, but that was really the extent of my knowledge at that time.  When I was asked to do ad-hoc directed Accessibility testing against Visual Studio , my first question to the Program Manager was, "How do I test for this?  How do I test using a screen reader?"  He replied, "Turn off your monitor, I guess."   And so I did...

There is a lot of information out there about what it means to be Accessible.  A couple of examples:

1. Does your application work with a Screen Reader? 
2. Does your application respond to High Contrast? 

From a tester' s perspective, we need specific details in order to test.  Just saying "Does the feature work" isn't deterministic.  What are these details?  What does a tester need to know in order to verify something works with either an Assistive Technology device (aka screen reader) or an Accessibility Feature (aka High Contrast)?

It is critical to know not only the "what" to test in terms of Accessibility, but also the "how" to test, which is the more important.  For now, I'll only discuss three categories of Accessibility: 

1. Keyboard Access
2. High Contrast
3. Assistive Technology Compatibility - specifically screen readers. 

For each category, I will go into detail regarding what a tester is looking for and also how to find it.

What is Keyboard Accessibility

This is the easiest of the three to test.  Most people have used this category without even realizing it was related to Accessibility.  Anytime someone uses Ctrl-X and Ctrl-C to cut and copy text without the mouse, he/she is using Accessibility.  Not convinced?  Let us compare the keyboard versus the mouse in this cut/paste scenario:

Constants in both scenarios:

• Outlook 2003 Mail Message using Word as Editor
• Cursor is at the end of the sentence to move
• Move the first sentence after the second sentence.

Keyboard Steps:

1. Press Ctrl + Shift + Home
2. Press Ctrl-X
3. Press Ctrl-End
4. Press Ctrl-V

Mouse Steps:

1. Move mouse to beginning of document
2. Highlight the text to copy
3. Right click (bring up context menu)
4. Select  "cut"
5. Move mouse to end of document
6. Left-click
7. Right-click
8. Select paste.

Although both scenarios took approximately the same amount of time (5 seconds), the Mouse Steps are obviously much longer than the Keyboard Steps.  Another thing I noticed while timing myself was how error prone the Mouse Steps were.  Sometimes I didn't get the mouse pointer exactly at the same point as system cursor, so I had to redo the highlight.  This error took an extra few seconds to correct, even more if I didn't notice it until after I did the paste.

When testing for keyboard accessibility, keep in mind the the miniminum number of keystroks must always be used.  It's either a design issue or a coding defect.  A design issue is using the keyboard shortcut "Ctrl + Alt + Shift + T" to perform a function, whereas "Enter" works just as well.  I'll explore this example in more detail in the next section.  A coding defect is when a control with a tab stop is missing its Accelerator or Mnemonic.  This is the underlined letter that appears when you have Control Panel - Accessibility Options - Keyboard Tab's "Show extra keyboard help in programs" checked.  Yeah, not the best name for the feature, but now you know what it does!  Consider a dialog that has about twenty controls with Tab stops.  Suppose focus is on the 10th control, but the user needs to reach the 20th control.  Of course, the 20th control doesn't have a keyboard shortcut, so the user is forced to hit tab 10 times.  A keyboard shortcut requires just the Alt + Underlined letter - 2 keystrokes.  This is especially important for someone with a mobility disability or has pain in their wrists when typing.

The What of keyboard accessibility is doing everything that a mouse can do using the keyboard.  That's all it is.  QED.

How to Test Keyboard Accessibility

Unplug your mouse.  You cannot test a feature for keyboard accessibility if your mouse is just inches away from you for the following reasons:

• We are creatures of habit
• We can be bias without knowing it
• We might accidentally cheat

Consider reading new mail in your Outlook inbox.  I always use the mouse to select a new piece of mail.  Suppose the focus wasn't on the inbox list and was on the folder view instead.  I would have to actually look up the keyboard shortcut in the docs to get to the list view.  However, I've trained myself to use the mouse to read mail.  If I knew the mouse was still there, I could subconsciously use it instead of the keyboard.  Trust me on this one as I've done it before.  It's better just to remove the mouse and avoid the temptation.

Another critical point is knowing which features map 1-1 with the keyboard and which don't.  For example, the keyboard shortcut to drop down a combo box's list is Alt-DownArrow.  This is virtually the same thing as using the mouse to press the combo box's button.  However, what's interesting is how to test drag-and-drop.  In some situations, you don't want the user to literally capture an object via the keyboard and drag it to a new location.  An example is dragging a toolbox icon, like a button, onto a winform designer.  The user simply has to press Enter for the button to appear on the designer.  By the way, the keyboard shortcut to force the toolbox to appear in Visual Studio .NET is Ctrl + Alt + x.

In the previous example, I mentioned the shortcut "Enter."   In the letter of the law, I could substitute "Ctrl + Alt + Shift + T" and still achieve the desired effect.  Considering the spirit of the law, how intuitive is "Ctrl + Alt + Shift + T" compared to "Enter"?  How will the user know to use this command, besides reading through lots of documentation?  In other words, keep it simple, direct, and intuitive as possible.  If the keyboard shortcut doesn't fall into one of these categories, there's a potential keyboard accessibility bug lurking around.

A keyboard shortcut must never be used to replace broken keyboard functionality.  For example, to check a checkbox, the user presses spacebar.  If there's ever a keyboard shortcut to replace spacebar to check a checkbox, it is an accessibility bug.  Check out the standard Windows XP shortcuts.  If there's a keyboard shortcut that is replacing these standard keyboard shortcuts, it is most likely an accessibility bug.  It goes back to "how would the user know?"  There are standard keyboard shortcuts for a reason: we cannot force users to memorize different keyboard shortcuts for standard tasks among different applications.

What is High Contrast

Go to Control Panel - Accessibility Options - Display Tab.  There's a checkbox for High Contrast.  High Contrast will modify OS font size and colors.  When high contrast is set, the High Contrast OS System bit is set.  If you enjoy working outside on a laptop on sunny days, try using High Contrast Black (large) scheme to improve visibility. 

The difference between checking the High Contrast checkbox and manually customizing the display settings is the OS System bit is set.  If the user manually customizes the OS System Colors to look exactly like High Contrast Black (large) scheme, the application must respond just as it would under the High Contrast scheme.  This response should occur because all colors are taken from the OS System Settings. 

How To Test High Contrast

Always turn on High Contrast before starting your application.  Supporting in-place High Contrast toggling is more difficult.  If the application doesn't respond to High Contrast having been enabled prior to launch, the application is definitely not going to respond to in-place toggling. 

Here is a listing of items to check to whether the application is responding correctly to High Contrast.  Note I'm taking these items directly from our accessibility test plan that I co-authored.

High Contrast Items to Verify

1. Verify all UI elements and controls are visible

If the background changes to black and the font color is hard-coded black, the application or dialog is not usable. 

2. Verify differentiable appearance of inactive and active selection

Explanation of Focus and Selection

Focus:  Only one control or UI Element can take focus at a time.  If I were to press a key on the keyboard, the keystroke can only be sent to that control with focus.

Selection:  Multiple controls can have multiple items selected.  List boxes can have as many or as few items selected.

Inactive Selection:  When focus moves away from the list box (with selected items) to another control, those list box items are said to have inactive selection:

Active Selection:  The selected list box item with focus.  Hence, only one item can have Active Selection.

Regardless whether High Contrast is set, Active Selection and Inactive Selection must correctly respond to their appropriate system colors.  Additional testing is required in High Contrast mode, because although it might work in some default Windows display scheme, it isn't guaranteed to work in High Contrast.

3. Verify visual focus is available in high contrast mode

Focus must be shown at all times.  A great way to find bugs is to tab around the application.  If focus ever disappears, it is an Accessibility bug.

4. Verify multiple schemes function

All color schemes should work, since font sizes and colors come from the OS.  However, due to time and resource constraints, it is important to test with the most commonly-used schemes, like High Contrast Black (large).  With some certainty, if the application responds correctly to one scheme, it in theory responds to all, because it is reading the color data from the same location.  Only the data is changing values.

5. Verify no text truncation occurs

There's some gray area here.  The text must be readable; yet, it's never good for text to be truncated.  The rule I've been using is to say if more than 20% of the text's height is truncated, it's an accessibility bug.

6. Verify no hard-coded colors

All colors must come from the OS system settings.  If the application has custom colors that cannot be mapped to the OS system settings, there must be a way for the user to customize these colors.  For example, in Visual Studio , we have custom colors for squiggles.  Since there isn't an OS system setting for squiggles, we provide a means via Tools Options for users to customize these settings. 

What is Assistive Technology Compatibility

Assistive Technology Compatibility depends on Microsoft Active Accessibility (MSAA) support.  If an application does not support MSAA, it will not support Assistive Technology Devices. 

Narrator is a screen reader that ships with Windows XP.  It's great for just learning the basics of how screen readers work.  It isn't a full-version or industry-standard, because there are third-parties who have spend years on end producing screen reader technologies.  Most people who are blind will use one of these third-parties products.  Make sure you are testing with an industry-standard screen reader, but it doesn't hurt to try out Narrator to become more familiar with how screen readers work.  Also, it'll make you appreciate an industry-standard screen reader even more!

How MSAA Works for Retrieving a Standard Win32 Button Accessible Name

Client (Screen Reader) asks MSAA for a pointer to the IAccessible object via AccessibleObjectFromWindow, AccessibleObjectFromEvent, and so forth....  MSAA asks the server (aka the button) for a pointer to the IAccessible implementation.  Since it is standard control and doesn't have its own IAccessible implementation, it returns 0.  In this case, MSAA uses a proxy to return methods and property values.  For IAccessible::get_accName, MSAA returns the value from GetWindowText().

How MSAA Works for a Custom-Drawn Button

Client (Screen Reader) asks MSAA for a pointer to the IAccessible object via AccessibleObjectFromWindow, AccessibleObjectFromEvent, and so forth....  MSAA asks the server (aka the button) for a pointer to the IAccessible implementation.  Since it is custom control, the developer has implemented IAccessible, so a pointer to this implementation is returned.  The client calls IAccessible::get_accName on the interface pointer and the value set by the developer is returned.  Note here that it might not be the same as GetWindowText(), although it must be.  Custom controls are prime targets for Accessibility testing.

How MSAA Works for a Owner-Drawn Button

A slight combination of both Standard and Custom.  It works exactly the same way as Standard.  When the client asks for the Name, GetWindowText() may return a null BSTR.  All controls, especially visible controls, must support name.  Another great target for Accessibility testing.

Once the client has a pointer to the Accessible object, the Assistive Technology will perform actions based on the object's role.  This value is returned by IAccessible::get_accRole that maps to a structure of known MSAA Role types, like push button or combo box.  It is possible for a server to return its own customer role type; however, will the Assistive Technology know how to interact with the controls?  EVERYTHING IS BASED ON THE MSAA ROLE. Seriously.  If the role is wrong, don't expect anything to work.

How To Test for Assistive Technology Compatibility

The MSAA information must be as correct as possible to support Assistive Technologies.  So, the first thing to test is MSAA.  AccExplorer is a great tool to view the IAccessible properties and method of a particular control; however, there is no mechanism to tell you if the properties or methods are supported correctly.  AccExplorer has its own verifications associated with it.  Unfortunately, these verifications were written with an Assistive Technology vendor in mind.  For example, on a button, the test will log a failure if DISP_E_MEMEBERNOTFOUND is returned for ::get_accValue.  This is actually by design, because a button does not support value.  If a method is not supported, return DISP_E_MEMBERNOTFOUND. 

In order to determine which properties and methods must be supported, review the UI Element Referece doc contained in the MSAA SDK Docs.  This website describes a virtual contract between MSAA and Assistive Technology vendors.  Even if a server were to set that value property on a push button, the Assistive Technology device wouldn t read it because, from the docs, buttons are designed not to support value.

Once the MSAA information is verified, the tester can moved on to using the Assistive Technology device.  I am most familiar with screen readers, so I will limit this discussion to just them. 

First and foremost, the tester must become familiar with all of the common keyboard shortcuts.  Second, and probably equally important, the tester should work with someone who uses the Assistive Technology on a routine basis.  Even if there is no one to work with, it is still possible to test with the Assistive Technology.  It just requires a deeper understanding of what all the keyboard shortcuts do.   Lastly, the tester can only use the keyboard.  A user who is blind will not be able to use the mouse.

Once the Screen Reader is installed, the tester opens up a common dialog (like start -> Run dialog) and interacts with it by tabbing to each control.  The tester trains his/her ear to listen for patterns.  An example pattern a screen reader could speak is <control name> <control role> <additional properties based on role>.  If focus were on the Run Dialog's push button, the tester listens for "OK PushButton." If focus were on the combo box, the tester listens for "Open: ComoBox notepad.exe" , where notepad.exe is the text within the combo box's edit box.

When doing Screen Reader testing, turn off the monitor.  It forces the tester to really listen to what the screen reader is saying.  And even then that is not enough.  As I've used VS for days on end for the past 4 years, I've become so bias towards how things should work, it is easy for me to miss certain bugs.  For example, I might hear the screen reader read the text for a link, but not realize that the screen reader did not say "link" at the end.  I am bias because I know it is a link, so I accidentally stop listening once it is finished reading the name of the link.  Turning off your monitor helps break that sense of comfort knowing where focus is at, so you are forced to listen to things more carefully.

From my experiences, there are two categories of Assistive Technology bugs against the server (aka, the application itself).

1. Functionality bugs like dangling pointers, infinite loops, and so forth... 

Example is when the Screen Reader tries to access inforamtion from a dangling pointer.  The application crashed due to a null pointer reference exception. 

2. MSAA bugs 

Example is a push button that doesn't have a Name.  This is the same thing as an OK button not having a Caption. 

The tricky part to Assistive Technology testing is knowing when it is a bug against the application and when it is a bug against the Assistive Technology.  Historically, MSAA has not been reliable due to poor or no implementation for custom controls, so ATs use hooks, one of which is an Off-Screen Model, that queries for information outside of MSAA.  Knowing if, how, and when an Assistive Technology uses such hooks is important for figuring out who gets the bug.  If the MSAA information is correct (and it is not a functionality bug), there is a high probability that it will go against the Assistive Technology.

In conclusion, I have stated the "what" and "how" of Accessibility testing for keyboard, high contrast, and screen reader support.  This testament is an honest collection of the knowledge and experiences I've accumulated in the past two years.  I hope this doc will be helpful for other testers who are starting accessibility testing.  Good luck and happy Accessibility bug hunting!

I look forward to your feedback!

Thanks for reading,

-sara

The Accessibility Technology Group on campus has a lab with numerous licensed-versions of Assistive Technologies (ATs), including Motion Trackers, Screen Readers, Screen Magnifiers, Braille Displays, Speech Recognition, and so forth.  Their lab is opened to any team or person on Microsoft campus interested in using Assistive Technology.  Using their lab is so straight-forward that I was a little embarrassed that I had asked Mike, their lab manager, to "hold-my-hand" for the first few OS installs.  But, Mike is cool and he didn't mind.

Why did we go there?

I had wanted my team to be able to use different Assistive Technology devices to perform basic Visual Studio tasks, in order to increase Accessibility awareness and to educate how Assistive Technologies and Visual Studio work together.

What did we do?

We focused mainly on Screen Readers and Screen Magnifiers, and a couple of Motion Trackers to really open people's minds.  Due to the nature of our product, Visual Studio 's targeted disability persona is blind or low-vision.  We're a visual product, hence "Visual" Studio.  We don't exclusively rely on sound to convey information.  Sure, you might hear a beep when there's a build error, but you'll see a build error message box, squiggles, and errors in the task list.  A person who is blind or has low-vision usually uses the keyboard exclusively, so we are already working on the support for people who cannot use the mouse or require a specialized keyboard. 

I installed Whidbey on 4 different screen reader stations, 2 motion tracker stations, and 2 screen magnifier stations.  I asked people to form teams of 2 gathered at each station.  Their task was to create an Accessible Application using Assistive Technologies.  They were give hard-copies of the MSDN Whitepaper:  Walkthrough: Creating an Accessible Windows Application to better simulate a real user experience.  Some reported that it was a useful activity; others said they liked unstructured activity.  The important part was that everyone worked with an Assistive Technology device. 

By the way, the folks who worked with screen readers had 5 minutes to get oriented, and then I came by and turned off their monitors.

Creating a Hello World App without the mouse or a keyboard

While we waited for the rest of the participants to arrive, one of our teammates, Boyan, demo'ed for us how to create a WinForm's Application with a button on the form that when pressed displayed a "Hello World' Message Box.  He did all of this using a Motion Tracker device.  You might think what's the big deal, but if you've never worked with a motion tracker, it's designed for someone who is paralyzed or partially-paralyzed.  To use this particular motion tracker, you wear a silver circular sticker on your nose (so you don't forget to take it off).  The Motion Tracker tracks this sticker and the cursor basically goes where your nose goes.  To click, you hover over a floating tool window on the desktop that has buttons for Single Click, Double Click, Left Button, Right Button, Scroll, etc.  If you hover over for a second or two, the corresponding button on the floating tool window becomes depressed, so you can impersonate that mouse feature.  There's an on-screen keyboard that allows you to simulate typing using that same technique to depress a key on the keyboard.  According to Boyan, the most difficult part was trying to type.  As people came into the lab and gathered behind him, you could see everyone slowly start swaying trying to get him to turn his head ever so slightly.  A lot of people were amazed to see this technology used with our product. 

Our Guest Speaker

Almost an hour later, after everyone had a chance to really work with an Assistive Technology and try to perform whatever task they were working on, we had a guest speaker stop by.  Mia, a tester from the Accessibility Technology Group, uses screen readers to perform her job.  She sat down with us and I walked her through the same exercise that Boyan had completed earlier with the motion tracker.  Whenever Mia wasn t sure where focus was in the IDE, I explained where she was.  In addition, I asked her what sort of information we could provide in these states.   For example, our previous out-of-box state was to have focus on the solution explorer.  Since the solution explorer is an empty tool window in this state, because there is no project opened by default out of box, the screen reader only replied, Solution explorer .  Immediately Mia tried to tab around, but we all knew that nothing was going to happen.  I looked at my team shaking their heads, like wow, we have some work to do.  Whenever I could, I glanced at the audience.  Some were looks of surprise, like, How can she listen to her screen reader that quickly.   Others were looks of embarrassment.  And a few had looks of determination to make our IDE more accessible.  Mia had a captive audience the entire time.  After 30 minutes, I had to end my first semi-usability study, because it seemed that people would have kept Mia there for another hour or so just asking questions.

Did the activity have an effect?

While I was walking down the hallway back to my office, I heard one of our devs, who had attended our activity, explain to another dev, who did not attend our activity, how he needed to improve the accessibility of his feature.

Thank You's

A big thank you to Mia for being our guest speaker.  Your demo was the highlight of the activity.

Another big thank you to Mike, the lab manager, for his help setting up the lab.

And one more big thank you to Matt, from the Whitehorse team, for being the first one from our division to organize such a tour for all the Accessibility QA Representatives. If Matt hadn't taken the initiative, there's a good chance this activity wouldn't have come together.

I attended a few get-togethers with some Assistive Technology vendors a while back when they were on campus for an Accessibility conference.  While eating dinner with one particular AT vendor, I had asked him what we, Visual Studio , could do to improve our Assistive Technology compatibility story.  Next thing I knew, I was writing frantically on paper usually used for receipts.

1.      Consider allowing Graphics to take focus.  If there s a control the mouse user can interact with, the keyboard user will most likely want to interact with that control in a similar fashion.  Sure, there are workarounds, like telling the user to go to the menus to find the same functionality.  But, depending on what the control does, it could mean a lot of extra steps, especially if the control is frequently used. 

2.   All graphics should have an AA object.  If it is too costly for the graphic to have an AA object, at least draw it as a bitmap.  Never just paint graphics.  These are black holes to ATs.

3.   Graphics should have a bitmap associated with it, especially for those that don t have AA objects or are just bitmaps.  If the graphic is painted, it is critical that it have a tooltip.  This at least gives ATs a chance to identify the graphic.

4.   Correct cursor location is returned.  For example, the (x,y) screen coordinates for an italicized cursor is at the baseline.  I was told by the AT vendor that Word does not return Italicized cursor coordinates correctly, but I have not investigated this issue to confirm this at this time. 

5.   After selecting text, the cursor must not disappear.  The cursor must continue to blink based on OS Settings.  I was told by the AT vendor that Notepad does this correctly; Word does not, but I have not investigated this issue to confirm this at this time.  ATs may have to write special logic to determine cursor location.

6.   Use win32 API DrawFocusRect, even if you ve drawn your own focus rect.  I was told by the AT Vendor that there s a parameter you can pass in to draw the focus rectangle as invisible, but I didn t see it in the docs.  It doesn t mean that it isn t possible.  The AT s Off Screen Model goes by the focus rectangle drawn by DrawFocusRect, so if the AT can t find focus, although it is visible on the screen, this is the most likely cause.

What the docs say

Starting with the MSAA SDK Docs on Object State Constants, the following terms are defined as follows:

• STATE_SYSTEM_NORMAL - Indicates that the object does not have another state assigned to it.

• STATE_SYSTEM_INVISIBLE - The object is programmatically hidden. For example, menu itmes are programmatically hidden until a user activates the menu. Because objects with this state are not available to users, client applications should not communicate information about the object to users. However, if client applications find an object with this state, they should check to see if STATE_SYSTEM_OFFSCREEN is also set. If this second state is defined, then clients can communicate the information about the object to users. For example, a list box can have both STATE_SYSTEM_INVISIBLE and STATE_SYSTEM_OFFSCREEN set. In this case, the client application can communicate all items in the list to users.

• STATE_SYSTEM_UNAVAILABLE - The object is unavailable.

• STATE_SYSTEM_OFFSCREEN - The object is clipped, or scrolled out of view, but not programmatically hidden. If the user makes the viewport larger, more of the object will be visible on the computer screen.

Simple explanations for each term

Normal just implies that the control is visible and available.  If no state bits are set by the server developer, the out parameter for the IAccessible::get_accState is 0.  When the client calls GetStateText for a 0 out parameter, Normal is returned.  Obviously, Normal is #defined as 0.

Unavailable means that the control is either unavailable or disabled.  For example, the Start -> Run dialog s OK button is unavailable when the combo box is empty.  Although I can visually see the button, it is grayed-out and disabled, such that I cannot press the button (or perform the default action).

Offscreen occurs when the object is either normal or unavailable, but it has been scrolled off the screen.  Increase the screen resolution or window size would cause the object to come into view. 

An Invisible object is programmatically hidden, implying that I cannot see it on the screen.   

Although these explanations seem simple enough on their own, combinations of such states are much more interesting...

Possible combinations

Normal cannot be and'ed with any other state by definition.

Offscreen and Unavailable:  The control is unavailable, but is scrolled off the screen.  In the previous example, suppose the Run dialog were resizeable.  If I were to resize the dialog such that the unavailable OK button were offscreen, I would expect this button to have both Offscreen and Unavailable states set.

Invisible and Unavailable:  In my opinion, a control would never have these two bits set at the same time.  Invisible seems to have a higher precedence than unavailable.  If a control were invisible, it isn t on the screen.  An unavailable control must be on the screen to be grayed-out. 

Having said that, a member of my team today gave me an interesting scenario where this could be true.  Suppose a control were unavailable and the user performed some action that caused it to disappear.  If the user were to revert this action (suppose unchecking a checkbox), the control would reappear in an unavailable state.  He concluded that both bits should be set.  I kinda disagree with this, considering a control cannot be invisible and grayed-out at the same time.  However, I hope that the client would check for the invisible bit before checking for any unavailable or offscreen bits, which leads me to the last combination...

Invisible and Offscreen: The definitions from the MSAA SDK docs, as referenced above, state that   

However, if client applications find an object with this state, they should check to see if STATE_SYSTEM_OFFSCREEN is also set. If this second state is defined, then clients can communicate the information about the object to users. For example, a list box can have both STATE_SYSTEM_INVISIBLE and STATE_SYSTEM_OFFSCREEN set. In this case, the client application can communicate all items in the list to users.

Offscreen means the control is programmatically accessible, but invisible means the control is not programmatically accessible.  Seems like there's a paradox here. 

I've found an interesting issue in the Windows Explorer -> View -> Folders tree view.  The child tree view item of a collapsed parent item (suppose the item has been expanded and collapsed at least once to generate the AA object) has the Invisible and Offscreen bits set.  However, so does any tree view item (child or  parent) that is offscreen.  In my opinion, it seems that clients need to check for the offscreen bit whenever invisible is set to determine if the object is really invisible or just offscreen in cases such as this one.

Hope this helps!

1.      Does this control need an AA name?

2.      Do we change the AA name if a control’s caption or label changes?

3.      Do we add the AA description to the AA name, in order to “force” the screen reader to read it?

Yes, yes, and no.

Explanation #1

All controls need to have a name, unless explicitly stated in the MSAA SDK.  For example, a Win32 standard status bar does not have an AA name, but its children must support name.  This is the only exception to the “always supply an AA Name” rule that I can think of off the top of my head.  If you’re writing in managed code (.Net Framework), always supply an AA name.  Consider it an ounce of prevention.

Explanation #2

Consider Visual Studio .Net’s New Project Dialog’s more/less button.  Note that the caption changes based on the state of the button.  I was asked if users would be confused if we changed the AA name for the control.  It seems to me that it would be even more confusing if we didn’t.  Imagine interaction with a more/less button that when toggled, still said “more”.  This reminds me of that bad junior high school joke where you write on both sides of a sheet of paper, “How do you keep a <insert profession here> occupied?  Answer on other side.” 

Explanation #3

I’ve studied the MSAA SDK guidelines for quite some time now (long enough if AA properties were GUIDs, I’d have them memorized), and I’ve come to the conclusion that the AA Name must match whatever it is on the screen, with the following exceptions:

1. The caption is a picture, hence requiring a textual name 
2. The caption or label is not unique to the dialog or form, hence requiring additional text.

Any other additional information required to explain what this control does must be provided via the AA description.  That’s what the MSAA SDK guidelines say to do. 

Having said all of this, remember we’re supporting “screen reading” technology.  I say screen reading in quotes to draw attention to the literal notion of what we are supporting.  If the AA Name didn’t match what was on the screen, are we really providing a way for a screen reader to read the screen?

Yes, there is a difference between the two.

• Usability - how well a user understands the UI
• Accessibility - the ability to use the UI

Is it possible to have one without the other?  Is it possible to have good usability without good accessibiltiy?  Is it possible to have good accessibility without good usability?  Let's say that i have perfect MSAA support for a feature that works perfectly with Assistive Technologies.  Is it possible to have good usability without having good accesibility?

I don't know yet.

I'm leaning towards “no, you can't have one without the other because they are the same thing.”  During one of my 28 hours worth of meetings this week, I mentioned that if i went to graduate school for CS, i would probably write my thesis on this topic.

What do you think?