* Reformat.
* Prepend some method names with `_`. GDScript convention is that private methods begin with `_`, and I'm slowly changing them over time.
* Speak that the user is focused on a button, not a texture button. That the button is a texture button is an implementation detail, and shouldn't change how they accessibly interact with or perceive it.
There seem to be a small handful of cases where we want this--controls that gain focus immediately after a dialog appears, for instance. We allow these edge cases to indicate that the next focus shouldn't stop speech, then clear it on cases where speech isn't stopped. This is a bit hacky, but seems cleaner than anything else I came up with.
This causes scrolling through trees, lists, and just about everything else where focus doesn't change to a new widget to fail. Clearly another solution is needed.
This reverts commit c459a35f0d.
* Remove indiscriminant speech stop on focus events.
* Only stop speech on input events that are keypresses.
* Don't interrupt speech when a dialog is presented.
Now dialogs present in their entirety without having their labels explicitly focused. This allows for Godot's default behavior, where the _OK_ button is automatically focused when the dialog appears, to speak the dialog text and the button as a screen reader user would expect.
Trees appear to eat "ui_accept" before `gui_input` receives it. This makes certain use cases--triggering buttons in cells--impossible via the keyboard.
Here, `ScreenReader` attempts to intercept recent presses of "ui_accept" and, if a button in a cell should receive focus, redirects the `InputEvent` to the custom handler for `Tree`.
Unfortunately, this loses the ability to click buttons in cells in the editor's node tree for some reason. It restores, or maybe gets working in the first place, clicking on the _Remove_ button in the input mapping screen. Not sure how to restore the former functionality--these trees are complex and not well-documented.
* Labels themselves don't have labels, so `guess_label()` on a `Label` returns null.
* Remove unused `is_in_bar()` function.
* Prepend `_` to more private function names.
Add necessary blank lines between items (even though they still displayed correctly).
Add additional indent spaces to ensure that "fenced" code blocks (both the back-tick open/close markers & the actual content ) are indented correctly in order to appear aligned with the rest of the item.
This change ensures that the items numbered 5, 6 & 7 appear as individual paragraphs with a list number instead of being run together in a single paragraph. The change inserts an extra blank line between list items which ensures their correct formatting.
However, the last sentence of item 4 is now indented incorrectly (it currently has no indent) but it was getting too complicated to figure out how to get all the content of item 4 indented correctly while also fixing the remaining items so decided to split the tasks.
That behavior is only specific to the editor. Any game UI that loses focus should be fixed by intelligently setting focus, not by magic in the accessibility addon.
* Don't manipulate selection in any way. Leave that to Godot, and I'll fix issues in the engine if needed.
* Unify speech rendering of tree rows. This results in more useful announcements of buttons and such when tree items receive focus.
* Only handle `ui_up` and `ui_down` to ensure that focus won't leave a tree when the top-most or bottom-most row is arrowed past.
* Add a bit of handling to strip out duplicate collapse/focus events generated by the remote `SceneTree` in an active game.
UI controls occasionally trap focus and make navigation impossible. Now, Ctrl+escape toggles a mode that attempts to intercept and generate UI focus events and bypass the control's own handling. This can probably be refined, but for now it allows escaping of `TextEdit` via tab. It also won't work everywhere--inn particular, arrowing around still traps focus in trees. But it is at least possible to tab out of most traps.
Further, event generation was cleaned up some. We specifically need to generate `KeyEvents` under Android because, IIRC, it wasn't enough to simply create and send some types of events. We now have two distinct generation strategies. These can probably be combined and streamlined, but for now this works.
