Geek in the Park

Parental advisory: explicit content.

This is the transcript of the ad-libbed discussion Bruce Lawson and I did for Geek in the Park, Royal Leamington Spa, 27 August 2006.

The podcast of this discussion is available in a variety of formats.

Audience comments have, in most cases, been summarised, paraphrased or — when not directly relevant to the discussion — omitted.

Where the rubber meets the road: Web Accessibility and Pragmatism

Bruce Lawson: OK, thanks very much for coming. It's indeed an honour, particularly as I know so many people either from old or online and it's … it's fucking great to be able to come and talk to you.

What we're going to do is: Pat and I have been talking philosophically for quite a little while about what we think about standards and accessibility, either online or on the phone or when we meet up. When Trovster said "Do you want to come and harangue people?" we thought what we'd do is we'd open out the conversations we've been having and hope that you'll converse with us, because we're moving to a way of thinking but we haven't firmed it up and we really want to have more people's ideas.

In order to be fully accessible, orthodoxy says that your web pages should be fully liquid, percent-based or em-based. All the text should be resizable. In fact, everything should really be text. Images … images are OK but image replacement is considered to be something of a bit of a dirty secret or a dirty trick. You should, of course, use only a very limited palette, a palette that makes the web safe colors look actually quite extensive, in order to meet contrast requirements.

Of course, all of this is actually bollocks, because in the real world, you can't do that.

We've had conversations on forums, etc, in which people have said that "Well, if you can't do that, you should change the design." That's all very well if you're just running a one-person blog or something, but actually, if you're running a corporate website where teams of highly paid marketing people come up with corporate palettes and typefaces, you can't go in and say "I'd like to change the design because a blind person or a person with visual impairment might find this difficult to read." It just wouldn't happen. It just wouldn't fly.

And so what Pat and I have been discussing and coming up with ideas for is something that we're going to call (piggybacking off Jeremy Keith) "unobtrusive accessibility". The idea is that the compromises that you have to make should really be governed by the fact that you do the best you can within the business rules and within the parameters you work in. I think we've all found in our jobs, that sometimes you get accessibility and standards under the radar. You're not telling your boss that you're doing them; you're just getting them in anyway because you know they'll be good and maybe the marketing people and the boss won't really care. And if you're standing up in meetings and announcing that you propose to change the corporate logos and the typefaces etc, you just wouldn't be allowed to do it.

I'm rambling.

Patrick H. Lauke: That's all right.

Bruce: OK, cool. Please stop me and say "No, Bruce, you're wrong." or please give us an anecdote that confirms or gives us another angle on what we're saying because sometimes we think we may be just two blokes having a chat and talking out of our bottoms.

Patrick: And it's not a polished kind of Doug Bowman-style slick presentation that we're going to do tonight. As Bruce says, it's mainly a little bit of a discussion. It's something for us to take away hopefully as well, as we explore different themes, different ideas.

As Bruce mentioned, we don't have the answers either in many cases. We're all on the payroll of some company. We're trying to do the best we can, so that's the kind of format that we're hoping to at least entertain you for about an hour. And after that, the bar is open anyway so we can drown our sorrows with that.

Bruce: So the compromises that I guess most of us make, or I've been making this week, is … a site that I've been making is fixed width. Of course, orthodoxy is that you have a liquid page. I've been using a lot of image replacements and I know that the people who have CSS on but images off — that's "inaccessible". Personally, I think that's legit because I think that's a choice that somebody's made. If they've chosen to configure their browser that way, that's up to them.

I know that's a big disagreement in the accessibility world between universal design or universal access and accessibility for people with disabilities. But I agree with Joe Clark's definition that accessibility is about accommodating things that people can't easily change. Arguably, that's a compromise that I've made from my purist position.

For example, I very rarely use the legend elements in forms. I believe the spec actually says it's mandatory after a fieldset and the legend element has massive accessibility benefits because all the big screen readers will read out the content of the legend before every prompt in the form. But the trouble is that it's just really, really ugly and terribly difficult to style and a lot of the time forms on websites are so disastrously off-putting for the punter that the marketing people quite rightly say "You're not going to pollute this already quite terrifying form with this ugly unstyled element."

So that's a compromise that I've made and I wonder if anybody else has made any dreadful compromises that they will share with us. Pat, have you?

Patrick: I have.

Bruce: Go on then.

Patrick: Well as I say I was … should I grab the mic and move it down here or whatever? As you can see, it's very well rehearsed, this handing over.

Well, as Bruce mentioned, I'm known … notorious mainly for being a very, very idealistic kind of person when you're on our mailing list or whatever, forums etc You will hear me or read me banging on about "In an ideal world, this is how it should be", and going on about all the things that we know should be done right.

As Bruce mentioned, sites should resize. If you're resizing a text size, yes it would be great if the site adapted to whatever situation the user prefers. They want a certain color combination. They want a certain size. They're on a certain device; maybe they're on the go on a PDA. They want to access the same site. Yeah it would be great if it worked. From an idealist point of view I see that and I will be the first one to pull somebody up about it if they said anything different … in an ideal world.

Using images where you could really be using text, things like "Do your buttons need to be actual images? Could you not code them so that it's real actual text in the HTML, and use various techniques, you could use the latest CSS with a bit of JavaScript to make up for older browsers that can't do it." Yeah it would be great! Color contrast again, as Bruce mentions, it would be great if I could design my sites completely with color combinations that always pass if you run it through Gez Lemon's wonderful little tool. Always come up and say "Yeah. That's perfect. That gives you just enough contrast between your background and foreground."

Bruce: Can we edit out the words "Gez Lemon's wonderful little tool." It could be misconstrued …

Patrick: Yes, leave bollocks in, but Gez Lemon is a bleep word.

Bruce: His little tool.

Patrick: His little tool? OK. Gez Lemon's huge, massive tool.

Generally catering to all users, now we're all trying to do our best, and in an ideal world, yes I would create web sites that work for everybody in any kind of situation. But the reality is, the pragmatist in me, the realist, the one that actually needs to get a paycheck at the end of the month to pay the mortgage, realizes that this is not always possible.

There are many accessibility checkpoints and guidelines, which are great in principle and in the very contrived lab situation that sometimes I think the W3C work in when they devise their guidelines, it would be great.

We could do all that, but there are many situations where these accessibility guidelines, as good as they are, as right as they are, and you read them and you think "Yes, I see exactly what you mean and why this could be an issue if I don't do it." The reality is that they're sometimes at complete odds with things that .. other requirements, other business requirements that in the real world we have to face.

Bruce: For example, one of the things in WCAG says, I can't remember the exact wording but it's "Provide a mechanism to skip over repeated page areas" which are basically skip links, isn't it? Now skip links is a great idea and there's a huge accessibility benefit to skip links, and I've gone on record saying "Your skip links should be visible." And the reason I've said that is because I've watched my next door neighbour, who's got arthritis, try to use the mouse and just not being able to do it. But because she's not visually impaired, if it was like a one-pixel spacer GIF with alt of "skip to main content", she wouldn't know it exists.

But the trouble with skip links is, a lot of site owners, a lot of businesspeople won't let the first link on the page, which is generally going to be in the nice attractive brand logo, be plain text, skip to main content. And also, and this I know is Pat's big bugbear, it should be the user agents that deal with that. The user agent should be able to sort that out. We're all, to a greater or lesser extent, committed to web standards and the separation of presentation and content is our mantra, and so bunging in things actually that are not content, that actually just help get over deficiencies in the user agents arguably isn't part of our remit at all.

And this is where we're interested in your help (either now or by email afterwards), because I acknowledge that there is a big accessibility bonus in skip links, but the purist in me rebels about patching up the UA and the sheer ugliness of it.

As an aside I think one of the things that was deprecated in HTML 4 or 4.01 was the menu element, which was a kind of list, like an unordered list, but it was a menu and it was used for a menu: the site navigation. And if we were still using the menu element, it would be a piece of cake for the screen reader people to skip over: go to the next bit of content that wasn't in the menu element. There, you've got a skip links.

But for some reason, and I have no idea what the thinking was and I'd love to get Tim Berners-Lee over a few pints and ask him why they deprecated what to me seems highly useful and semantic element.

[audience comment]: Isn't there a navigation list item coming up?

Bruce: There is in XHTML 2; at the moment, it's in draft.

Patrick: So when it comes out in 2057 … [laughter] By the time the browsers adopt it, that's another ten years on to it.

[audience comment]: So what's stopping you doing it with XML?

Patrick: What's stopping us?

Bruce: Matthew, what's stopping us doing it with XML? [laughter]

Patrick: No user agent would support it unless we developed a standard, and even then it would take at least a few years before … even if we developed a grass roots standard. People talk about microformats, best practices, patterns, John Allsop's Web Patterns idea. It's all great if we all around the world could agree to some kind of baseline level of whenever we want a navigation, we always have a class …

[audience comment]: He said the word, he said baseline! I was waiting for somebody to bring baselines up. [groans]

Patrick: It's the newspeak. You have got to learn it.

Yes, so if we all agreed that if even though we know that HTML itself is a kind of generic language with a few caveats that we're going to cover. If we all agree that: yes we could do it 100 different ways to create the navigation. If we all said "But whatever we do as a navigation, we will give it a certain class" and we will all around the world agree that "Yes, whenever we give this particular class, we identify this as a navigation", then in a future where then the web browsers, the user agents, will understand that, yes we could have it right here, right now, so to speak.

With the technology of now, once we implement it we could say "look out for a class that is called 'navigation' or 'nav-element' or whatever we want to call it, and do it." But as I say in the here and now we can't because the browsers pretty much treat it as very generic mark-up, which in theory it's supposed to be.

So all the idea of microformats are great, they do great t-shirts and everything else. It's a good idea. Hello. [laughter] It's a good idea to have but it's all good and well that we as developers work towards this code and it is good to see groups like the WHATWG pushing it. It helps that a lot of people at WHATWG work for Opera and you can start imagining that Opera will start implementing a lot of these things. But the reality is that as much as we as developers feel really good about setting a new standard within the confines of HTML, we're working towards getting better semantics into HTML, yes you can then have extensions for Firefox or bookmarklets or various other clever things that extract this semantic information. But for the user agent itself, for instance for screen readers, it doesn't make any difference at all at this stage.

It's great that we're all congratulating ourselves that we're all using hCard and we're using the various vCard or whatever other microformats are out there. The microformat way of deciding by actually approving it, getting it peer-reviewed and everything else, is really good, but until we actually get screen reader manufacturers to acknowledge that development, where at this stage some assistive technology isn't even acknowledging basic web standards.

They're still ignoring it on the grounds that: "the majority of the web is still loads of tag-soup, so why should we work towards identifying proper semantically structured HTML when 90% of the stuff out there isn't? We'd rather invest time in getting heuristics out there in our products that try to understand what is effectively tag-soup, and we will ignore whatever you try to do based on the spec because nobody else does it, so we'd rather spend time doing that."

(I'm losing my thread here!) Yeah, so, we can do it. We as developers can do it. We can feel great about using microformats and things like that, and we could invent a microformat to define part of the layout of a page or the functional layout of a page. We could clearly define the role (and that's another key word for the XHTML 2 guys) of certain parts of the page now. We could sit here and actually draft something tonight and say: "right, as of tomorrow all of us here will say we will use a certain class. We'll call it 'Geek in the Park Navigation' for the navigation [of] Geek in the Park Content, and we will expect screen readers to look for that particular class." But it's not going to happen. Yes we can do it, but it won't make a difference at this point unfortunately, I think.

Bruce: It's also pertinent at the moment that Pat and I have been having phone conversations that our newest bugbear is indeed the deficiencies of HTML and the deficiencies of the proposed XHTML 2 spec. I've mentioned the fact that it's a shame that the menu element was deprecated. In HTML 3 there was a figure element that was dropped and never made it to 3.2. That would be brilliant because that was allowing you to associate a caption with an image and actually link them together. That never got into the spec because it was considered too difficult to implement at the time. That would be great to be in XHTML 2, but instead they've still go all the crap that computer scientists put in there in the early 90s. You've still got kbd, var, samp, code — and now, blockcode. What the hell is blockcode?

Patrick: They've got arguably presentational elements like sup and sub, which are presentational because even if you look at the examples they give, they show various things that you might use when you're marking up certain mathematical formulas or chemical formulas. Or in French if you do "Mademoiselle", you need the capital M and then "lle", but that needs to be superscripted so that they're kind of mixing this element, that in essence, says "you need to take the text, make it slightly bigger, and put it up or down." And they're trying to — I engaged them in a conversation recently on the actual HTML W3C mailing list, where they discuss the future of HTML. And I pulled them up about it, and I said "Why is this kind of stuff still in there, it is clearly presentational." And they tried to justify it by spurious "it is actually useful because there is no other way of doing this at the moment", but that's not an answer that really pleased me.

[audience comment]: The W3C had the audacity of giving everybody a "get out of jail free" card when they invented baselines.

Patrick: To a certain extent, baselines is a thorny subject, but baselines will be defined … we need Gez here.

Bruce: We do need Gez, because Gez knows everything about WCAG 2.

Patrick: Because baselines — yes, as a company, for instance, I could say what my baseline will be — it's technology based, not browser based. So I couldn't say "my baseline says my site will only work if you're using Internet Explorer 7 and a certain plug-in." That's not how it works, you need to be able to say "my site works if you're using HTML, CSS", and you could say "my baseline includes Flash." The interesting thing with that is that you will probably get some companies that will try to use the excuse of baselines to push for — well, everybody needs that, and my special Bruce-Patrick plug-in that will stream content that is purely proprietary to us. But that will be, if it ever comes finally to a court case about the DDA, a website being accessible or not accessible, I would reckon that the attack would be mainly on "did you choose a baseline that is just unrealistic for the real world". If I said "my site only supports my browser that I've created that supports my particular mark-up that I've invented", I could do that, as a baseline …

Bruce: But you still would lose a court case.

Patrick: Yeah, that would be contested. The focus of the court case would shift from "you're not passing a validation" — because you could get around that by saying "Well, there is no validator for this special Patrick-Bruce-ML" — but the attack would be "your baseline is unrealistic", therefore, you need to develop a site that uses baselines that are representative of the standard of what people are using currently. Which would, for my own part, for the University of Salford website … for those of you who don't know, I manage a large university website. We've talked a bit about baselines. The problem is, I'm the only one that's really in the know about accessibility. But I've talked with colleagues about baselines, and what is going to happen mainly, also with a lot of other university websites, is they are going to be very conservative, and say "our baseline is HTML", full stop. There's nothing more than that.

[audience comment]: The way I see it, we're in a boat. The developer's got one oar and the user's got the other. The developer's got social responsibility to move forward and become more educated, in order to meet the needs of the user, but — you know what? — the user has to row a little bit as well, otherwise you're gonna go round in circles … Everyone sees the onus as being on the developer all the time, and I want to see some of the onus on the user.

Bruce: I completely agree, and in the introduction to a really great quality new accessibility book, available in a bookshop near you. That's the one. I very firmly say, and the PAS 78 says, it is up to the user; if your user comes to you with Jaws 1 and IE 2, and says "I can't access your site" … tough shit, really. Tough shit, really.

Patrick: Is that what it says?

Bruce: (I am paraphrasing, I believe it's actually "tough titty") No, but I completely agree with you, the user has to come too. We touched a little bit on whether it's legitimate to expect us as developers to make up for deficiencies in the user agents, or the browsers. But equally, the users really need to know how to use their browsers. Now the browser manufacturers could make it simpler, and Pat's got a cunning plan for that to happen. And again, you can help us, because I'm quite torn … I think 'skip links' is a user agent problem. But other things that are user agent problems, I'll work to patch up in the site, I don't know exactly where I stand.

Patrick: It's a slippery slope. Once you start saying things like "We don't care because it's a user agent issue" … I've come across recently discussions where people have said "Why do I need to put alt attributes on my images with text when OCR technology is coming in leaps and bounds, and shouldn't it be a user agent issue to actually look at the images and analyze them, work out what's happening there." They were kind of sucked into the artificial intelligence thing a bit I think.

[audience comment]: I hate anybody who calls them "alt tags".

Bruce: "alt tags", I believe, actually in this splendid book. No, no, in the glossary, I think we say that …

Patrick: We're hoping that in WCAG 3, there will be a penalty of death for calling them that.

Bruce: It says "it is evil and wrong to refer to this as an alt tag, as there is no alt element in XHTML, and many hope that WCAG 3 will mandate the death penalty for calling them this".

Patrick: So we're a bit hardline, in certain respects, but, oh well …

Bruce: We're talking about user agents, patching up user agents and we're going to talk about why don't the UAs on first installation ask pertinent questions.

Patrick: As I said, we had a carefully constructed plan but it's great that we're already throwing in the wind. As we said, it's a conversation; that's the way we want to run it, really. We're not here to kind of expound on great truths that we've worked out hiding away in a monastery for two years, studying the markup and studying the specs and working it out. As I said, I might actually jump into, back into my flow and then get to that particular point when we get to it, really.

Let's see, where was I? Yes, so I was talking about … when I started off saying I am very idealistic, I can be very kind of hardline, as we're just proposing a kind of death penalty. No, I can be, I'm very passionate about accessibility, for some reason. And I can be very idealistic saying "In an ideal world, this is how it should be." But at the end of the day, as I said, we work in the real world … well, most of us do; some people that we know do work in a fantasy world.

But, as I said, a lot of times when you've got these ideas of "I want to do the right thing", and that's the main thing: we want to do the right thing in terms of accessibility, in terms of making our sites work for the majority of users in any situation.

But we come across, we're at complete opposites sometimes with things like the needs of branding as Bruce already touched upon. We might be bound by a corporate identity which mandates a certain kind of corporate palette, corporate typeface, a certain logo that God forbid you change it into anything else because we might lose our kind of complete brand recognition, or anything like that.

And also the marketing needs: "I really need this particular product or course or initiative", or whatever. "We really want to make a big splash so we need something that is really attention-grabbing." For visual users that often means things like things need to be really brightly colored, things flying into the screen, things — I'm not going to say blinking but you know — grabbing people's attentions. There are certainly kind of, for visual users, there are certain tricks, certain things, that sometimes you have to employ to actually achieve the kind of ideas that you have, the business goals that you have.

And also there's the other side. It would be great if we all had unlimited time, and unlimited budget. so … we're putting a video up. Right, we'll do an alternative version. We'll do a captioned version, we'll do one version where the captions are burnt into the video, we'll do an alternative version with SMIL and we'll do one for Windows and everything else. Maybe we use a bit of Flash as well and try to make sure that that's accessible. But again the reality is that if you aren't working … well, if you are working in a company with unlimited time and budget, I'd like to come in for an interview.

But in the reality, it's often the case, as we're already saying, we're often forced to do things stealthily and under the radar. We're doing accessibility because we care, not because we're told to care. But if you start coming along and say to your boss "Right, it's great that we're going to put the latest advertisement campaign up there. Yes, it's only going to take me five minutes to upload the video but could I have another three days to actually sit there and type up a transcript and then I need to devise a way of making the various kinds of alternative ways available. At the same time I need to make all these links to the alternative version available but I really don't want to impede", in terms of being under the radar, it doesn't have to be too obvious so that people from the marketing department call you up and say "What is that link doing under my beautifully designed video?" and everything else.

So there are these realities that unfortunately as much as we would like to just turn around and say "Oh no, it's not accessible I'm not doing it."

Some of us … I'm in the good situation where I've got a day job that pays; I can turn down offers of freelance jobs when I think this goes against what I believe in. I don't really want to do this website because for whatever reason I don't think this should be done. In the day job itself we haven't got the luxury of turning down jobs if we're being told to … you know, this is what you do, you've got one day to do this. It's not that easy to say "Well, I refuse to do it unless we're actually working on … have you got a transcript, have you got this, have you got that."

So I'm just going to quickly, as an example, talk a little bit about are design that I did recently. As I mentioned before, I work at the University of Salford, it's kind of a medium size university. I've been there since 2001, it's been a long time now.

We're sort of, we're famous in those circles for having one of the first university websites that switched completely to tableless, XHTML, CSS, accessibility type stuff — doing all the right things. We're trying to kind of obviously carry on with that because it's the right thing to do from a maintenance point of view and everything else. And again … book pimp! I've got a whole article in the book here talking a little bit about this redesign and the various challenges of it.

Thank you, lovely assistant Bruce. So, as I say, I've got a certain commitment. I want to make sure that at the least my name is out there. If people now go on to the new Salford website and it's a bag of shit, I need to make sure it's actually working all right, it's still accessible. So I've got this commitment to "I want to make something that's accessible.." But with this latest redesign which we carried out over the course of the last six months, we had a new branding that came in, new visual identity elements and everything else and we needed to make a big splash about it.

This was a clear example of what we're talking about, where, from my point of view, I really wanted to create a site that is perfectly accessible — caters to all the audiences, does all the right things, color contrast, etc But the reality was that, because of the time schedule, and because of the fact that mainly, it's a team of one, which is moi, that's doing all this web stuff, it was just not possible to kind of go all the way with accessibility. So there were a few pragmatic, and that's kind of my favorite word, pragmatic decisions, that had to be made. You have to weigh up what's right, what's morally right to do, with time, resources, capabilities of other people involved in the project, etc. So I'm just going to touch upon a few of the accessibility sins, and I'll openly talk about them, a few of the accessibility sins that I have committed in the latest redesign of the website.

Unfortunately, we haven't got a projection here, but we'll send an email out later on, and if you have a look at the site, you'll see what I mean. It's not horrible — I don't want to create this image in people's minds that it's completely inaccessible, but there are certain things that I personally know that could have been done better in a certain situation, but just because of the reality of the how it happened, didn't, really.

So the reality is that I myself, my position as Web Editor, sits in Marketing & Communications. So I get the full brunt, the whole story about the branding, and the impact on the target audience, that we're kind of the masters of the corporate identity, we're the ones that actually go out to other people and say "that's not a corporate color, you can't use that" or "the logo needs to be always in that position on that page" "if you print it, it needs to be there", etc. So obviously I'm in probably the worst position to disagree with any of the mandates that come from up top, because I'm right at the source, really.

And as I said, I'm a team of one, mainly, and I'm doing the majority of coding and also the marketing side for a lot of things on the website. And with the recent redesign, as I said, there were a few changes in terms of our visual identity that needed to be carried out onto the website.

So some of the accessibility nightmares that I had — and before I started the redesign I actually consulted with a few of my accessibility buddies on various mailing lists and stuff. Basically along the lines of "don't excommunicate me, don't throw me out of your tree house club, but I'm fully aware that what I'm about to do is not fully in line with the hardline idealist kind of way of doing things. But it's the reality of the job, and I will do my best to kind of work as much as I can under the radar to bring things back in, in terms of accessibility, but that there are certain real-world requirements that demand that I do these particular things." So they've all been very nice, they didn't kick me out … yet.

Bruce: That's what we're going to do tonight.

Patrick: Make it official, make it nice.

Bruce: We're gonna debag you and roll you in tar and feathers.

Patrick: That's very nice. Cheers for that.

So the main ones that stand out, I had a thought — obviously well prepared, on the train coming down here — kind of a top four list of things that I know I've done; there's probably a few more here and there.

Top four list of things that I've done in the recent redesign that are suboptimal — that's another one of my favorite words, suboptimal — but from a pragmatic point of view, had to be done.

Yes, as Bruce mentioned himself, I've also used fixed-width, our design is fixed-width, in pixels.

And Karen's had enough, and that's it? Bye. Yes, it's a riveting subject.

So yes, fixed-width, 790-odd pixels, or a little bit less. Whatever the BBC is using. Horrid.

Also the site makes a lot of use of basically images, images for buttons, and the images are mainly text with a nice little border around. It's got kind of a knocked-out, little 45-degree corner, to make it very, kind of, fashionable, if we're talking about two, three years ago. But you know, corporate world is a bit slow when it comes to cool stuff.

Also, big image headers on the pages to say what the page is about, basically your title for the page, effectively. That uses a nice, big image, and it's actually an image, it's an image in the markup. No image replacement going on or anything like that. So, oh, disaster. Obviously, can't be resized, and what if I change colors, the color in the image won't change, and everything else. So, not ideal, but I implemented it.

And yeah, talking of colors, my hands were bound in terms of "this is the corporate palette, this is what you can use. And, for this campaign, we want to mainly use these colors anyway", so an even more limited kind of scope in terms of what I can do with this particular redesign.

And then the piece de resistance is: because the branding is a completely new …we've got a new advertising agency in, they're all zany and creative young people, and you really want to make a big splash about this new branding that we've got. And it's all mainly based on this — I don't particularly like it, but it's this particular montage kind of style, collage kind of thing. A lot of people refer to it as our kind of Sgt. Pepper type cover images. And that's pretty much what it is, it's a lot of images kind of superimposed, juxtaposed, and every image has got a certain kind of correlation with zany courses we do, or achievements that the university has had, and "did you know that we're the first university to do … blah." So it's all got some kind of purpose, but it's all kind of mashed up together. And that needed to be …

Bruce: … all links …

Patrick: Yeah, they're all links, I'll get to that in a minute, yeah. It's an imagemap, even. Oh, shock, horror, proper one.

Yeah, we needed to make a big splash about that. So center stage on the home page needs to have the new branding image, and a nice little explanation that pulls it all together for people, so that people can explore … The tag line is "Limitless Possibilities." So, great. So you have to explore it with a mouse, the various things, what happens there, and the description comes up. But I'll get to that in a minute, really.

So just looking a bit, these are the top four kind of things that I know people, the accessibilistas, in the nasty sense of the word, will look at that and shake their head and say "He just didn't get it, did he? He's very idealistic on his emails, but he just didn't get it." But, as I said, there are pragmatic reasons why that had to be implemented.

In terms of fixed width, that is one that is kind of closely related to the next one, which is the use of images. In terms of our design, on most sites it's a three-column kind of design, and the rightmost column — as I said it would be nice if we had it visually, but … open your minds … imagine … I'm going to do it in the medium of dance now, I'm going to interpret the website. The right-hand column is these kind of buttons that we've created which are a fixed size image on the right-hand side, mostly with text, so yes they could have been implemented in a different way. But we'll get to that in a minute.

So that's a fixed kind of column. The rest of the design could potentially kind of expand and contract with the size, but you know, we started, we went down — when I say "we" it's mostly the royal "we" because it's mainly a team of me doing it — we tried variations on the theme of making it elastic, it's the kind of special thing where you say "I want it elastic, but not quite because I've got something that is not elastic." That's when the problem starts. If I went completely percent or completely em, everything was in the same kind of style, it would be a piece of cake to do it. The problem arose because of this use of fixed sized images, and certain kinds of browsers not being too happy with things.

Now we've honestly tried six or seven things — it's my apology to the world "We've honestly tried!" Six or seven variations of basically doing two things at the same time. I want it fluid, but not quite, because I want it only fluid up until it gets to a certain size. So max-width, min-width, all of those things were kind of thrown into the pot, in a variation of themes, always kind of ending up with situations where it works in 90% of the cases, but if they have that particular combination of text size set or if they don't refresh the page or whatever, things start falling apart in a rather bad way, in a very visible "Oh, there's something wrong with this page" kind of way: things overlapping, links not working anymore, things falling underneath the content.

So we've tried a variation of things, and in the end, the easiest one, the most consistent one, ended up being "let's stick a fixed width in." As I say, I did kind of ponder that for all of two, three days, sitting there thinking "there must be a different way", and I really started to get into very exotic uses of CSS, where you start saying "OK, I can make everything flexible and fluid and everything else … what if I add a fictitious border that's a certain pixel width to the right-hand side, and then add a negative margin to counteract it", and everything else. It always kind of worked in most cases but there were always situations that where — not completely edge cases, there were reasonable cases like IE with a default text size set to fairly small — things started falling apart. Really the CSS in the last attempts started becoming really, really exotic in terms of you couldn't really understand anymore what was going on. Until, as I said, the pragmatic decision was "I can't spend any more than the next two or three days trying to work something out — we will have to go for fixed." And that's really what we implemented.

Also, because we're using fixed width headers, the conundrum would have been "Yes, if I make it all nice and fluid, minus the right-hand bar, if I managed to even solve that problem, the next problem would have arisen which would be: if I've got this big, large image that needs to span the whole top of the content, how do I implement that?"

Now, of course, we are all sort of CSS aces, we're at the cutting edge of things, and we know the latest bit of JavaScript to counteract that and do certain things in certain browsers that don't do it, etc. That's all well and good. And I actually had devised a way that is reasonably simple, if you start thinking about it. Like, OK, I'll do something like div and there's no overflow and I'll have an oversized kind of image sitting in the background. We'll set it as a background image, great. It depends on how much space there is, it will always stretch to 100% unless you go completely over your oversized image. Great stuff: we know how to do that.

The problem with that is that unfortunately, even though I'm a team of one centrally, what happens once you go down outside of our core site and into the school websites, into the faculty websites, research institutes, etc, you end up finding a vast array of web authors with skill levels ranging from "you're not doing anything on Friday, you know how to use Word, here's a copy of Dreamweaver, you're doing our site" to people that, yes, are complete tech-heads, and they actually argue with me that if you use this CSS it would work better. You know, great stuff.

But you have a huge range of people. And I couldn't, for the lower end of that particular spectrum, I couldn't say "Yes, all your pages need this header, and to do that you know what you've got to do? You go into Photoshop … oh, I don't have that … oh well, Paintshop or whatever, Paint, and create these really oversized images. And the way it works is that your CSS will need to overflow it here and cut it off there … It s just not feasible. It's just not realistic to assume that people will have the same common knowledge. People that will maintain, in the end will maintain these pages, will not have the same kind of technical ability that I have. It sounds really big-headed, we'll probably need to open both doors later when I get out of the pub to get my head through, but it's the reality.

We can know all the latest CSS tricks and wizardry of JavaScript to make even Internet Explorer 5 compliant with the latest standards. That's great stuff, but if the people that maintain these pages, and you don't have a content management system that takes care of all of that, and only locks them into … you can only text edit here and there. If you've got people that actually need to use something like Dreamweaver to do it, the chances are extremely high that they're going to either mess it up completely or just not bother. They will not bother. They will take an image because they will see the site on their screen and think "Oh well, OK. I just need to take an image and stick it in there …"

Bruce Lawson: Well, the worst thing, of course, is that they're so worried about actually how to do it that they just don't update their bit of the site. Then they've got dead websites.

Patrick: Yeah. They'll say that "every time I try to do something, the evil web editor comes down to my office and says you're not allowed to do that. He mumbled something about WCAG and things like that …"

Bruce: I worked on a site … I fell into the trap that Pat's talking about, using all the whizziest CSS, and none of the content authors could work out how to publish, so they're all sticking PDFs up.

Patrick: Yeah, because they don't have the time, and a lot of them … I understand them. The problem with Salford, anyway, is larger. Is this podcast around the world? Yes, excellent. The problem with my employer, you see … take my employer … take him please. No, it's basically, we've been crying out for a CMS type solution, but we haven't got one for a variety of political and financial reasons, whatever. So, as I said, the situation is that people are still using Dreamweaver to do things. Yes, if we had a CMS that takes care of all this stuff, yes, that would be great. It would be great to have a CMS that takes care of WCAG compliance, whatever that might mean to people … takes care of the majority of the page and they really only go in and change their text and everything else. But the reality is now, that that's not happening at our place. So, a lot of these kind of pragmatic decisions that are to make, were made mainly in the light of "I know how to do it, but I know that if I hand it over, they'll mess it up anyway." So, I'd rather find-not optimal, but slightly less evil than the alternative kind of way of doing things and you have to weigh these things up. As I said, you might get the person who's only got one hour a week to do things, so you have to take that into consideration, unfortunately. Again, that's one of those real-world kind of things that push you towards pragmatic solutions really.

Let's see, I've covered fixed width images. Color contrasts … as I said, there is not much more I can say really on that one.

That's all right. That's very rude. You know, we'll wait for him now. What's his name? [laughter]

Color contrast … as I said, there's not much I could have done in terms of "No, I will now invent a new corporate color and we'll only use this." In fairness, I have been more and more involved now with the Corporate Identity review panels and everything else and making suggestions along the lines of "Even though we've got all the nice, flashy, funky kind of neon, bright colors, we really need a few more muted ones to complement them so that we can also use them for things like link text and everything else on a white background."

Bruce: Or at least an alternate style sheet for those people for whom the contrast is not good enough.

Patrick: Yes, exactly.

Bruce: So they at least can use some style sheet widgets on an accessibility page, rather than nork about using … trying to work out how to get user style sheets into the browser, which is utterly impossible for anybody.

Patrick: Exactly.

Bruce: It's not impossible but it's just too many contortions to go through.

Patrick: Yes, a propeller head kind of proposition.

Bruce: I'm a great fan of alternate style sheets, however …

Patrick: Nonsense!

Bruce: … their implementation in the browsers leaves something to be desired. Again, you could say "Not my problem. It's a user agent problem." Sometimes I agree that it's not my problem, it's a UA problem, but I tend actually to think that alternate style sheets are my problem because I'm using them, actually, to get away from another problem, which is insufficient color contrast. Sorry, mate.

Patrick: No, that's all right. I'm gathering my thoughts because that touches on kind of my hobby horse, my rants topic to get me going. Grrrrrr. It's basically the proliferation of … as we touched on before, that we're trying, as web content developers, we are often forced to counteract or make up for bad functionality or missing functionality in user agents. Things like style sheet switchers. All the time you get people coming on forums and stuff. "How can I do the style sheet switching?"

Here's the A List Apart kind of thing where they do it in JavaScript. Here's the other one that does it in PHP and everything else. Save it in a cookie so they can come back later and they use the same style sheet. It's great. Along with things like "I also want to have a text resizer. I've got text plus and minus buttons. That's really good. We need that on our site." Those are all the things, on an idealist point of view, yes, I would say that is a user agent issue. If the user agent is not implementing that in a sensible way, that is not our problem. We shouldn't get any shit as web content developers if browser developers are effectively lazy.

You hear a lot about "Have they read WCAG ? Let's tell them that they're not complying to WCAG." I hardly ever hear anybody ever mention things like "Should we go and tell Microsoft that their browser isn't compliant to UAAG", which is the User Agent Accessibility Guidelines. Also, maybe tellingly enough, WCAG and ATAG are … you know they are working on version 2, UAAG is still in version 1. I don't know if that's telling of the priority that even the W3C sees for that but, as I said … go on, point it out.

Bruce: Pat and I have, because we're sad bastards with no life, we've been compiling a list of places where we think the browser manufacturers or the user agent manufacturers could help us all out by making their software better. And so Pat and I have been getting a list together, which we hope to publish reasonably soon, either on if we can get the full agreement of the rather fractious Accessibility Task Force. (If we can't get their agreements, we'll put it on our sites.) But it's effectively a list for all the browser manufacturers of how they could comply with the spirit of the User Agent Accessibility Guidelines, rather than just …

Patrick: Rather than just pay lip service to certain things by burying it deep into the preferences or anything else, but put things right up front.

Bruce: What are the things? I can't remember all the things, because … what was it?

Patrick: One of the UAAG things says you should implement specifications when they can be useful to accessibility, which is almost like a wild card kind of statement. But there are things that have been in the HTML specs since forever, since dinosaurs roamed the earth, things like link in the header, where you can link to "previous" and "next"; you can also define certain, kind of, other parts of your site: link to home, define the relationship that your current page has with other pages in the site, which is one of the kind of things I remember from a really alcohol-driven kind of night with Andy Budd when he came up to Manchester about a year ago — it was just before the first dConstruct, so yeah must have been about a year ago — where we started talking about HTML as a language is great to mark-up content, but the problem is: to actually make a website, you have to start inside the bit that is for content, which would be body, you have to start putting in all the framework of your site, you need to start having a section for your navigation, section for your header and everything else.

Wouldn't it be great if we could ditch all that, and basically say that navigation or the entire kind of "how is this page related to other pages within the site; what other pages are there within the site; what functionality is there" … if all that could actually be externalized completely and if your HTML was only the current document and your actual navigation was either a separate file altogether, or a separate element in your page, so you could have, instead of body have content then the other one would be relationship of this page to other pages or sitemap or something like that, an RDF reference to the sitemap — something along those lines.

As I say, it's very vague. But what we're left with when we do complex sites is that we really spend the majority of the time putting the scaffolding in place and then having to inject the content in there. And again, the problem that we touched on before was: yes, we do all the scaffolding, but because there's no standard for it, and there's no elements that are specific to that particular scaffolding stuff, then we start either inventing microformats that nobody supports or we do just what we can. There's no real standard.

[audience comment]: … we always talk about code and HTML. But if a website is not usable it doesn't matter how accessible it is. If you can't find the website, if you can't locate it … just because you build it, doesn't mean people will come. I want to know what you did at Salford to make sure it's usable as opposed to accessible — or did you attack it as a two-pronged thing, or do you do one thing and then the other?

Patrick: The whole usable versus accessible thing — or are they the same …are they two sides of the same coin? Oh did I use a buzzword there?

Bruce: Nah, it's just a philosophical argument too far, that one.

Patrick: We're not going to talk much about that but just my view on that is — I mean, the main problem that we're having when we start talking about accessibility is that because of all these shortcomings and because of the way we're all bumbling to actually find a good solution for things, it shifts the focus. If this was all — if we had a language that takes care of all of the problems in terms of "How do we mark up the navigation so screen readers could use it", if there was an actual element for it, that discussion would shift now — it would shift away from the technicalities of "How do I do it", but more in terms of what, in terms of the content and then starting to build more on that in terms of "How to make it actually usable."

The problem we face most of the time is that it is seen by a lot of people as a separate thing, and once we start talking about all the issues, the accessibility technical implementation is the one that usually takes up a lot of the time because there are so many gray areas. Hopefully we'll be able to shift that conversation more towards the usable, but usability itself is part of accessibility to a certain extent; they kind of go hand in hand, they overlap — overlapping Venn diagram circle type things.

[audience comment]: We talked about visual impairments. Who is the biggest blind user on the web?

Bruce: Mister Google!

Patrick: (your mother) … have you seen her? [laughter] Ah, anyway …

[audience comment]: To sell accessibility, forget about visual impairment. Just say "If it's not accessible, Google can't see it."

Bruce: Have you heard the stats that … the guy from Legal & General, the firm … the launch of PAS 78, they gave us some stats. Have you heard the stats they gave?

Patrick: They're in the book! [laughter] Quelle surprise!

Bruce: Legal & General, with Mike Davies, who you might know as Isofarro, on accessifyforum, they made their site accessible because they were worried about the legal risk.

And they found as side effects: 30% increase in natural search engine traffic, a significant improvement in Google rankings for all their target keywords, a 75% reduction in time for pages to load, accessible to mobile devices, their time to manage content reduced from an average of five days to half a day per job, they saved £200,000 a year on site maintenance, they got a 95% increase in visitors getting a life insurance quote (which was the purpose of that site), a 90% increase in sales online, and 100% return on investment in 12 months. And that was the side effects of making the site accessible.

[audience comment]

Patrick: Would Google penalize you, as we were talking about search engines?

[audience comment]: He talked about mobile users …

Patrick: That's an interesting one, because that touches on what I was saying before about, the thing about … the thing? The thing that I can't remember? The thing, the thing! Yeah, user agent responsibility, where does that start, where does that end, how can we cater for sites that do the right thing for all user agents or all users?

There are things where you could specify style sheets specifically for mobile users, for handheld users. It's a shame that the majority of mobile browsers ignore that, still based on the assumption that "Well the majority of the web doesn't follow that, so why should we follow it."

It's the usual chicken and egg problem. Until a lot of content out there uses the handheld media specification, we won't waste time implementing it in our user agent. And vice versa, why should we as paid developers create really sophisticated handheld media style sheets if the device doesn't support them? We're both waiting on both sides.


[audience comment]: I'm not a believer in anything Microsoft does, but their mobile browser now does have the option to put everything in … resizes everything.

Patrick: That's a user agent functionality. And to a certain extent … sorry.

[audience comment]: Fixed width is a good way to go for a lot of reasons that you mentioned earlier.

Patrick: It was their choice, they didn't implement the handheld, but they implemented functionality that would then override any things that wouldn't work in that particular medium.

In an ideal world it would go hand in hand: if you don't find a handheld style sheet, do it yourself, or offer the user the option of resizing it or linearizing it. If you do find a handheld media style sheet, for heaven's sake use that, because obviously it shows that the developer actually cared.

Whether they then got it right or wrong, that's then academic. Whether they set both the screen, and the handheld, and print, and whatever all to point at the same style sheet that says this site is only 800 pixels wide, that's then squarely a problem on the developer's side.

But as I said, it's kind of a lopsided ballet, we're all trying … we should all be working together, browser developers should say "Right, great, I'll honor your handheld style sheet" and developers should say "Great, because you do that, I can now start using it."

[audience comment]: Because developers are offering all these extras like text resizing and alternate style sheet switching, that's a discouragement to user agent manufacturers to bother …

Patrick: That is my point! We've been carrying the fallacies, the shortcomings, of user agents. Because at the end of the day we're pragmatic, which ties it back into my thing, and we know that I can't sit there and say "Not my problem, it should be a user agent " when the manager says to me "Why is your site not working for our vice-chancellor who's trying to look at it on his PDA?"

I can't go into a tirade about Microsoft, and make sure I spell it with a dollar sign in my email back "Micro$oft … browser wars … blah blah blah." It's "Well great, fix it, or you're out of a job." So in a pragmatic way we had to do it, but yes in an idealist way, we carry on doing that, and the browser developers think "Oh well, it's not our problem. Not invented here."

And users, who we always assume — and for the majority of times it can actually be true — we always assume the users to be extremely dense, in terms of "Oh, users don't know that they can resize their text." To a certain extent, we're not prompting them to learn it because we're then compensating for that by having big buttons that say "text plus, "text minus."

It actually reflects badly on sites that do the right thing but don't implement those widgets. Because then they'll say "Look at that website, that's really shoddy. It doesn't offer me the possibility to resize the text", where really what they should be doing is … Well actually, no, it shouldn't be the sites that educates the users, that's another one of my bugbears, because a lot of the current thinking is "OK, great. Don't offer the text resizers."

I'm sorry if I going to ramble on a bit left, right, and center but it's a huge subject.

Currently, in your accessibility statement, wouldn't it be great if you told people "Oh, did you know that you can resize your text. Here's a little handy guide. If you're using Internet Explorer, do this; if you're using Firefox, do that. Here's a link to the BBC My Web My Way website. It's great. It tells you even more about how to do things."

Is it the responsibility of every single website out there to teach users how to use their site? I start thinking along the lines of, I don't know, if I was a petrol station selling gas, every time I sell gas, should I hand out a little pamphlet saying "This is how you drive your car. This is the steering wheel, this is the gas … "

We were talking about user agents, referencing the PAS 78, where they say "We're all doing this according to WCAG to the best of our intent". The browsers need to join us halfway and actually implement UAAG and implement web standards. The users, to a certain extent, need to learn as well, how they can actually use their particular product to access the web.

If the product isn't obvious enough — and that's my main bugbear — if it's not obvious that I can resize text in Internet Explorer, that's because they've hidden it deep down in the bowels of the Preferences. Yes, there is a toolbar button to do text resizing but it's not there by default. But if you went into the "personalized My Toolbars", etc, I can make it appear. Why not make it appear right away first time you run it? Have it there by default.

Right there … I wrote a little crappy Firefox extension and I still get one or two emails a month on that one from people saying "Oh, this is great. Now I can resize text." It's basically just the plus, minus and normalize. I'm basically just calling the functions that are built into the browser and in the menu, but I've made it visible. You install the plug in, you've got three big buttons right in the toolbar. Great. As I said, from the emails I get, there are loads of people that installed that and then thought that I've done this good job of enabling this magnificent functionality. It's built in there, mate. It's like: control, scroll wheel, whatever. But users don't get it.

Why not have it there on first install? Either it shows it by default "Here's the resize thing right there, in front of your eyes." If you're a more experienced user, you're more likely to say "I don't need that … customize toolbar … remove it." rather than expect people to say "Well, I need that. I'll go and study the preferences and make it visible."

Or things like a wizard. Oh, the wizard. Gandalf. Have it when you first run it. Firefox already says, the last time I installed it, rather than upgrade it "Do you want to transfer your favorites from IE?" What about if the next screen says "Do you think you require the facility to resize text?" or whatever the wording, I'm not going to go into wording. Something like "Do you need text resizing — Yes/No?" "Do you need a particular color combination, otherwise, you can't use the web?" "Do you want to use … if the developer has shown accessible alternative style sheets — and then we can discuss how we can say that this is the accessible alternative or the linearized alternative — do you want that to be loaded by default rather than the unmarked one?" All of that stuff.

The user agents, as we mentioned before, pay lip service to UAAG, they follow to the letter often things like, if it says "there needs to be a functionality that allows users to change the text", that doesn't say in UAAG how prominent it needs to be. If they bury it under five levels of preferences, to somebody that questions it, they can say "Oh, we've done it, it's there, it doesn't say where it needs to be." If they followed the spirit of it, the idea …

Just a second. I'm on a rant. I'll be there in a second. Neon signs …

If they actually follow the spirit which didn't say just follow this as a legal requirement … all of that stuff only says "This will make it easier for your customers, your people that downloaded this browser or installed this browser, they will find it easier to use web content if you implement this", so why only implement it … well, only follow the letter? Implement the spirit of it!


Bruce: Here you go.

[audience comment]: … when it comes down to developers, we've actually got a lot of power in terms of what we can actually do to influence … I use the web developer toolbar a lot, why isn't there a text resize toolbar … there's a lot of stuff that can be addressed, with JavaScript …

[BREAK IN AUDIO] It would be nice to be able to show people this is what we're talking about, this is what we'd like to see from user agents, it can be done already.

Patrick: What I always see … that just reminded me of another rant, but its only a mini rant, don't worry. One of the things I see a lot is very talented people like … was it Steve Falkner or Falcon? Faulkner.

Bruce: Faulkner. From NILS.

Patrick: He's moving now to London to work for The Paciello Group. He's done the IE Accessibility Toolbar and that's great. Firefox Webdev Toolbar, you can't get away from it. It's all great but all I seem to see are these toolbars and plug ins and various other things. that are targeting the developers: this is what you need to actually check you're doing the right thing with your page.

What I'd really like to see is that talent also being put to good use, the same kind of good use, to implement these widgets and things in the browser, that are for users.

Like my little simplistic text resize thing, that is meant specifically for users, and I'd love to see somebody actually take up the mantle, forget about … "list me all the meta elements", the various kind of "disable this" "disable that", when it's something that's really developer, geeky kind of thing.

Think about the top five or six things that from a user perspective would be useful. Well 'disable style sheets' could be useful from a user point of view, because if somebody has created a style sheet that is completely unusable for me, I might have a certain color deficiency or whatever, for whatever reason, it doesn't linearize properly and I really need it linearized … Having a plain vanilla browser I can't very easily, unless I'm going to dig into the preferences again, say "ignore the entire style sheet". I looked at the other day from an IE point of view. There are options to say "ignore the colors that the author has specified" "ignore this" "ignore that" … very much text based, but there's nothing that says, for instance "ignore positioning" "ignore floating" or whatever, something that makes it linearize.

All that functionality, that's mainly meant for developers to do their accessibility testing or whatever, that says "linearize this page." That would be great if you just had a very functional, four or five button toolbar that's very obvious and basically says: "this page is crap I want it in a linear format" "the colors aren't working right, I want to expunge all style sheet things" "the javascript is behaving funky with my screen reader, disable it". Just have it right there in your face, but for users, not for us developers, because we already know what's wrong with it anyway and that helps us kind of streamline our testing, but … somebody think of the users!

Bruce: That's right and for the users really means in the browser chrome.

Patrick: Because otherwise you'll say "Who's going to install that", although at that stage you could start widening the discourse. Widen the discourse! Yes, you can tell I've been working at university and in marketing for too long. You can widen the discourse by looking at the stakeholders. What was I saying?

You can start arguing that support agencies, companies like the RNIB, RNID — organizations, not companies — maybe are the right ones to then create guides for their customers that say: "if you are blind or heavily visually impaired, or whatever, or if you have a certain color deficiency or whatever, this is what you really want: you want IE and you want to install this, this, this and this, for these reasons this will make your life a lot easier", rather than creating guides saying "this is how you can work around problems in your browser", actually have them having more of an active role in user education, saying "hey, yes you need a screen reader, these are the screen readers available, this is what you can do if you need your text bigger, this is what you can do, you can install this."

Again, there's a lot of people that need to solve this problem. To bring it back to my main point, there's a lot of pressure that usually is just applied to web developers, who really are the ones at the coalface; we're the ones that, for a majority of cases anyway, we know what's the right thing to do but we're trying to compensate for so many other things that are missing: users who are too thick to know they can resize text because they've never been told, and it's never been exposed to them by the browsers. Browser developers need to make their tools more obvious, more fit for purpose, for their particular audience.

As I said, RNIB, RNID should really work with their — I'll call them customers, the people that they're trying to help.

Bruce: Stakeholders.

Patrick: Stakeholders, thank you very much. Work with their stakeholders to help them, help in the education that they need to set up their browsing environment in a way that's beneficial to them. Because you know there are certain things we know can be done and problems will not appear, or at least it will mitigate problems which you may encounter on the Wild, Wild Web.

[audience comment]

Patrick: There are a lot of issues involved here. There are a lot of players involved here, a lot of stakeholders, that really, we all need to start — it's getting to be a very "tree-huggy" kind of thing — we all need to start working together, take care of yourselves and each other kind of thing, to make this work. But the pressure's really mainly on — what you see a lot, anyways — developers: "Oh you're not developing to WCAG" or "you're breaking this particular guideline". Sorry, that was a mega-tangent, this one. I'm just checking to see if there's anything …

Bruce: We'll do the talk roundup and then break for questions.

Patrick: Oh yes, just one more point … a little point. If you remember way back about probably half an hour ago, I talked about the top four bad things I did — you know, me bad — on the Salford web site. I think I've covered the first three. The fourth one was this interactive branding thing. It's just a little one that kind of ties into an interesting point that I hope I've got.

So, this interactive — as I say will be great to show it — this interactive exploration of our branding, which, just to say from a … hang on, I'm going to stub this out …

… which in our print campaign, in our poster campaign, is really a massive poster with the actual full-on montage, colors and everything else. You know, these photographs cut up, mashed up. Underneath there's a little key line with numbers and then …

[diet…Diet Coke for my lean figure]

… all the things have got numbers, and for every numbered point there's the explanation … "We chose this image because", in sexy terms "this represents the courses in avionics that we do, and this shows that we work with the community" or whatever.

As I said, I needed to do some kind of sexy, kind of interactive, or multimedia way of presenting that for our new branding on our main site. So, what I did, I looked up various options and what I ended up doing, if you visited the Salford web site, is you'll see it's a big image and it's marked up as an imagemap. Wherever there's numbers, that actually uses a bit of JavaScript that I crafted. It pops up the explanation right next to where the number is. It works both with mouse and with keyboard. It uses JavaScript so I also implemented a non-JavaScript version and I had a very discreet, but still fairly visible link that comes before it that says "This uses JavaScript. If you're having problems you might want to switch to the non-JavaScript" and vice versa. You can flip backwards and forwards between them.

I've really spent a bit of time, that probably took me the longest … well, that was the longest single section that I spent on the development, because I knew that I really wanted to do the right thing in a lot of cases. I did not want to have something that if we gave it out to tender to a design company that it would come back with a nice bit of Flash and it would have been completely inaccessible. So I said "Look. Before we do that, let me try and do something that still has the visual effect that the marketing people were after" and most of them would try it with a mouse and it works with a mouse, great. I did my testing with a keyboard. It worked reasonably well there as well. JavaScript, non-JavaScript, as I said, that works.

When I started thinking about it, I thought, well, yeah, that's great. But, what if … cognitive disabilities, that could create a problem because text comes up and disappears. Also, if I'm using something like a screen magnifier, because of the way the whole thing is built, it might be that, yes, I can use my keyboard or the mouse to highlight the certain numbers, the text appears, but the text because of the way it's laid out, it's kind of a nice sexy box, but it might move off the viewport that I've now got because I'm zoomed right into the page. If I, depending on how I try to move my focus away to see the rest of the text, the whole thing might be disabled again and the JavaScript would disable that kind of textual presentation again. So it might create loads of problems or be, at least, reasonably difficult for certain types of users to use. I've tried working around a variety of options, but in the end, again the pragmatic thing was that I willingly said "OK, it works for … " and that's a point that Bruce was keen to make, I think, in the book as well, is that as much as we want to create content that works for everybody in every single situation, you have to pragmatic as well and say "Yes, we don't want to exclude anybody, but if you really are tied to a certain deadline, a certain amount of time, a certain set of resources, is it that wrong to … yes, try your best, if you initially work toward 99% of your audience? Yes, it's evil to say "You're only 1% and we're not going to cater for you". In an ideal world we would create a solution that works for everybody, but, when push comes to shove and there is no one way of satisfying every single type of user, is it evil to say "99% of our visitors are sighted; of that about 80% use a mouse. The other ones are sighted but use a keyboard. And then yes there will be users with cognitive disabilities, and yes there will be users with zoom text, but we can't accommodate them in the current kind of format. If they have a problem, yes we have very clearly marked up help files in terms of 'If you've got a problem with any of our content, please contact us and we will do our utmost to help you.'" But yes, there is the anticipation aspect of making your site as accessible as possible, but is it that bad?

If you're really pushed and you just concentrate on the reality of 99% of our users are sighted. Yes, I will try to do my utmost to make it work for screen readers, but if it comes to a certain situation I might have to willingly and knowingly say "Yes. I know for a fact this won't work for this particular group. Is the risk worth taking?" So it's about the pragmatism, again, obviously in a discussion if I put that online now in a mailing list or on a forum you'd get the "Oh that's nonsense! Of course you can! Macromedia have created this way. You can do the Flash and make it accessible. You need to do the fallback content in the object and this and that."

And as I said, these are all great if you've got the budget, if you've got the time. Obviously if you have that, there's no reason from the outset say "Well, we're just not going to bother with them." But as I said, in the real world, in the reality, that's sometimes what you have to do.

[audience comment]: Do you think you have to mention these compromises in your accessibility statements?

Patrick: Yeah, definitely. Be open about your decisions if you can. If you say "All our site was working. We built it to the best of our abilities. We're striving as much as we can to make it accessible to everybody. We are aware that certain sections will not work." If you want to list them, if it's only a handful, you can say "Yes. We are aware that that particular thing is not accessible. Please let us know if you have a problem and we can provide you with a content in an alternative format." And then obviously if a call comes in for that, be prepared to actually put the time in to do it.

Then you've got actually something that you can take to, going back to all the people that pay us, if you've got the evidence that you can say to your manager or whatever, you can say "Look. We have had a request. Under law we are obliged to at least acknowledge it and do something about it."

Whether it now be "We will prepare you a separate version and send it to you", or "We'll spend more time and actually develop it on the web site so that we avoid having the same problem next time around". Yeah, as I said, but it makes it a lot easier also to sell. Again it's all … you can't say cut and dry, but it makes it easier then to sell to your manager. Rather than from the outset sit in the meeting where they say "Oh we need this. And when you move the mouse it comes up." And somebody sits in the corner and says "Oh that's not going to work for people that are using this particular browser with that cognitive disability and the text zoomed in at like 400% or whatever."

It's about weighing up these various problems. I was just saying about the reality is that on the Salford site, 99% of people probably are, like I say I don't have any hard figures, but say 90% are visual people that can see the site. And of that, the majority will be mouse-using visual users and that yes you can acknowledge it, but acknowledging that there will be problems, but sometimes you have to be pragmatic.

It's also, yeah on that particular one with the sexy, all singing, all dancing explanation of the key lines, the one thing that also I had to weigh up was "What is the shelf life?" and that's one of the things I'm very keen on as well as a factor. What is the shelf life of that particular resource or site that you're doing? I knew that this particular case, just this section with the "explore limitless possibilities" thing, would have a shelf life probably of about six months at the most, because that's when a new run of the branding will come in. It will be along the same lines but it will be moving further.

What we really needed to do with this one was we need to really make a big splash for both internal and external purposes saying "Hey we got this cool new stuff happening." In six months times I'd be very surprised if that was the main focus of the home page. It'll probably quieten down more and come back to "These are the great courses that we offer, this is etc."

So it's all good and well sitting there saying "Yes we need to do it." It goes in with the resourcing and the time issue. If it was something that I knew was a fundamental section of our site from now until eternity, the next six, seven years all our business depends on this, then you've got a far stronger motivator or driver — oh, a bit of marketing speak there — to actually say "We need to really make sure that yes, there might be only one percent but we need to make sure that we get it right."

It starts getting thinner and thinner, the response that you get from marketing if you said "Yes, it's only one percent and it's only going to be up for six months, and it's an outside chance but we need to address it." So again it's about in the real world, rather than the limitless time, limitless resource, sterile, vacuum packed lab that the W3C might create their things in, you have to weigh that up. That's just one of the many factors that come into play when you decide how far you take it.

You decide it very knowingly sometimes saying "I know for a fact that what I'm doing right now will exclude a certain group." If you're prepared to do that, if you've got a good reason for it, and you also know if a call comes in, how to remedy that, then that's great.

Again it's dangerous now to take that as a snippet now from tonight and say "Oh well, we went to Geek in the Park. Patrick says, 'Fuck 'em'". Don't really care about them. As long as you're knowingly doing it, that's fine. Yeah, fuck 'em, I know them …

German people using the web? Nah, fuck them. And I'm German so I can say that.

But as I say, it's about the pragmatism, really. If there's one thing to take away from this, it's about "Yeah these are all the things, in the real world you have to make that kind of decision" and you have to go by triage and say "These are all the things we'd like to do. These are all the other things that we need to do."

Try to do them the best you can, at least that's what I'm trying to do in most cases. I try to do the best I can. I don't have to agree everything with my bosses or anything else, and that touches on … we do a lot of things under the radar, we try to do a lot of things hidden away. We've got skip links but they're at the top but it only comes up and becomes visible as a proper text link when you hover or when you set your focus on it, so when you move with the keyboard … Arguably you know it should be there. The hard-liners will tell you "It should be there at all times. So that even somebody that comes to the site for the first time, they might be put off right away if they don't see a skip link right there and think, 'Oh, it's not worth the hassle.'"

But I argue that if it's a first link in your tab board and it appears the way you've done it and it appears where you'd expect the first bit of content to be, top left. Yes if you have your, oh yeah, it activates if you tab to it but we actually still hidden it away some here at the bottom. Somebody who might be using a zoomed in view or something with a magnifier, they might miss it. But basically we've carefully placed it where people would expect the focus to move anyway.

You can start saying that "Yes in an ideal world we would have it visible … and yeah why not make it a feature of your design?" Yeah, great, if you've got people that are open to that, I'd rather have a very visible skip link that is nicely integrated into the site and doesn't look like "Oh yeah, and we've plastered this on at the end because we need to." But in all other situations to make it stealthily under the radar, sometimes there are solutions that are not 100% optimal, but they will, if you're doing it with the knowledge of what you're trying to do and who your end-users are going to be and what their issues might be, if you do it that way, you can at least do something that is not 100% evil while still doing it under the radar if you've got the time …

I mean a lot of us, I think you mentioned before, we beaver away sometimes … or we badger away, I don't know … one of the two. If it was a chargeable job I might just do it without telling you, just because I'm committed to actually making it, doing the right thing. But as I said there is the tension where doing the right thing in the eyes of whoever pays your bills starts conflicting with other requirements and other drivers you've got. As I said: corporate identity, logos, need to be in a certain typeface, etc.

So … there isn't really a conclusion to what I've told you.

Oh beautiful. I think just for my part, don't throw stones at me if you go on to Salford website and say "Oh yeah, he's all talk when he's out there on the mailing lists and stuff. But look what he does … 'Do as I say, not as I do' kind of thing", but as I said there are the realities that sometimes need to be taken into account.

And yeah that will pretty much conclude my little bit.

[audience comment]

Patrick: I can sit down now. Yeah.

[audience comment]: I think it's interesting, the lengths that we …

Patrick: the length of your talk is incredible! [laughter]

Pub's closed now. Go ahead. I'm sorry.

[audience comment]: It's incredible the lengths that we go to to make things accessible. If you turn the clock back five or six years, nobody would give a shit. It was all "I can do this cool thing". Do you think we've become more morally aware, or is it a case of box ticking for our clients?

Bruce: To be honest, I don't personally, I don't have many clients who really give a shit until I tell them that that list …

[audience comment]: The legal requirements.

Bruce: Yeah.

[audience comment]: Accessibility nazis who send you their list of things that are wrong with your site …

Bruce: Yeah, they're box ticking …

Patrick: that's what I do in my lunch hour just to keep myself entertained. Your site is shite, and this is why …

Bruce: Well, I had a go at the DTI.


Bruce: I find that the stuff about the Legal & General stats impresses more people. But also it does become obsessive and I find myself becoming obsessed — is it an abbreviations, is it an acronym — and getting overly obsessive, but the "take home" that we'd like you to get from this isn't Patrick saying "Fuck 'em", though …

Patrick: Although it's quite good! It's quotable.

Bruce: It's good, yeah but only quote Patrick and don't involve me in that quote.

But what we'd like you to take home is that a lot of things that we spend a lot of time doing we shouldn't be doing. It should be the user agents. Now is a good time because all the browsers are back in development. We've got a list that we've been jamming together of things that we'd like the user agent manufacturers to think about. Off the top of my head, I can't remember all of them, but there's things like skip links, that should be a UA feature, not us.

Patrick: … title appearing …

Bruce: The title, when you're using the keyboard, the title should appear on focusable things if there's a title. It shouldn't only be on hover. How the hell the browser manufacturers can justify some information only appearing when you hover … that is completely ignoring the User Agent Accessibility Guidelines. Other things like I believe Safari still doesn't pass the focus to a form … to the input when you click to the label. Now that's such a good …

Patrick: That's a known bug and it has been filed years ago.

Bruce: Yeah, yeah, and I know Jeremy Keith, God bless him, has some script that allows you to plug that with JavaScript, but we shouldn't have to. It should be them.

And the last thing I want to say is that: if we get too obsessed about perfect accessibility, and there never can be, we can do ourselves a disservice in the eyes of our clients, I think. I've found myself banging onto clients, and you can see them thinking "We're never, ever, ever going to think about accessibility ever again, because this bloke's … "

Patrick: And that goes back to maintainability as well. If you're handing over the site, it's like peeing yourself when you're in black trousers: it gives you a warm feeling but nobody notices. [laughter]

It's great — it's great: you hand over the site, and it's plus parfait — it's absolutely beautiful markup and then the next week they've passed it on to their internal team and because they found it too difficult, they just stuck a table right in the middle of it.

Bruce: That's right. And nobody wins, and you can't even say … and you're embarrassed about that site, because if you cite it on your CV, people think you put the table there, so nobody wins.

What we're trying to say is: let's not talk about in ever, ever more navel-gazing about accessibility; let's actually go out there and do what we can under the radar as part of the job and when we publish our wish list for the user agent manufacturers, if we put it on the, maybe comment and say "Let's do it " let's get a bit of momentum and we'll all benefit.

Patrick: There's lots of grass roots aimed at developers. We need to make web developers more aware of WCAG and everything else. That still needs to happen. I'm not saying shift the blame, but I'd love to see the same kind of pressure, especially from groups like RNIB, being applied to browser manufacturers. Obviously they all think in terms of money, but if it starts becoming a really bad PR job all across the media, saying "Even RNIB or whatever suggests switching from this browser to that", and they're getting all their stakeholders to do that, Microsoft will probably start noticing. [ … ] This is not a Microsoft job; it's not Microsoft-bashing; this is all-browser bashing. Dave Hyatt from Safari — get him on board. He does comment every now and again — he's jumped in on the other rant we had … well, I had … on the XHTML 2 stuff. So he is aware … this is a new generation, or at least the old generation that's now more visible in their corporations. People like Chris Wilson, they do listen; yes, Microsoft has changed.

Bruce: And they do care.

Patrick: Yeah. People might say "Oh, they're now starting to do blogging; they're trying to make up for it." But yeah, OK, they're trying to make up for years of bad PR, and bad decisions, but now is the time, because — I'll be a bit controversial, ooh! — as opposed to some of the members of the W3C, these are actually people that engage with the community rather than just sitting in a sterile lab and saying "This is the only kind of markup that people will ever need to mark up their documents", and then all of a sudden that hits reality, and it's like, why have you still got all of this computer science crap in your thing: samp, var, kbd? Wouldn't it be better if you had more semantic elements for things like footnotes?

I'd love to see a sensibly implemented element or set of elements to handle footnotes, and then not have the developers like us worry about "Well, should I have it as a link in a square bracket that I then style to make it look like the typographic convention of a footnote, and then that links down to the page, and then I need to provide another link that links me back to where I was … " That is one of those things where I would think … and now is the time for XHTML 2, because it's still not out, and as I said, it will be a long lead time before it's used, but if we can't expunge the crappy kind of elements, like samp and kbd and var, and if we can't, start lobbying now for "Can we not have elements in there that actually make more sense?"

Things like a matched pair of footnote kind of elements "Here's to go to the footnote, here's to get back", or whatever, and then we can say, quite rightly "Well, this is a user agent issue", and not have things where the user agent should magically work it out with heuristics "They've styled it like this, it's got a square bracket. This is presumably a reference to a footnote" but actually have something that is inequivocably tied into markup and says "This is actually a footnote", or whatever the non-print-background-related generic name for that kind of thing would be "additional information" or whatever. Different levels of information.

Then we can say, if that's in the spec, then we can say to user agents "Our time of making up for that is done. Your user agent needs to start supporting that because it's part of the spec."

Bruce: The user agent should be able to do things with this information; the onus is still upon us to mark it up as well.

Patrick: Yeah.

Bruce: Anyway, thank you very much. If you've got any questions, why don't we all have a pint first and then reconvene.

Patrick: [laughter] The answers will be far more amusing!

Bruce: Mine's Pedigree.

Patrick: Pal! [applause] We're available for children's parties, especially my rantings about all this.

Bruce: Bar mitzvahs, funerals, and satanic orgies. Karen, you had a question …

Design elements on this page borrowed from the original Geek in the Park site, created by the MultiPack. Original photograph by Neil Crosby.

Initial transcript provided by CastingWords, with subsequent editing by Bruce Lawson and Patrick H. Lauke. Released, like most other works on this site, under Creative Commons Attribution-NonCommercial-ShareAlike 2.0.