Introduce WT A11y Proposal 2023 #14319
Conversation
Note to readerIf there are any features that would have a positive accessibility impact, mention them here. Accessibility comes in many different ways, so features outside of UI Automation deserve to be mentioned too. Of course, we can add to this document as we come up with more ideas later too. 😉 |
| ### Respect Text Size OS setting | ||
| Windows Terminal has a profile setting for the font size (`"font"."size": <integer>`) which is then used when instantiating new terminal sessions. There should be a way to make the terminal font size respect the text size setting in Windows found in the Settings App > Accessibility > Text Size. | ||
|
|
||
| A possible solution is to scale the session's text size at runtime based on the OS setting. Furthermore, the Windows Terminal's settings UI should warn the user when they are attempting to modify the font size profile setting. |
There was a problem hiding this comment.
I think we shouldn't change the user given font size parameter - this could potentially make this setting appear as ambiguous/buggy/unexpected to users. Instead I believe the best way to go about it is to use it as a modifier for the default font size. So instead of always defaulting to 12pt, we'd default to a range between 12pt and 24pt.
There was a problem hiding this comment.
I think if the user is using this accessibility feature, they can be trusted to understand that "text scaling" means "text scaling wherever there's text."
We can display a hint in the settings UI if it's enabled:
| 1. Support for counting the total number of matches | ||
| 2. Displaying the number of results in the search box and announcing it via a UIA notification to the screen reader | ||
| Additional search features may fall into this including but not limited to: | ||
| - Highlight the search results in the scroll bar | ||
| - Successful searches should read the line where text was found (similar to VS Code experience) |
There was a problem hiding this comment.
FYI/BTW I benchmarked this and the runtime of <regex> practically depends entirely on the number of matches. Given a few thousand matches it takes about 100ms on a slower CPU, which is too much, but not /too/ much. std::boyer_moore_horspool_searcher would probably be a good alternative by default (>20x faster) if we consider that most of the time people aren't using the regexp search functionality in VS Code either.
doc/terminal-a11y-2023.md
Outdated
| - [**PSReadLine**](https://github.com/PowerShell/PSReadLine): a PowerShell module that enhances the input line experience | ||
| - [**Windows Subsystem for Linux (WSL)**](https://learn.microsoft.com/en-us/windows/wsl/): a tool to manage and run GNU/Linux environments without a traditional virtual machine | ||
| - [**PowerShell**](https://github.com/PowerShell/PowerShell): a cross-platform command-line shell (open source) | ||
| - **CMD**: a Windows-specific command-line shell |
There was a problem hiding this comment.
CMD is "regularly updated"? 😮
There was a problem hiding this comment.
Whoops, yeah that's not the case haha. My bad.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
zadjii-msft
added
the
Issue-Docs
The release of Windows Terminal has served as a way to reinvigorate the command-line ecosystem on Windows by providing a modern experience that is consistently updated. This experience has caused faster innovation in the Windows command-line ecosystem that can be seen across various areas like expanded virtual terminal sequence support and enhanced accessibility. Command-line apps can now leverage these innovations to create a better experience for the end-user.
Since accessibility is a very broad area, this document is intended to present recent innovations in the accessibility space for the command-line ecosystem. Furthermore, it will propose additional improvements that can be made alongside key stakeholders that could benefit from such changes.