Elements or Lower

Thu, 09 Mar 2006

In lamenting our failure to achieve level-AA accessibility, I noted that we could make a quick accessibility improvement to the WBC site by slightly changing the way we link to popups on the site.

I believe there are times that launching a popup window from a link (never in the background) is actually useful on a site, such as offering contextual help without diverting the user away from the current page. We do this quite a lot for links to PDF files and RSS feeds.

In doing this, however, one has to be very careful that the links remain as accessible as possible. Two checkpoints from the WCAG are especially relevant here:

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.

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

We’ve always covered our bases with the first of these. The CMS has the ability to “masquerade” any page to make it behave as if it were a different page in the site hierarchy. When a popup link is created, the URL leads to a special popups page, and features the internal ID of the page you’re coming from as pathinfo. The popup ID is then provided in the querystring.

This prompts the popups resource to “masquerade” as the resource whose ID was provided, and the querystring not only pulls out the popup content from the relevant database table, but also triggers the CMS to make the page “deep” — that is, the page acts as though its content is the result of a form submission, and a link back to itself is appended to the breadcrumb trail. This is how something like The Woking Forum gets the breadcrumb trail right for individual messages even though the CMS considers the whole Forum to be a single resource in the site hierarchy.

The result of this is that, without Javascript, the popup link acts just like it brings up a descendent of the current page, containing further explanatory information. This satisfies checkpoint 6.3 above.

Previously, the CMS would also write an onclick event to the link in the HTML, which would call a Javascript function to open the link in a popup window instead. The URL for this would be slightly different, though. By omitting the pathinfo ID of the current page, the popup resource wouldn’t masquerade the content as a regular page, but would wrap it in a special popup template instead. Consequently, the results of selecting the link with Javascript enabled would be different from selecting it without Javascript, both in terms of window behaviour and page appearance.

This didn’t satisfy checkpoint 10.1, however, because at no point was the user informed that the link would act as a popup using Javascript. Although it’s subject to interpretation, the consensus on checkpoint 10.1 seems to be that it’s okay to open a new, or popup, window as long as the user is informed this is going to happen.

So, I thought I’d implement a variation on Gez Lemon’s script for opening external links in a new window.

This works by finding all links marked with rel="external" and modifying them using Javascript to open in a new window, and also to append a “(opens in a new window)” disclaimer to the link text. The beauty of this is that, without Javascript, neither the behaviour nor the link text is modified. You’re never misled.

In the end, my implementation was inspired by this, but wasn’t a modification of the code. Instead of attaching the onclick event to the link in the HTML, the CMS simply attaches a “popuplink” class. The site already loads the wonderful behaviour.js, so my script uses this to trigger a function when the page loads that pulls out all elements with the “popuplink” class to modify them. The actual code for this is taken straight from the equally wonderful Prototype, but the library itself isn’t loaded to save on download time, as it’s quite large.

The script adds the onclick behaviour to each link it finds (it seems that onclick does behave in a device-independent way, so I believe we’re safe with respect to checkpoint 6.4), and then appends an img icon to the link. The icon is set to have alt text of “(opens in popup window)”, so the icon acts as notification that the link is different from normal for both sighted users and users of assistive technologies. This, I think, should satisfy checkpoint 10.1 too.

You can see this in abundance on the site’s What’s New page.