Elements or Lower

Over the weekend, we launched our new registry notification cards on Buy Our Honeymoon. For customers in the UK or EU, we send out a set of 100 cards as part of the service. Previously, these had used our logo, URL and a standard message, but we’d wanted to offer customised cards pretty much from the beginning.

One of the key challenges in doing this was finding an easy way to generate the artwork for the cards without having to manually alter a template each time. In some ways, the obvious thing to do would be to generate a PDF — but that’s not easy at all. Have you seen XSL-FO?

Instead we decided to use a non-obvious choice: HTML. And it worked beautifully.

There’s a couple of things that it’s easy to forget about HTML:

• CSS includes a whole bunch of physical units, like mm and pt. As web designers, these are verboten because (a) they’re absolute units, and are consequently less-than-accessible; and (b) a 10mm square box in the stylesheet almost certainly won’t be 10mm square on screen. But — and this is the key point — it will be on paper.

• Changing the size of a graphic using HTML or CSS often looks like ass on screen, because browsers generally aren’t as adept at resizing images as, say, Photoshop. But, as this venerable A List Apart article shows, scaling down a hi-res image in the CSS just ups the DPI in print.

• Browsers normally won’t print background images. But they will print a foreground image that’s had text overlaid using absolute positioning.

Was the resulting file fit for use on the web? Was it accessible? No — but that wasn’t the plan. The plan was to load it into Safari and print it using a very high-quality laser printer onto some nice thick card. It’s HTML, but it’s not a web page.

Why Safari? Well, for one thing, it’s the browser I use on a daily basis — but, crucially, you can also set it to miss out the normal printed headers and footers (such as the page URL), so you’re left with the content and nothing else.

So, having set up a sample file, it just needed some experiments to get the page margins correct. And then a workaround for the discovery that Safari seemed to miscalculate some of our mm box sizes by 3mm. I have no idea if Safari 3 fixes this — but if it does, it’s just an adjustment to the stylesheet.

Very nearly ten years ago, when I started Article Seven, my intent was to focus on print design for students’ organisations, with web design as a secondary concern. The basis of this was my work as a sabbatical for Kent Union, plus my role as Publications Assistant for the NPC, but over time, I discovered three things:

1. The niche market “graphic design for students’ organisations” wasn’t really a market at all.

2. Print design is a frustrating business: you send off your artwork, wait, and when it comes back with a problem (because you’re too cheap for proofs), there’s nothing you can do about it.

3. I was getting much more skilled at web design than I’d ever be at print design. What’s more, my poor old Acorn couldn’t really cut it. As much as I loved Photodesk, ArtWorks and Impression, anything but mono work would always come back shockingly desaturated, at poor resolution, or with myriad unpredictable glitches (exacerbating point 2 above).

Consequently, before long, my print work trailed off to a logo here and there, and the occasional NPC newsletter.

When we launched our honeymoon gift list service last month, we began a careful marketing campaign, which included trying to make personal contact with a number of wedding blogs and magazines.

Shelley discovered a recently-launched magazine named Perfect Wedding, whose next issue was to be a honeymoon and gift list special. We contacted them, and were offered a full-page ad at an excellent price, but only if we could deliver the artwork within a few hours, as they were just about to go to press (I believe the page would otherwise have been used for a cross-promotion of one of the publisher’s other titles).

With no small degree of art direction from Shelley, the following ad was created in about two hours flat:

I can intuit InDesign much better than Photoshop, so I’m glad that the design was much more of a traditional DTP project than an image-manipulation extravaganza.

Having picked up a copy of the new issue yesterday, I’m delighted with the result. The colours are rich, vibrant and match the screen colours near-perfectly, and there aren’t any horrible gotchas. Perfect Wedding were also kind enough to locate our ad right next to their honeymoon article, so we’re situated brilliantly.

Print work will never be a significant part of Article Seven’s output again, but it’s good to know that whatever skills I once had haven’t completely evaporated, and a complete thrill to see both our company and artwork in a major newsstand magazine.

The site for the Greenwich Community Network is now live, in its resplendent minty glory.

This represents Article Seven’s first foray into work for local authorities other than Woking, and my only work for a while that hasn’t been in any way CMS-related. It’s also (I hope) one of my more rigorously-accessible efforts, despite being fixed-width.

It’s still only a single page, but I’ve now put a new redesign of article7.co.uk live. This serves as an entirely unwarranted distraction from real work, not unlike poor Timmy’s relentless torment.

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.

Press coverage on this year’s SOCITM “Better Connected” report observes that only three local authority sites achieve WCAG “level AA” conformance, despite the ODPM priority outcome for all sites to do so by 1 April. Woking isn’t one of the four.

This news got under my skin just a little, not because I think it’s unjustified, but because it reminds me vaguely of my old French teacher:

I have a word for nearly right, and it’s this: “wrong”.

The subtext I found myself reading into this was that accessibility is an all-or-nothing thing; that unless you can meet all checkpoints on all pages, your site is inaccessible.

In truth, every checkpoint you can meet is acting to decrease potential problems and frustration for at least some users. There are some things you can do to completely nix accessibility for certain groups (for example, requiring Javascript for any links to work), but few checkpoints are designed to specifically address these kinds of egregious issues.

Of course, the report itself probably acknowledges this, and it’s unlikely that more than a representative sample of pages from any site were assessed. But the difficulty we have, as an organisation who have tried to follow the WAI checkpoints closely, is knowing exactly what let us down in the eyes of the report.

The current guidelines aren’t always 100% unambiguous, and there are certain issues addressed by them that are the subject of some debate.

Although the Council have yet to receive the full report, I understand that the methodology for assessment against level A are listed in the appendix. This is great news, but (unless I’ve misread the situtation), the methodology for assessment against level AA isn’t included, and that’s precisely what would help us most.

My sentiments here are largely an echo of those expressed by Dan Champion, web manager for Clackmannshire Council. Dan notes that the lack of transparency in the assessment process used by companies such as SiteMorse devalues the results they provide.

Our page metadata doesn’t claim greater than level A comformance, since it’s probably better to undersell than oversell here, but accessibility is an ongoing priority both for the Council as publishers and me as programmer, and we’re confident that by-and-large, we really should be meeting pretty much everything from level AA and a fair number of checkpoints from level AAA as well.

Having said that, we certainly have work to do in improving the accessibility of our PDF provision, we need an accessibility statement, we need to consider provision for accesskeys, and I have a personal project to implement a zoom layout style-switcher in the next few months.

I also suspect that a key issue that let us down is the way that we’ve used popups for things like explaining PDF and RSS usage. My implementation here works by having a link to the content as the href and a call to a Javascript function that opens a popup onclick. The normal link, however, includes a reference to the current page, so that the CMS wraps the popup content as if the page were a descendent of the current page in the sitemap (that is, the breadcrumb trail contains appropriate navigation back). The onclick link lacks this reference, which prompts the CMS to disregard the normal page templates and use a “popup” template instead.

The issue here is that none of this addresses the requirement to inform the user when a link opens a new window. The content only opens a popup if you have Javascript enabled, and acts as a normal link using the same window otherwise, but that’s not quite what the checkpoint addresses.

I plan, therefore, to implement a variation on Gez Lemon’s script, which uses the DOM to add new window behaviour — and, crucially, notification — to links marked as being external.

It won’t help our score in Better Connected, of course, but it will help our ongoing accessibility efforts.

When we built Window on Woking, we knew that organisations who signed up to the site would want to be able to customise their pages as much as possible.

So, inspired by the themes system for Blogger, the CSS Zen Garden and, in particular, Zaadz and the Evanescent Design Crew, we decided to try to implement a themes system for Window on Woking.

Internally, and backed up by consultation with the project’s visual designer, Adam Pink, we came to the following conclusions:

1. Themes would be implemented as an extra CSS file, loaded in addition to the main site styles — a theme would override global rules selectively, changing as much or as little of the default design as the author wished.

2. Other than the extra <link> to load the theme stylesheet, the HTML of any given page would remain otherwise identical between themes.

3. The Window on Woking masthead, login panel, primary navigation and footer would all be “sacred” and must remain untouched by any theme.

Having developed the global stylesheet and a set of styles for the Diary of Events, we first asked Adam to design a theme for the Councillors’ pages. This acted as a proof-of-concept for the idea, from which Adam then went on to produce two more themes, which we named Steel and Mediterranean.

I’ve produced four themes myself (Autumn, Air, Meadow and Grass), and we’ve commissioned Mike Stenhouse for two more, one of which (the excellent Corkboard) has now gone live.

Organisations can change theme whenever they wish, but at the time of writing, here are some examples of the seven currently-available themes in use:

• Air
• Autumn
• Corkboard
• Grass
• Meadow
• Mediterranean
• Steel

We’d like to have a much more extensive library of themes available, however, and so we’re hoping people will get in touch with their ideas. We’re offering £200 for each theme that we commission, although we’re only asking for people to contact us at first if they have an idea.

We’ve put more information about this, including a downloadable theme resources pack, on the Window on Woking site.

Although the budget for each theme is modest, I’m hopeful that we might be able to get some really talented artists contributing to the site.

Last year, I picked a beef with Mike Davies and Matt May over their arguments concerning the counter-productivity of having a separate “Easy Access” version of a website. Matt was kind enough to post a response to this in the comments here, which of course was lost when I turned comments off from the site.

Thankfully, Matt crossposted his comments to his own site. As (typically) belated as this is, I’d like to observe how calm, rational and unargumentative Matt was about this. A lesser man might have called me out for being overly defensive and, frankly, jumped-up.

Whilst I still feel that the apartheid analogy is, as the Missus would say, “a bit extra”, in hindsight it’s pretty obvious that my argument here was really that:

1. Woking had, at that time, an “Easy Access” version.
2. I thought I was doing a good thing by implementing it.

Deep down, I knew that making the regular site accessible beyond WAI-A was really the right thing to do, but I was too enamoured with the fact that the “Easy Access” version of the site showcased how the CMS could re-contextualise the whole site at the drop of a hat.

We have other uses for that technology now (more on which another time), so I don’t feel it’s wasted now that we’ve fixed up the normal site and dropped the “Easy Access” version. And, honestly, it really is so much better this way.

Observe, if you will, item #40 in this list of links from about a year ago.

Now, on the one hand, I’m massively honoured that Joe Clark, renowned accessibility specialist and author of what has affectionately come be known in some circles as the Goatse book, has actually seen my blog, let alone seen fit to link to it and describe it as both a “radically unusual weblog format” and “nice to look at in Safari”.

On the other, I’m shamed that the same Joe Clark, renowned accessibility specialist, observed that it was guilty of “violating all sorts of WCAG requirements”.

I never actually realised that the old design here had serious accessibility problems — but as someone that likes to consider themselves both a web professional, and accessibility-considerate, it bothers me tremendously that it might have, and even more that I didn’t realise. Having said that, I know there were validation issues with the old design that I never bothered to address fully, and there are a couple of (WAI-AA and above) guidelines that catch me out every time, so hopefully the problems were related to those and nothing that I’m likely to unwittingly perpetuate as a matter of idiom.

I’ve checked out the new design with validity and accessibility in mind, and it seems to have a more-or-less clean bill of health. Guideline 10.5 bites me here even now, though, which is a pity.

…I say “site”; really I mean “page”.

In a fit of insomnia last night, I decided that I was waiting too long for myself when it came to the redesign of article7.co.uk. I was hesitant over duplicating the old site structure, but indecisive over what the new structure should be.

How much to focus on the CMS? Should the CMS have a name first? How elaborate to make the case studies? Should I keep the graphic design angle?

But I’ve been unhappy with the old site for some time now. So, I decided to take the homepage layout I’d put together and simply fashion a new single-paged site out of it, merely linking to a selection of sites from the portfolio.

I may develop it from here, such that most of what you now see becomes a link to more information. But at least this represents my current direction rather better than the old site — for one thing, as promised, it’s entirely CSS-driven. Unfortunately, it breaks rather if you bump up the text size (IE won’t let you, as I’ve defined the starting size in pixels) — this represents an accessibility problem, of course, which is a touch hypocritical. I’ll work on addressing that soon enough.

But for now, at any rate, real work is calling again.