Re: Generic windows forms accessibility for generic screen readers
Re: Generic windows forms accessibility for generic screen readers Typically the accessible description attribute is used to provide information that tooltips might provide, for example. The accessible name attribute isn't usually used unless your making edit boxes, tree views and such. When you do use it it should match the label placed above the control in question. You shouldn't have to mess with the accessible role attribute unless NVDA identifies the control as something that its not (which I've never seen happen). URL: https://forum.audiogames.net/post/520120/#p520120 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Generic windows forms accessibility for generic screen readers
Re: Generic windows forms accessibility for generic screen readers Ian really is a wonderful gentleman. He always gives very helpful answers without ever being snide or snarky, neither contentious nor contrary.Kai URL: https://forum.audiogames.net/post/519684/#p519684 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Generic windows forms accessibility for generic screen readers
Re: Generic windows forms accessibility for generic screen readers Ian - you are a legend. I had to see this for myself so I just ran your code in a dummy project and it's as you report. It says the text on the first button and then the accessible name of the second.I'd failed to understand the difference between the native text on a UI element, its AccessibleName and AccessibleDescription attributes and how they were being used - so when NVDA was picking up the button text it was then saying the accessible description text after that and as such it was doubling up because they were both the same thing.Thanks so much for your clarification. URL: https://forum.audiogames.net/post/519648/#p519648 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Generic windows forms accessibility for generic screen readers
Re: Generic windows forms accessibility for generic screen readers
I just tested with the following code: public partial class Form1 : Form { public Form1() { InitializeComponent(); var b = new Button(); b.Text = "Press me"; this.Controls.Add(b); var b2 = new Button(); b2.Text = "Press me 2"; b2.AccessibleName = "B2's accessible name"; this.Controls.Add(b2); } }I tested by:Creating a .NET Framework 4 client profile WinForms app in VS 2010.Creating a .NET Framework 4.8 WinForms app in VS 2019.Creating a .NET Core 3.0 WinForms app in VS 2019.I tested with both NVDA and JAWS.When tabbing between the buttons, all scenarios spoke exactly the same.They said "Press me button" for the first button, and "B2's accessible name button" for the second button.JAWS also spoke a help tip telling meI could press spacebar to activate the button, but I'm sure that can be turned off in JAWS settings.There was no duplicate speaking of text and accessible name that I noticed, and the buttons always spoke.I am running Windows 7, so perhaps running on Windows 10 gives different results.Or perhaps you are using a different framework version than I tested with.If you like, you can email me your program/solution at i...@blindaudiogames.com and I will test it to see if it works any better for me, or perhaps I can spot the difference that is causing the issue.Quentin C is kind enough to publish the playroom statistics:https://qcsalon.net/en/stats?generalUnder the "Screen readers used" heading you can see that JAWS is used by 43.84%, and NVDA is used by 51.5%, out of 13,244 users.That accounts for 95.34% of the users included in the stat.Personally, I would only worry about supporting NVDA and JAWS on Windows.And as Camlorn said, using the operating system controls (which WinForms does) should not require any extra work on your part to get decent accessibility.Speaking extra notifications through Tolk can be a good idea if used appropriately.
URL: https://forum.audiogames.net/post/519637/#p519637
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Generic windows forms accessibility for generic screen readers
Re: Generic windows forms accessibility for generic screen readers Very much appreciate your feedback. I think I'll just leave the general UI without specific accessibility hints so all the buttons and UI elements read out as theiy're named or have text on them. I just wanted to be sure that I wasn't accidentally going outside best practice or anything. URL: https://forum.audiogames.net/post/519634/#p519634 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Generic windows forms accessibility for generic screen readers
Re: Generic windows forms accessibility for generic screen readers Actually, as another kind of important followup to this: in general the OS-provided controls are already accessible and extending them will get you into trouble. So if it's a button and it already does the button things, everyone is going to already know how to pull button things from it without you doing anything, and you trying to make it special is probably going to end frustratingly. URL: https://forum.audiogames.net/post/519581/#p519581 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Generic windows forms accessibility for generic screen readers
Re: Generic windows forms accessibility for generic screen readers I'd suggest NVDA and Narrator as your test, and then let people using other screen readers report bugs. I know that many shops have gone that route, though I don't have specific examples offhand.There is no standard. The accessibility APIs aren't screen reader specific--for example they're also for one-switch controllers and dictation solutions. Also, there are literally 50+ settings in each screen reader that can change behaviors in one way or another. My advice is either be prepared to keep up with the maintenance, or don't add properties to controls (i.e. just use a standard button, standard checkbox, etc). It should be possible to do UIA or something if you use a screen reader yourself, and have an at least okay experience on others, but if you're actually approaching this from the perspective of a sighted programmer trying to work it out, it's probably best avoided.Jaws, NVDA, and Narrator will cover 90% of the market. NVDA and Narrator probably covers 40-% to 50% of the market if not more at this point, and is also what lots of places use to test with, since no one really wants to buy all their frontend devs licenses for Jaws. On the whole and as someone who has done some Aria stuff and who is considering doing a virtual GUI library at some point for game devs, "I test with NVDA and narrator and will work with you on bugs if you use something else" hits all my ethical due diligence boxes. URL: https://forum.audiogames.net/post/519558/#p519558 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
