E-mail List Archives

Re: ActiveX accessibility


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


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

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.

-----Original Message-----
From: J. B-Vincent [mailto: <EMAIL REMOVED> ]
Sent: Saturday, May 23, 2009 4:57 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] ActiveX accessibility

Thanks Kelly (and Mark); always good to see fellow former Trace Elements in
the discussion groups:

I've run across a website with an ActiveX object (actually, it's the only
thing on the page), and I'm trying to advise the client about how to make it
508 compliant. Since the object may be from an third-party author, the best
option in this case might be to have a redundant accessible version, but I'm
also trying to put together information on dealing with ActiveX in general.
There don't seem to be public guidelines available the way there are for
Java or other languages. Any/all info much appreciated.


--- On Sat, 5/23/09, Kelly Ford < <EMAIL REMOVED> > wrote:

From: Kelly Ford < <EMAIL REMOVED> >
Subject: Re: [WebAIM] ActiveX accessibility
To: "'WebAIM Discussion List'" < <EMAIL REMOVED> >
Date: Saturday, May 23, 2009, 4:43 PM

Hey Jane,

Can you give any further details on exactly what you are trying to do here?
Just adding Microsoft Active Accessibility support to an ActiveX control
isn't likely to accomplish what you want, depending on what you are trying
to do.  If screen readers are involved as an example, there will be other
steps you'll probably need to take

Are you building your own control for example that is going to display a
user interface for people to use?

BTW, hello from another former Madisonian.

If you can give a bit more of an idea I can probably get you the details you


-----Original Message-----
From: J. B-Vincent [mailto: <EMAIL REMOVED> ]
Sent: Thursday, May 21, 2009 9:37 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] ActiveX accessibility

Hi Mark:

I found a lot about iAccessible, but very little practical guidance about
how to use it with ActiveX.

Thanks, and say hi to State Street for me,

--- On Thu, 5/21/09, mark novak < <EMAIL REMOVED> > wrote:

From: mark novak < <EMAIL REMOVED> >
Subject: Re: [WebAIM] ActiveX accessibility
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Date: Thursday, May 21, 2009, 9:32 AM

hi Jane

Do you mean the "iAccessible" interface ?  If so, I think you will find
lots of
info searching on Google ...



J. B-Vincent wrote:
> Good morning:
> I've been scouring the Web for information on accessibility and ActiveX
scripting. There are some references to use of iAccessibility, but even that
is scanty. Any leads to more robust writeups would be much
> Jane Vincent, Center for Accessible Technology, Berkeley, CA