WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ActiveX accessibility

for

From: Kelly Ford
Date: May 26, 2009 10:50AM

Jane,

Making ActiveX controls accessible is kind of a building block process that
requires you consider accessibility at each point in the process. Here's a
brief list of what needs to happen.

Before the list though, you should understand that ActiveX controls do not
work in all browsers and such. I'm ignoring that fact completely here but
depending on what you are working on, this could be a blocking issue to
start.

Add basic accessibility. ActiveX controls are really best thought of as
software applications that happen to run inside a browser. As such, the
ActiveX developer is responsible for adding accessibility to the control.
If your control happens to be based on standard win32 controls (not likely)
you'll get basic Microsoft Active Accessibility for free. If not, you need
to add accessibility support at the basic level to the control. This is
where Mark is saying you need to support IAccessible. Details for this are
at http://msdn.microsoft.com/en-us/library/ms696165.aspx.

You could use other platform level accessibility solutions too likeUI
Automation or IAccessible2 in theory. I've personally not been involved in
efforts to make ActiveX controls accessible with these two technologies.

If the control in question doesn't support some platform level accessibility
infrastructure (and adding it isn't an option), there is likely nothing you
can do to make it accessible.

Supposing the control itself does support an accessibility infrastructure.
Now you have to look at whether that infrastructure is going to work for
your target audience. If you are talking about screen readers for example,
you need to understand how the screen reader gets information from the web
browser. For example, JAWS by default ignores information from ActiveX
controls. There is a configuration file called fsdomsrv.ini that can be
modified to adjust this behavior but again if the control doesn't expose
things via an accessibility API, modification of this file won't do any good
because there won't be any info for JAWS to pick up.

The Window-Eyes screen reader would likely pick this info up by default
based on my experience. But there's no guarantee that it would all work
correctly in terms of user interaction.

These are just two examples. Obviously the full range of accessibility
needs to be considered.

Flash is really a good example of where all the building blocks had to come
together to support accessibility. The Flash developers had to add
accessibility for a basic accessibility infrastructure. They used MSAA.
They obviously then had to ensure that people writing Flash content could
give the needed information (object names and such) to support this
infrastructure. Then they had to work with the AT industry to ensure that
this accessibility info was used.

My hunch is that this is not quite the do 1, 2, 3 and your ActiveX control
will be accessible level of detail you are wanting.

Personally if I was doing this kind of an effort and the ActiveX control in
question didn't already support accessibility, I'd be looking for a
different solution versus trying to add accessibility support.