Web Standards Group - WSG

Ten questions for Patrick Lauke


Patrick Lauke

Patrick currently works as web editor for the University of Salford, where he heads a small central web team which provides development, training and advice to departmental web authors across the institution. In 2003 he implemented one of the first web standards based XHTML/CSS driven UK university sites.

He has been engaged in the discourse on accessibility for the last 5 years, regularly contributing to a variety of web development and accessibility related mailing lists and forums, as well as taking an active role in the running of Accessify.com and moderating the Accessify forum. In his spare time, Patrick pursues his passion for photography and runs a small web/design consultancy.

I'm an idealist by nature, but a pragmatist by trade. I'd never class myself as an expert and I certainly don't have all the answers...I'm just an opinionated guy eager to find real world solutions "where the rubber meets the road".

[1] Russ: You seem to be a true renaissance man - photographer, film-maker, designer, developer and accessibility evangelist. Which of these areas is your main strength?

Patrick: I wish I could say that I'm equally versed in all of them, but to tell you the truth I'm more of a 'jack of all trades'. I love to dabble with anything that catches my interest and always strive to try something new to expand my knowledge and understanding (and, of course, trying to have as much fun as possible along the way).

My background is fairly varied and straddles both development and design: I did two years of Computer Sciences (at the Swiss Federal Institute of Technology in Zurich), but found it far too academic and uninspiring. After working as an assistant for a professional photographer for a few months, I upped sticks, moved to the UK, and switched to a Graphic Design course, followed by a Masters in Creative Technology.

If I had to choose one of the areas that I'm most comfortable working in, I'd have to settle for photography. I've been shooting since I was about 16 years old, and I have, in the last few years, also started collecting older cameras (I've nearly completed my collection of all of Canon's A and F series). Despite my other interests in digital technology, I still prefer to use real film - mostly black and white. There is a certain quality to the analogue medium (such as black and white film's response to light, and the very natural looking grain you get at 400 ASA and above) and the 'craft' involved in manual shooting and working around film's limitations that I'm passionate about.

[2] Russ: How long have you been developing using CSS and how did you get the bug?

Patrick: I have been involved in web design for the best part of eight years now. It's interesting to look back at how my development practices have changed in the course of that time.

My first sites were all hand coded in a simple text editor, pretty much to standards compliant HTML. I recently found some source files of one of these sites on an old backup CD, ran them through the W3C validator for a laugh, and was astonished to find that - apart from missing the DOCTYPE - they passed as HTML 4 without any errors.

However, by the time I was on my Graphic Design course, I started working with the first version of Dreamweaver and explored the possibilities of a small, but promising new technology by the name of FutureSplash (who would have thought that this would one day turn into the almost ubiquitous Flash?).

I clearly remember first hearing about CSS while reading the now legendary WebMonkey, probably around early 1999. Although it looked interesting, there was still a lack of extensive browser support for anything but the simplest stylings. Beyond some experimental cases, there was also a lack of good practice examples, and certainly no large commercial sites with CSS driven layouts. After a few experiments of my own, I practically forgot about CSS and carried on in the old tried and tested way.

Fast forward to 2001, when I started my current job as webmaster at the University of Salford. With the position I inherited a large site which was already well established, but more importantly I was faced with providing help and support to a variety of departmental web authors. This aspect of my job was what eventually drove me to read up on things like accessibility, usability and general markup / coding practices. I started to visit sites such as A List Apart and became a regular contributor to Sitepoint.com (even joining the ranks of moderators and later becoming an advisor), while wrangling the horrible, inflexible, triple nested table based layout that my predecessor had put together.

By this time browser support for CSS had improved considerably, and sites such as the newly relaunched Wired.com demonstrated that CSS driven layouts were finally a viable mainstream alternative.

Taking advantage of our University's corporate identity review, I embarked on my first major CSS driven layout project: as our site would have needed a complete redesign at the end of the review, I decided to finally ditch the unmaintainable old-school markup. I was fortunate in that I did not really have to sell the idea to our management, as my position allowed me enough freedom to take this decision myself (although I did run a series of presentations and discussion groups to explain the advantages of this 'new' way to our various stakeholders). You can find some more information about this project in the presentation notes from a session I ran at last year's Institutional Web Management Workshop, but in summary this large scale redesign project was really my first proper use of CSS (and, although I can't be 100% sure about the timings, it's fair to say that we were one of the first universities in the UK to successfully move to a table-less XHTML/CSS site)

[3] Russ: You have two designs that have been published at CSS Zen garden - Door to my Garden and Gothica. Did you learn anything new about CSS when you were developing them?

Patrick: Absolutely, yes. At the time, I was right in the middle of our University's site redesign, and literally learning CSS one rule at a time as I was going along. I actually never intended to enter any of my designs to the Garden; even though it was still in its infancy, it already featured such high quality entries that I felt my meagre attempts would be quite inadequate. As CSS was fast becoming the most popular topic in the web design area over at Sitepoint's forum (were I was a moderator at the time), we decided to run our own 'garden-like' competition. I was involved in the contest's organisation, and developed two example designs: the default Sitepoint style, and the slightly more elaborate 'Gothic'.

Imagine my surprise when, out of the blue, Dave Shea emailed me to ask if I'd like to rework 'Gothic' as an entry to the Zen Garden. It was this initial vote of confidence that pretty much took the 'fear' of the Garden from me and spurred me on to explore a variety of new techniques and styles, pushing my knowledge of CSS further than the constraints and boundaries of my large Salford redesign would have allowed.

Certainly working on 'door to my garden' (which seems to be my most successful entry, even managing an appearance in Dave and Molly's book 'The Zen of CSS Design' - see the sample chapter at creativepro.com) has provided me with a very strong grounding on the various issues involving the use of background images and cross browser alternatives, and probably represents my most 'finished' piece of work in terms of striking a good balance between visual design and clean, simple stylesheet usage.

For completeness' sake, it may also be worth mentioning that I have two more entries which unfortunately did not quite make it into the 'official' list: phonephreak in the 'conceptual designs' category, an admittedly unreadable design that mimics a double page spread magazine layout, and an advanced version of 'door to my garden' under 'special effects', which uses some :hover trickery in browsers that support it, yet degrades gracefully in those that don't.

[4] Russ: Would you change the way you constructed these two pages if you were going to do them now?

Patrick: The exciting thing I find with CSS is that, as with many aspects of 'semantic/structural markup', there is often no 'One True Way' of doing something. Just look at the growing number of image replacement techniques which have surfaced over the years. I still find that I'm learning something new with CSS every day, with every project I tackle. Sometimes, it takes a lucky accident, or a fresh way of looking at a problem, to discover a better, more robust or more elegant way to solve a specific problem. So, certainly, if I had to do these designs again today, I would probably do many things differently. I just hope that, almost three years down the line, people won't start dissecting my submitted CSS and start laughing at some of the naïve blunders that are hidden in there.

[5] Russ: What made you interested in web accessibility?

Patrick: As with CSS, my first real contact with accessibility came with my job at Salford. Although I was peripherally aware of the concept, and had previously heard mentions of the WCAG (Web Content Accessibility Guidelines), it was never something I thought I needed to concern myself with. However, researching some of the legal requirements involving educational websites in the UK, I inevitably came across SENDA (Special Educational Needs and Disabilities Act) and the wider DDA (Disabilities Discrimination Act). To summarise very broadly, the DDA demands, among other things, that the provision of goods and services should be (within reason) accessible to anybody. In its initial state, the DDA did only cover businesses and government bodies, making a special exception for educational establishments. SENDA, which effectively became part IV of the DDA, removed this special status, bringing education back under the general provisions of the main DDA.

Although the Act itself does not directly mention web sites, the 'Code of Practice - Rights of Access Goods, Facilities, Services and premises' does, and it is understood that therefore all government, education and business sites need to make 'reasonable adjustments' to ensure a basic level of accessibility.

So, having started my position as web editor at the University of Salford and realising the legal requirement imposed by SENDA/DDA, I began delving deeper into the subject of accessibility. What I found was that, even among 'seasoned' web managers in the UK education sector and beyond, there was a lot of ignorance and confusion - coupled with misinformed management concerned with 'Bobby validation' as the be all and end all.

This sorry state of affairs, combined with the fact that, deep down, I feel that accessibility is simply the ethically/morally right thing to do, led me to explore this subject further. I find it fascinating that even though in recent years more and more sites, books and even conferences have been devoted to accessibility, there are still many grey areas once you move beyond the basics, where even experts can furiously disagree. It's not all cut and dry, and in many instances one has to take a pragmatic approach, weighing up how things should be done (according to things like W3C specifications or even common sense) against how they work in practice (in light of flaky browser or assistive technology support, for instance).

[6] Russ: For developers who are trying to learn about and apply accessibility to their sites, what are some simple things they can address straight away?

Patrick: The single, most important thing developers can do is to start thinking about the issue of accessibility. Rather than the rote mastery of a series of markup techniques ('make sure each image has an ALT attribute') which must be followed with blind dogmatism, developers need to gain an understanding of the reasoning behind sets of recommendations such as the Web Content Accessibility Guidelines. Despite its good intentions, certain techniques outlined in WCAG 1.0 are either out of date or based purely on subjective criteria. An essential aspect of creating accessible sites is to know exactly which recommendations are relevant and which can, in certain circumstances, be ignored or broken (provided that there is a valid reason for doing so).

[7] Russ: If developers use full CSS and semantically correct code for their sites, have they moved a long way towards making their sites accessible?

Patrick: Separating content from presentation, using CSS rather than tables for layout, and correctly marking up a document's structure, identifying the purpose of each element, certainly constitute a first step on the road to an accessible site - a solid foundation. More recent document types like XHTML 1.0 Strict deprecate presentational attributes and elements that used to be present in HTML 4.01, as well as mandating things like ALT attributes for every image. However, XHTML/CSS is not a magic bullet, and it is still possible to create highly inaccessible sites while sticking to valid, standards-compliant code. Developers still need to understand the potential problems that users can face.

[8] Russ: You created a Quicktime SMIL file from Zeldman's WE04 introduction video. What is SMIL? Could you explain how the video was achieved?

Patrick: SMIL (Synchronised Multimedia Integration Language) is an official W3C (World Wide Web Consortium) specification which offers a simple framework for creating rich media presentations from separate elements. Although support for SMIL is still far from perfect, it is one of the useful formats for creating captioned video presentations like Zeldman's Web Essentials keynote speech.

A fairly detailed explanation of how the video was achieved can be found on the 'Skills for Access' site.

[9] Russ: Is there really a need to provide different formats for video and audio?

Patrick: Quite unequivocally, yes. A visually impaired user may not be able to see a video; a user with a hearing impairment may not be able to hear an audio track. If developers don't provide essential visual or aural information in alternative formats (even as a simple description or text transcript), some users will not be able to take advantage of the information you're putting on your site.

As is often the case, adding what would be considered 'accessibility' features can have benefits for all users, not just users with disabilities. For example, imagine that you're writing an article or research paper, and you want to include a quote from a conference's speech. If the speech is only available as an audio file (a podcast, to use the term 'du jour'), you'll have to listen to the audio and manually type up your quote. If the speech is also made available as a transcript, it simply becomes a matter of copying and pasting. And of course, search engines can't index the content of audio/video files.

[10] Russ: You're a member of the recently formed WaSP accessibility Task Force. Can you tell us a bit more about it?

Patrick: Since its inception in 1998, the Web Standards Project (WaSP) has been campaigning for the general adoption of web standards. Now, while great progress has been made in getting browser manufacturers, web designers and even authoring tool developers to understand and leverage the advantages of standards, there still remain crucial parts of the 'web equation' to be tackled.

Web standards offer many specific markup elements and attributes that can aid accessibility, as they unequivocally define relationships, provide alternative content and give richer meaning to what would normally just be unstructured text. Assistive technologies such as screen readers, however, still do not consistently take full advantage of the possibilities offered by standards-compliant markup. In part, this is due to AT developer's ignorance of, or disregard for, standards. Another factor certainly is the common 'chicken and egg' problem of web standards: as the majority of web sites are still constructed using fairly inaccessible tag soup, assistive technology has had to resort to heuristics and clever algorithms to guess the implied structure and relationship of web page content. The fact that each AT implements its own algorithms and interpretations has resulted in the current situation, where, rather than being able to rely on standards, we as developers have to test how each different screen reader behaves. As more and more sites are now moving towards the use of web standards, one of the main goals of the WaSP ATF is to work together with AT developers to ensure that their next generation of products will take advantage of standards-compliant markup in expose its structure and accessibility features in a consistent manner to the user.

Russ: Thanks for the interview, Patrick!
Patrick: Thank you for your patience. It only took me, what? 9 months to give birth to my replies?

Copyright © Web Standards Group 2012