Problem/Bug: poor C# windows forms accessibility for disabled?

[waltborders]

Hi,

Because the blind are unable to use a mouse, keyboard navigation is
key. A major difficulty is that not all windows forms controls are
keyboard 'tab-able' or 'arrow-able' or have "tab order".

The application is built and the next step is to create the custom JAWS
(Freedom Scientific)screen reader script to read the application. The
application uses the accessibility properties for controls provided by
C#. JAWS reads properties these fine --using a mouse for access. For
example, JAWS can read ComboBoxes and DateTimePickers that are placed
into DataGrid cells without any problem. The problem is the lack of
keyboard access.

Using Microsoft's accessibility SDK 2.0 tools: AccExplorer32,
Inspect32, AccEvent32, I can gather a great deal of information. It
appears that C# controls can not be given individual unique IDs. JAWS
can navigate to IDs. Is there something that can act like a unique
identifier? Different classes/objects are simply labeled
WindowsForms10.Window.8.app3. This is too ambiguous. JAWS has a
limited number of recognized classes it understands, but a substitution
could be made if an unknown class was unique.

What about custom controls? Is there a way to uniquely ID C# custom
controls? There are many very interesting controls being developed in
the .NET world, that could be read if there where more identifiers.
Looking for help at MSDN and the Knowledge Base it seems that there is
a significant difference between C# and C/C++ functionality in this
context.

How can I have keyboard access to my C# windows forms application?

Can anyone offer any tips, or code samples?
Thanks,
Walt

My environment: C#, Windows Forms, Framework 1.1, VS.NET 2003, Windows
2000 & XP, JAWS 5.0

 

[Pete Davis]

Walt,

The company I work for is currently adding accessibility support to
custom controls used by our suite of applications. We're finding it
frustratingly difficult to get help for many aspects.

Since all the controls used in our application are custom, I can't really
speak to the accessibility issues of the .NET controls, except to say that
they are all based on the underlying Windows controls (with a few
exceptions, such as DataGrid, which is entirely .NET).

That means that anything not supplied by the framework, you're probably
going to have to manage yourself by deriving from the base objects and
adding the support, though I'm not sure how you'll handle IDs, particularly
for simple elements. You should be able to add any unincluded keyboard
support this way, though.

Does JAWS not use the AccessibleName and AccessibleDescription? If it
does, then you can set those in your code.

Actually, we're having a lot of trouble getting information about how to
handle Child IDs in some situations. I've posted to a number of newsgroups
(including this one) as well as talked to a few people at Microsoft and some
of the Accessibility hardware people and we're still don't have answers
after a few weeks.

As for custom controls, if you didn't code them, then it's unlikely there
will be any accessibility support in them. That's been my experience so far.

If you want to contact me by e-mail, feel free (just remove the NOSPAM.
from the e-mail address) and I'll be happy to help where I can.

Pete

 

[Nicholas Paldino [.NET/C# MVP]]

Pete and Walt,

Can you elaborate on the nature of these unique id's that you need? I
am not too familiar with accessibility, but my thinking is that if you need
a unique id for a control, just use the handle of the window.

 

[Pete Davis]

Actually, I'd be hard pressed to give you a lot of details about it since
that's part of the problem I'm trying to solve.

The handle won't work because not all AccessibleObject derived classes are
controls. For example, in a grid, you have the grid itself which is a
control and the scrollbars are controls. But there are accessible objects
that represent columns, rows, and cells which aren't controls. These need
unique IDs of some type.

If it's not built into the implementation of the accessible object, then
there's no real way to add it.

It's a really strange implementation because the IDs are used in a number of
methods. For example, the Control.AccessibilityNotifyClients() is used to
notify of events related to an accessible object in the control's hiearchy.
For example, I would send a AccessibilityNotifyClients() to notify of a row
being scrolled out of view. The cell would be identified by a unique ID
passed to AccessibilityNotifyClient.

The problem is, the ID isn't part of AccessibleObject (or the IAccessible
interface which is the base for the COM Accessibility stuff). So the problem
I'm running into is trying to figure out how to associate the ID that I pass
to AccessibilityNotifyClients() with the cell (or even to get the ID for a
cell).

Unfortunately, it appears there are maybe a handful of people that
understand this stuff. I've talked to Sara Ford at MS (she's one of the
Visual Studio Core testers who specializes in Accessibility), but apparently
I've stumped her as well and she said she'd pass my question along to
someone on the accessibility team and that's the last I heard. I know
they're busy trying to get the next version out, so I suspect it got swept
under the rug.

Pete

Pete and Walt,

Can you elaborate on the nature of these unique id's that you need? I
am not too familiar with accessibility, but my thinking is that if you need
a unique id for a control, just use the handle of the window.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Walt,

The company I work for is currently adding accessibility support to
custom controls used by our suite of applications. We're finding it
frustratingly difficult to get help for many aspects.

Since all the controls used in our application are custom, I can't
really
speak to the accessibility issues of the .NET controls, except to say that
they are all based on the underlying Windows controls (with a few
exceptions, such as DataGrid, which is entirely .NET).

That means that anything not supplied by the framework, you're probably
going to have to manage yourself by deriving from the base objects and
adding the support, though I'm not sure how you'll handle IDs,
particularly
for simple elements. You should be able to add any unincluded keyboard
support this way, though.

Does JAWS not use the AccessibleName and AccessibleDescription? If it
does, then you can set those in your code.

Actually, we're having a lot of trouble getting information about how to
handle Child IDs in some situations. I've posted to a number of newsgroups
(including this one) as well as talked to a few people at Microsoft and
some
of the Accessibility hardware people and we're still don't have answers
after a few weeks.

As for custom controls, if you didn't code them, then it's unlikely
there
will be any accessibility support in them. That's been my experience so
far.

If you want to contact me by e-mail, feel free (just remove the NOSPAM.
from the e-mail address) and I'll be happy to help where I can.

Pete

 

[Pete Davis]

Why is it that every time I get into an Accessibility discussion on the any
of the newsgroups that the moment I post this particular issue, the
conversation dies?

I can't tell you all how frustrating this is. Nobody seems to know the
answer to this question, not even the two people I've spoken to at Microsoft
who are by most standards, accessibility experts.

I mean, this shouldn't be rocket science and it could be easily solved with
clearer and more complete documentation.

Oh well, we may never get an answer to it.

Pete

Actually, I'd be hard pressed to give you a lot of details about it since
that's part of the problem I'm trying to solve.

The handle won't work because not all AccessibleObject derived classes are
controls. For example, in a grid, you have the grid itself which is a
control and the scrollbars are controls. But there are accessible objects
that represent columns, rows, and cells which aren't controls. These need
unique IDs of some type.

If it's not built into the implementation of the accessible object, then
there's no real way to add it.

It's a really strange implementation because the IDs are used in a number of
methods. For example, the Control.AccessibilityNotifyClients() is used to
notify of events related to an accessible object in the control's hiearchy.
For example, I would send a AccessibilityNotifyClients() to notify of a row
being scrolled out of view. The cell would be identified by a unique ID
passed to AccessibilityNotifyClient.

The problem is, the ID isn't part of AccessibleObject (or the IAccessible
interface which is the base for the COM Accessibility stuff). So the problem
I'm running into is trying to figure out how to associate the ID that I pass
to AccessibilityNotifyClients() with the cell (or even to get the ID for a
cell).

Unfortunately, it appears there are maybe a handful of people that
understand this stuff. I've talked to Sara Ford at MS (she's one of the
Visual Studio Core testers who specializes in Accessibility), but apparently
I've stumped her as well and she said she'd pass my question along to
someone on the accessibility team and that's the last I heard. I know
they're busy trying to get the next version out, so I suspect it got swept
under the rug.

Pete



message news:[email protected]...

Pete and Walt,

Can you elaborate on the nature of these unique id's that you need? I
am not too familiar with accessibility, but my thinking is that if you need
a unique id for a control, just use the handle of the window.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Walt,

The company I work for is currently adding accessibility support to
custom controls used by our suite of applications. We're finding it
frustratingly difficult to get help for many aspects.

Since all the controls used in our application are custom, I can't
really
speak to the accessibility issues of the .NET controls, except to say that
they are all based on the underlying Windows controls (with a few
exceptions, such as DataGrid, which is entirely .NET).

That means that anything not supplied by the framework, you're probably
going to have to manage yourself by deriving from the base objects and
adding the support, though I'm not sure how you'll handle IDs,
particularly
for simple elements. You should be able to add any unincluded keyboard
support this way, though.

Does JAWS not use the AccessibleName and AccessibleDescription? If it
does, then you can set those in your code.

Actually, we're having a lot of trouble getting information about

how

to