Hi!
If you're using NVDA and fold code in the xalm editor NVDA will only
read the first word, i e "Label", "StackPanel" and so on. If you have
useful eyes you can see that the attributes on the first line has a dim
color but aren't spoken.
If NVDA would read the entire first line of the folded code one could
have the name of the control there and that way easily know what control
it is without having to unfold it.
If one could write comments <!-- Search controls --> in the xaml it
would be possible to organize controls into blocks so you know where you
are when arrowing around in the xaml.
I think I found a bug in the WPF ListBox related to its selected index
if it's set when the window is loaded. I've created a list of companies
you can choose from and it's set to the last opened one. I tried to set
the listbox as the initially focused control but NVDA doesn't read the
selection. It behaves the same if I don't set the initial focus and have
to tab into it. The really problematic behavior is that regardless of
what list item was selected it will select the first list item when you
press arrow down. This makes it impossible to know what value was
pre-selected if you're a screen reader, or at least a NVDA user.
Thanks for sharing your results.
Cheers
Karl-Otto
Karl-Otto Rosenqvist
MAWINGU
Orgnr: 750804-3937
+46 (0)701 75 98 56
karl-otto@xxxxxxxxxx
Den 2021-03-19 kl. 18:15, skrev Andy Borka:
Hi,** To leave the list, click on the immediately-following link:-
I took a while to experiment around with the WPF designer in Visual Studio 2019. Here are some interesting points that came from that experiment.
* To force the designer to not change margins, change the ‘insert
layout properties when dropping controls on the designer’ setting,
which can be found in the XAML designer node of the options dialog.
* As a screen reader user, it might be faster using the XAML editor
since we are required to tab around the properties window instead of
arrowing through attributes and events.
* When using the designer, NVDA’s Developer toolkit addon found at
http://www.github.com/ajborka/nvda_developer_toolkit
<http://www.github.com/ajborka/nvda_developer_toolkit> gives proper
sizes and placements.
* The designer is completely accessible for NVDA/JAWS users as long as
we assign a name and automationProperties.name to the control.
* In Visual Studio 2019 16.9.x, the AutomationProperties category
doesn’t read when tabbing through the properties window.
* In Visual Studio 2019 16.10.x preview, the above point is no longer
valid.
* Sometimes, we will have to save and reload the designer to refresh
the control state since NVDA/JAWS doesn’t always read the new names
of controls after changing properties in the properties window.
* The size of the design surface may not reflect the size of the
window at runtime, so keep actual/design time rendering in mind.
* Turning on descriptions in NVDA’s object presentation settings will
read AutomationProperties.HelpText when tabbing through the designer.
Overall, the WPF designer is a safe and pleasant experience, but it lacks in efficiency with screen reader users. Some other points on WPF/WinUI3 that I noticed in general follow.
* The layout managers such as Stack panel, Doc panel, Tab control,
Canvas, and Flow layout panel may cause difficulty for screen reader
users to understand.
o When setting Horizontal or Vertical alignments, it appears
controls require manual resizing or a width/height attribute.
o When setting Horizontal/Vertical orientation modes, the layout
manager will resize in the direction of the orientation mode.
o Setting Horizontal orientation will horizontally resize based on
control width and vertically take the remaining space.
o Setting Vertical orientation will vertically resize based on
control height and horizontally take the remaining space.
* Based on how complex a layout can get, folding controls in the XAML
editor proves a benefit.
* Control’s are easier to read and manage in the XAML editor when each
attribute is on a line by itself.
* Setting focus to the first logical input control in a window is
needed to achieve the default WinForms behavior.
If anything is wrong here, feel free to comment.
