SftButton/DLL 3.0 ships with built-in Windows UI Automation (UIA) support. Users who rely on Narrator, NVDA, JAWS or any other UIA-compatible assistive technology can read and operate SftButton controls without the hosting application doing any work. No opt-in, no code change, no separate build.
What the screen reader sees:
| Control type | Button. For buttons with a dropdown arrow (fShowDropDown set), the control type becomes SplitButton so the user hears "split button" and can invoke the primary action and the dropdown arrow independently. |
| Name | The button's text (with the ampersand accelerator prefix stripped for speech). |
| Toggle state | For toggle buttons (fToggle set), the current pressed state is exposed through the Toggle pattern. The screen reader announces "pressed" / "not pressed". |
| Help text | Any tooltip the application has set on the control is routed through the UIA HelpText property. |
| Patterns implemented | Invoke, Toggle (for toggle buttons), ExpandCollapse (for split buttons, for the dropdown arrow), Value (read-only - the button text). |
Event notifications raised automatically: invoke, toggle-state changed, keyboard focus changed.
There is nothing to turn on. The provider loads on demand the first time a UIA client queries the control, so there is no overhead for applications whose users never attach an assistive technology.
The main thing the application controls is the button's text - screen readers read it first, so a generic "OK" tells the user less than "Save and close this document".
Dark mode (the Windows "Choose your mode" personalization setting) and Windows High Contrast (an accessibility setting) are independent. SftButton follows High Contrast by default, and follows dark mode once SetDarkMode is called with SFTBUTTON_DARKMODE_AUTO (see SetDarkMode and SetHighContrastMode).