E-mail List Archives
Thread: Navigate to browser toolbar when plug-in is present
Number of posts in this thread: 3 (In chronological order)
From: Lisa Pappas
Date: Tue, Jun 01 2004 7:24AM
Subject: Navigate to browser toolbar when plug-in is present
No previous message | Next message →
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?
Thank you for any guidance!
-Lisa
===================Lisa Pappas
accessibility analyst
SAS Institute, Inc.
= EMAIL ADDRESS REMOVED =
====================
From: John Foliot - WATS.ca
Date: Tue, Jun 01 2004 12:52PM
Subject: Re: Navigate to browser toolbar when plug-in is present
← Previous message | Next message →
>
> 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 ADDRESS REMOVED =
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca 1.866.932.4878 (North America)
From: Lisa Pappas
Date: Tue, Jun 01 2004 1:05PM
Subject: Re: Navigate to browser toolbar when plug-in is present
← Previous message | No next message
John,
Thank you for the thorough response. I agree with you that the most accessible option would be NOT to use the plug-ins. However, it's a nature of the product. Specifically, there is a purchaseable Microsoft-specific add-on (to take our statistical data & graphs into Word or Excel for familiar reporting). One option is to download the file; another is to view and tweak it within the browser window. The PDF plug-in is another customer-commanded feature as our customers deliver reports in signed PDFs. They want to generate them from the data, view the output, then save the PDFs for distribution. Incidentally, the PDFs produced are accessible.
-Lisa