NVDA treats buttons, list items and score elements as editable text

Issue type

Accessibility issue (e.g. for keyboard-only or screen reader users)

Description with steps to reproduce

Many if not all accessible controls in MuseScore Studio report that they contain text (like a text control) because they have the UI Automation Text pattern, whatever their role. Buttons, check boxes, list items, groups and non-text score elements all claim to be text. For all of them the exposed text document is empty.

Screen readers such as NVDA treat any element with a Text pattern as a text container. When focus is on such a control and an arrow key does not move focus, NVDA reads the text at the caret. The document is empty, so NVDA reports "blank" or otherwise behaves as if the user were inside an empty edit field. Text review and braille routing operate on the empty document instead of on the control's name. It might even cause braille to malfunction, as reported in https://github.com/nvaccess/nvda/issues/20791.

Steps with NVDA:

1. Open the new score window.
2. Tab to the cancel button.
3. Press Left arrow.

Actual behaviour: NVDA says blank
Expected behaviour: NVDA announces nothing like blankness, because the button is not a text document.

Note that NVDA can work around this by just ignoring the text information of the control, but that's just not how things work in the UIA ecosystem.

Supporting files, videos and screenshots

N/A. The behaviour is visible in any UIA inspection tool without files.

In which versions of MuseScore Studio is this issue present?

4.0.0 - 4.7.5, and current master.

Regression

No.

Operating system

Windows 11. The same cause affects the AT-SPI Text interface on Linux, but this is untested.

Additional context

The root cause and a proposed one-line fix are documented in the framework tracker: musescore/muse_framework#284.

In short: Qt's UI Automation backend offers the Text pattern exactly when the accessible interface returns a text interface. The framework's AccessibleItemInterface::interface_cast returns that interface unconditionally, for every role. Restricting it to the EditableText role fixes this. Score text elements already register with that role, so text editing on the score keeps its Text pattern.

This re-files #20732. That issue described the same cause. It was closed with a pointer to #30463, and I cannot reopen it. That said, it definitely shouldn't have been closed at all because the underlying issue wasn't fixed, rather at most worked around.

Checklist

• This report follows the guidelines for reporting bugs and issues
• I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• I have attached all requested files and information to this report
• I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible