A small GUI toolkit can still be the right tool.
The Tcl Core Team released Tcl/Tk 9.1.0 on September 29. Tcl 9.1 adds Unicode normalization, a monotonic microsecond timer, list filtering, larger-size APIs, and more memory-efficient list internals.[1] Tk 9.1 adds a core toggle-switch widget, screen-reader support, bidirectional text on Windows and X11, consistent dark mode on Windows and macOS, native file icons, and locale-aware word handling.[2]
That list is not a nostalgia exhibit. It is maintenance work on the seams that decide whether a small desktop utility feels usable outside the maintainer's machine.
The useful question is not "Is this toolkit modern?" Ask whether its current contracts fit the tool you need to ship.
Accessibility belongs in the runtime, then in the test plan.
Core screen-reader support changes the starting point. It does not certify an application. Labels, reading order, focus movement, state announcements, contrast, zoom, and keyboard escape still depend on the app and platform.
Do not turn a release-note bullet into an accessibility claim. Build the smallest representative window. Test it with the target operating system, screen reader, keyboard path, scaling setting, and language direction. Save the results beside the toolkit version.
Read the incompatibility list before admiring the feature list.
Tk 9.1 is a minor release in the 9.x line, but the release announcement names known changes from 9.0. Negative screen distances are rejected in most cases. X11 builds enable bidirectional text by default and require HarfBuzz. Windows removes old XP dialog variants and the xpnative theme in favor of vista.[2]
The larger cut is between 8.6 and 9.x. Tk 9.1 does not support Tcl 8.6. An existing 8.6 application needs an upgrade branch and representative replay. A green launch is not enough. Exercise text input, dialogs, menus, images, scaling, themes, packaging, and any native extension.
Use boring tools for bounded jobs.
A small internal utility, inspector, teaching tool, or operator console may benefit from a compact toolkit and direct native controls. A browser-delivered product, a highly animated canvas, or an app tied to a large component ecosystem may need a different route.
Tool choice is a workload decision. Write the distribution target, supported platforms, assistive-technology test matrix, extension dependencies, and update path before choosing. Then build one representative slice and let the failure modes vote.