A screen reader, an inspection tool and a UI test all ask the same thing: what is this element, what is it called, and what does it hold. WPF answers most of that from the control itself, and a control library has to fill in the rest.
Names for buttons drawn from a picture
The name of a button comes from its content, and the content of a button drawn from a glyph is the path that glyph is cut from. Point a screen reader at one and it reads the coordinates out.
Every button of this kind carries a name of its own: the clear button on a text box, the one that opens a picker, the arrows of a scroll bar, the ones that scroll a tab strip, the button that shuts a flyout, the window buttons, and the overflow button beside the window commands.
In a released version several of them read out their path data. The button that opens a picker announces a page and a half of coordinates, and the one that empties a text box announces the letter its cross is cut from. Fixed on develop, which is #4454.
They are translated
Microsoft asks for an accessible name the same way it asks for anything on screen: accurate, concise, unambiguous and localized. The names live in Lang/Automation.resx, with a German set beside it, and a language nobody has translated falls back to English, the way the colour names do. A translation is a welcome pull request: copy Automation.resx to Automation.<culture>.resx and fill in the values.
The button that opens a picker says Show Calendar, which is the wording WPF gives its own DatePicker, and Show Clock where the drop-down has no calendar in it.
What each control tells a client
Tile |
named after its Title when the content leaves the name empty |
Badged |
hands the badge over as the status of what it wraps |
RangeSlider |
a slider reading out both ends, with each outer thumb carrying the value it stands for |
HotKeyBox |
hands over the combination it holds |
DropDownButton |
a button that opens and shuts, named after what it says on it |
FlipView |
says which page is showing and how many there are |
ColorCanvas |
every channel named after the letter beside it, slider and box alike |
FlyoutsControl |
answers a point only while a flyout is open, so the content underneath stays reachable |
ToggleSwitch, NumericUpDown, MetroWindow, Flyout, MetroHeader, ProgressRing, WindowCommands |
carry a peer of their own |
Everything else takes what its base type gives it. A MetroTabControl is a tab control, a MetroProgressBar a progress bar, a SplitButton a combo box, and each of them reports the class name of that base type rather than its own.
All of these are new on develop. In a released version a HotKeyBox is not in the tree, so the combination it holds hangs off nothing; a DropDownButton arrives as a list with no name, because the entries of its menu are its items and the button is nowhere to be seen; a FlipView is an empty list; and the seven channels of a ColorCanvas are sliders nobody named. This is #4454.
The odd one out is RevealImage. Its Text was never bound to anything in the template, so the caption was missing from the screen as much as from a reader. Also fixed on develop.
A flip view is the one that could not be given the usual shape. It builds nothing for the pages it is not showing, so there is no list of pages for a client to walk through. Rather than offer an empty selection it says where in the run the current page is, and the page itself, banner and all, is in the tree the way any content is.
Reaching a window at all
An inspection tool asks Windows what sits under the pointer, and that question goes by the box an element occupies rather than by what a click would hit. Anything lying over the whole window answers it, whether or not it draws something.
That is what the flyouts control did from .NET 8 on, which left nothing in a MetroWindow reachable for Accessibility Insights, inspect.exe, FlaUInspect or WinAppDriver. It is fixed on develop, and the Flyouts page has the detail.
Related
RangeSlider and Slider describe how a test drives them. Tile and Badged say what each hands to a reader.