Okay thanks; it will be a while though because even once I start to work with forms (and I'm backlogged as it is since MS certification is higher on the priority list right now) I still might have to do some specific research on the specific controls used. And not to mention, what if the accessibility information exposed by SQL Server Management studio 2012 is UIA and not MSAA? Will it still work? Should I try talking to Microsoft about this and see if they can start applying some more consistent standards to the way they develop programs? I have direct contact with the head of accessibility over there. And in terms of reading the controls in SQL Server Management studio during database creation, it's not so much reading them the way I want, but it's more about ensuring that they are read properly. Like half of the dialog doesn't read at all; there's where the issue is. But I'm not sure if you guys took a look at my accessibility test of the latest TFS (Team Foundation Server) beta? If not, then you probably should, because there's an example of where mirror drivers and current accessibility mechanisms will no longer apply. To see it, go to: http://youtube.com/thechromebuster. But thanks all who have participated in this thread so far. I appreciate the input and the clarification. -----Original Message----- From: Stephen Clower [mailto:[email protected]] Sent: Monday, July 30, 2012 11:31 AM To: [email protected] Subject: Re: Creating apps to give Window-Eyes support for certain control types?
FYI, the problem with the Microsoft grid controls is that there is no consistent accessibility design from one implementation to the next. A technique which would work in something like Fox Pro won't work in Project, and one technique which works in Project fails in .NET. Additionally, depending on the control type, version of .NET in use, OS, phase of the moon, and price of gold every other Thursday, the control may not provide enough information to be useful to an adaptive technology. Thus, every single application which implements a so-called grid must be examined and special-cased on an app-by-app basis. It isn't that we refuse to support grids-- simply that the consistent inconsistencies in the varying implementations out there make it impractical to create a 100% reliable catch-all solution. That said, you can typically monitor MSAA focus events in such controls and traverse the tree based on what you get back to determine where you are in most grids. I haven't tried VS 2012 but suspect this would work to at least get you started. Regards, Steve On 7/30/2012 10:51 AM, RicksPlace wrote: > Hi Kate: > When you say you tried to create a Sql DB did you use Visual Studio or Sql > Management Studio or something else? > SQL Management Studio has been messy over the years but I've not had to > script it but didnt work much with those features which did get messy to even > look at and seemed pretty bad. > Those Grid controls are used all over the MS Environment and have been > problematic since 2005 when I first asked GW about them and was told they > were not standard controls and not supported in WE. > I am not sure about today's WE though. > Now, if you want to script a grid control you can do it, I did it in an old > script and got it to work much better but that was several years ago and I am > not sure I still have that script around. > When you create the script you are best served in this case to create the > script to work with the program you are using. > So, if you are using Sql Server Management Studio you would create a script > for Sql Server Management Studio and address either Grid Controls in general > or that particular Grid Control to make it read the way you want. > Note that some Grid Controls are arranged by Columns Within Rows ( Normal > Layout ) and some are arranged Rows within Columns ( a wierd but sometimes > used version of the Grid Control). > I would recommend building a script for the particular application like Sql > Management Studio or Visual Studio and then scripting that particular Grid > Control. > That way you can address any other accessibility issues within that > application and keep it all associated to that specific program whenever you > open it for use and wont step on any other programs. > Rick USA > > > ----- Original Message ----- > From: Katherine Moss > To: [email protected] > > Sent: Monday, July 30, 2012 9:36 AM > Subject: Creating apps to give Window-Eyes support for certain control > types? > > > I've probably asked this question before, but I still don't necessarily > understand it. I was just trying to create a database in SQL Server 2012 > (full edition) and I have realized that with the limited support that > Window-Eyes (and JAWS for that matter) has for it, it is extremely hard to > make any advanced configurations with said database (using filegroups and > secondary .ndf files to split the data across files, growth configuration, > and others) that could make life easier. I'm learning how to write code in > C#, and I'd like my first project to be a Window-Eyes app that will fix this > .net grid control issue, and so I was wondering if anybody had any current > samples in .net 2010/4.0 I could look at like from past projects? And then > my next question is this; should I target the actual program (MSSQL Server > 2012), or should I target the control type (.net grid control, which I was > told by support that is currently not, and will not in any future version, be > supported)? Thanks. > -- Stephen Clower Product support specialist & App Development GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825 260-489-3671 * gwmicro.com
