Re: How do I make JavaScript "pop-up help" accessible?

Actually, I don't have public pages anymore that do this. I changed my mind
because it's conceivable that there are situations where a person might be
using a known browser but have some of that browser's usual functions
unavailable to them. For example, a public web kiosk might be set up using
IE as the browser but with close buttons/commands disabled (to discourage
people from trying to close the browser and run other tasks). A rare case,
but conceivable, so I am positive there must be others I haven't thought of
too. There are usually reasons why a particular guideline (as Mr.
McCathieNevile pointed out) exists in the WCAG.

Still, I dug through my code box and pulled out the functions I used to use,
for those who are curious:

function PopupWindow( pageLoc ) {
  // The parameters are of course changeable
  hPopupWin = window.open( pageLoc, 'PopupWindow',
'location=no,menubar=no,toolbar=no,resizable=yes,scrollbars=yes,titlebar=no,
status=no,height=500,width=400' );
}

function WritePopup( pageLoc, linkText ) {
  var s = '<a href="javascript: PopupWindow( \'' + pageLoc + '\' );"><img
src="popup_link.gif" alt="Popup window: " width="12" height="10" /> ' +
linkText + '</a>';
  document.write( s );
}

function WriteCloseWindow( ) {
 var s = '<a href="javascript: window.close();">Close window</a>';
 document.write( s );
}

You'll notice there's an image included in the WritePopup() function; I put
that in so there'd be a clue (a little 10x12 icon for visual users and an
ALT "Popup window: " string for persons who are not so inclined) preceding
each popup link. In addition I employed the same script/noscript pairing,
using the WriteCloseWindow() function, on each destination page so that
users who had JS enabled (and thus reached the page by way of a new,
browser-spawned window) would have that window closed while others could
just have a typical "back" link.

Side remark: I also used to have, on the popup-spawned windows, an invisible
(style="position:absolute; top:-100em") chunk of text that said "this is a
popup window" for users who are blind. Has anybody ever come across another
case where content has been provided (like this) for users with disabilities
but *not* for those in a "typical" browsing situation? The tables can be
turned, it seems. Unfortunately it can still be disorienting for blind users
to close a new window, especially if the focus history is somewhow
interrupted and they don't arrive back at the original window when the new
one is closed.

I saw Mr. Morita's suggestion for using the onClick() method within the
link, which seems to work great. I would remove the target="_blank" myself,
because I prefer that (as Reidy Brown pointed out) the link open in the same
window if JS isn't enabled. But, seems to be a good method, although I don't
know what behavior is explicity required when an onClick() event is captured
by a link that also has an HREF. IE 5 ignores the HREF and fires the
onClick() event, but there could be browsers that decide the HREF is more
important.

Another consideration that led me to abandon this technique in my situation
was that I wanted to have links to external sites in the popup windows, but
I couldn't decide what sort of behavior this should invoke: closing the
popup + opening link in old window, not closing + opening in old window,
opening in popup window, etc. So I just stuck with the user's original
window, and figured that people could Shift-click if they wanted to.

If you were going to use this in a controlled environment (read: intRAnet)
where users still might turn off JS, and where the content of your popup
windows is simple and involves no linking, like a glossary of terms, then I
think this could very well be a good solution. For the big wide Internet, I
would be more cautious. As with all design decisions, it depends on your
audience.

Cheers,
David

P.S. And, as Mr. Bailey pointed out, the code within the <script> tags
should also be enclosed in comment tags (<!-- // and // -->) or certain
browsers will render the code as text...

> On Tuesday, November 07, 2000 7:15 AM, Charles McCathieNevile wrote:
>
> Well,
>
> it provides a pop-up window, which goes against WCAG 1.0 checkpoint 10.1
> (Priority 2) that says not to do that. But it does work for non-javascript
> browsing, which is important.
>
> Cheers
>
> Charles McCN
>
> On Mon, 6 Nov 2000, David Holstius wrote:
>
>   Something that I've done in the past is to make a Javascript function
that
>   writes Javascript code into the document. I don't know how "official"
this
>   is, but it seems to work. Something like:
>
>   function WritePopupHelp( helpFile, linkText ) {
>       var s = '<a href="javascript:Help(\'' + helpFile + '\')">' +
linkText +
>   '</a>';
>       document.write(s);
>   }
>
>   Combine it with a Help() function that you define, and then code your
actual
>   HTML like:
>
>   <script type="text/javascript">WritePopupHelp('foobar.htm', 'Definition
of
>   foobar')</script>
>   <noscript><a href="foobar.htm">Definition of foobar</a></noscript>
>
>   That way, only users with JS enabled will get source that invokes JS.
>
>   It becomes a little redundant to hand-code all those script/noscript
pairs,
>   so if you have the luxury of server-side processing you can wrap the
>   generation of each script/noscript pair in a server-side function. (You
>   wouldn't want to put it in another Javascript because then folks w/out
JS
>   wouldn't get *anything*.)
>
>   I'd like to know what WAI-IG members think of this workaround.
>
>   David Holstius
>   holstius@msu.edu
>
>   > On Monday, November 06, 2000 2:19 PM, Bruce Bailey wrote:
>   >
>   > I site I am reviewing generates context-sensitive "pop-up" help using
>   > JavaScript.  I imagine they are doing this for the effect that:
>   > (1) The main window stays open;
>   > (2) The new pop-up window is smaller than full-screen and has none of
the
>   > normal browsing controls -- so it doesn't really look so much a web
page.
>   >
>   > The pop-up is invoked by code like:
>   > <A href="JavaScript:Help('foobar.htm')">definition of FooBar</A>
>   >
>   > Obviously, the HTML file is available if one can figure out how to
hunt it
>   > down (it's fairly well hidden).  Lynx just generates a message:
"Alert!:
>   > Unsupported URL scheme!" and nothing happens.
>   >
>   > Is there an alternative way to code this so that 4x browsers still get
the
>   > no-frills pop-up version, but Lynx (and other JavaScript-free) users
get
>   the
>   > regular URL for the help text?
>
>
> --
> Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134
136
> W3C Web Accessibility Initiative
http://www.w3.org/WAI
> Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
> September - November 2000:
> W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
France
>
>
>

Received on Tuesday, 7 November 2000 14:22:13 UTC