Feat: Accessible-name fallback for UI buttons (screen reader support)

[hesam-oxe]

Summary

Fixes the missing accessible names reported for icon-only buttons in issue #476. Ui::AbstractButton now exposes an accessible name automatically:

• If an explicit setAccessibleName() was set, it is used as before.
• Otherwise the button's toolTip() is used as a fallback.

FlatButton and SettingsButton also call setAccessibleName() from their text, so screen readers (NVDA/JAWS/ORCA) can announce every button without per-call-site fixes.

This is the foundational, low-risk part of the accessibility work: it gives every button a name. The deeper focus-navigation (chat-list tab order), context-menu focus announcements, inline-media InvokePattern, and voice-recording keyboard alternatives discussed in #476 are planned follow-ups and are NOT part of this PR.

Where the code lives

The implementation is in the lib_ui submodule:

• hesam-oxe/lib_ui@feat/accessibility-base-refactor (PR to desktop-app/lib_ui)
• AbstractButton::accessibilityName() in ui/abstract_button.cpp
• FlatButton::setText / SettingsButton::setText in ui/widgets/buttons.cpp

This tdesktop PR only bumps the lib_ui submodule pointer to that commit and adds a standalone verification snippet under Telegram/SourceFiles/test/accessibility_names_snippet.cpp (not wired into the CMake build; it compiles against Qt directly).

Testing

The fallback logic was verified with a standalone Qt program (offscreen platform) covering: icon-only button -> tooltip becomes the name; explicit accessibleName() wins; empty when neither is set. Full integration build is performed by the maintainer toolchain.

Related

• Issue: tdesktop should be screen-reader friendly #476
• Depends on: desktop-app/lib_ui PR (same branch name) so the submodule commit resolves.

[CLAassistant]

All committers have signed the CLA.

[ilya-fedin]

The same problem as in #31198: wrong lib_ui commit

[hesam-oxe]

@cla-assistant check

[hesam-oxe]

@ilya-fedin Same fix here — the submodule no longer points into my fork and stays on the upstream commit.

For transparency: parts of the tdesktop-side code (the sub-item InvokePattern support in HistoryInner / ListWidget) override the new accessibilityChildSubItem* virtuals introduced in desktop-app/lib_ui#356, so this branch will not compile against upstream lib_ui until that PR merges. I have marked it as draft accordingly; once #356 lands I will bump the submodule to the merged upstream commit and ping you for re-review. The remaining changes (voice-record toggle, focus handling, reply links, dialog key handling) are plain tdesktop/Qt code and independent of the lib_ui change.

[ilya-fedin]

Same question as for #31198 - should the test land upstream?

[hesam-oxe]

@ilya-fedin You're right, and honestly — no, it shouldn't. That snippet was a scratch verification file written during development of the lib_ui changes (it has its own main() and isn't wired into the build or Test::Runner), and it slipped into this branch when I split the work across repos. I've dropped it from the branch (b686ddd): the PR now contains only the functional commits — the voice-record keyboard toggle and the focus/invoke/reply-link work.

For completeness on the shape of this PR: it depends on the lib_ui-side changes in desktop-app/lib_ui#356 and desktop-app/lib_ui#357; the plan was to bump the submodule here once those land upstream, which is why it's a draft. If you'd rather see it reworked differently (or not at all until lib_ui is settled), just say the word.