- From: David Holstius <holstius@msu.edu>
- Date: Tue, 7 Nov 2000 14:19:41 -0500
- To: <w3c-wai-ig@w3.org>
- Cc: "Bailey, Bruce" <Bruce_Bailey@ed.gov>, "yuu morita" <yuu@os.rim.or.jp>, "Reidy Brown" <rbrown@blackboard.com>, "Charles McCathieNevile" <charles@w3.org>
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