WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Navigate to browser toolbar when plug-in is present

for

From: John Foliot - WATS.ca
Date: Jun 1, 2004 12:52PM

>
> We have a browser-based application that can host an in-line
> plug-in, such as MS Word (.doc), MS Excel (.xls), and Adobe
> (.pdf) files that are opened into the browser. How can we
> navigate to the Browser or the Document Viewer toolbar using the
> keyboard when the plug-in is opened in the browser window?
>
> We've reviewed the Internet Explorer Keyboard shortcut lists and
> reviewing on-line help for the individual applications, but we
> have not found a solution.
>
> To explain the problem, once the in-line plug-in is present,
> keyboard inputs, such as Alt+D (to take you to the Address bar),
> no longer work.
>
> Can someone help me to understand the proper (from 508 & WAI
> Guidelines) behavior and how to achieve this?
>


Yikes!

The simple answer is don't use the plug-in, convert the content to a
"recognized W3C Technology" (Priority 2 - 11.1 "Use W3C technologies when
they are available and appropriate for a task and use the latest versions
when supported.") As well, the Priority 1 checkpoints indicate: "And if you
use applets and scripts (Priority 1) - 6.3 Ensure that pages are usable when
scripts, applets, or other programmatic objects are turned off or not
supported. If this is not possible, provide equivalent information on an
alternative accessible page." Your plug-in certainly qualifies as a
"programmatic object" in the context of this checkpoint.

While this may not be the answer you seek, it is unfortunately the answer
you need. The intent of HTML is, was and will always be to be a vendor and
operating platform neutral mark up language which conveys semantic structure
to your content. If you are obligated to provide content in other file
formats to your clientele, then do so as downloadable objects, which the
clients can then save and open using the appropriate application. This of
course opens up other access issues, as it is unreasonable to expect each
user coming to your site to have the appropriate application all of the
time - the Acrobat Reader is a free download, true, but what about the
Microsoft Office files? It is for this reason that Priority 2 - 11.1
exists.

I would also be doubly concerned that you are looking *only* at IE keyboard
shortcuts: what about the plethora of other browsers out there? Developing
for one browser without regard to others is a dangerous and troubling
concept, and certainly goes against my interpretation of Universal
Accessibility, which *should be* browser agnostic. While it is true that
currently Internet Explore holds a commanding market share, some of us old
dogs remember when Netscape ruled the web, and who knows, perhaps one day a
different browser will be top dog. The days of "Best viewed in X Browser"
should be long gone by now.

Without seeing your application and plug-in, but based upon what you have
indicated, the current solution will never be W3C/WCAG compliant, and
probably not Section 508 either. (508 Standard - (m) "When a web page
requires that an applet, plug-in or other application be present on the
client system to interpret page content, the page must provide a link to a
plug-in or applet that complies with ?1194.21(a) through (l).") See the
checklist at the WebAIM web site:
http://www.webaim.org/standards/508/checklist which explains further the
requirements for Pass or Fail. If you are mandated however to achieve
either of these standards/guidelines then it appears that you will need to
abandon the plug-in solution.

Good Luck

JF
--
John Foliot <EMAIL REMOVED>
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)