I’m often asked “What’s the correct name for this control?” There are many variations to this question, for example:
Yes, yes, and no.
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.
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.”
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:
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?