IE testing made easy
Testing in Internet Explorer is horrible for many reasons. Not least the fact that you cannot run multiple versions of IE on a single operating system.
In the past there have been a number of solutions to this problem. There were standalone versions of IE. However, it quickly became apparent that they did not behave as IE does natively. There are online services which provided screenshots of your site in different versions of IE. However that does not give a sense of whether interactive elements were working correctly.
The only really feasible solution was to run multiple operating systems as virtual PCs but this was slow and inconvenient.
However, it looks like things might be about to change. DebugBar have just released IETester. A free web browser that allows you to have the rendering and javascript engines of IE8 beta 1, IE7, IE 6 and IE5.5 on Vista and XP all at once.
They are currently describing it as Alpha software (whatever that means), so it sounds like it is still a work in progress. As with any such software it is hard to know if it is accurate. If you do choose to use IETester, I would still recommend giving your site a final once over in native copies of IE before making it live.
That said, this does look very promising and I will be trying it out myself very soon.
Hosting your Javascript libraries
Our next story is an announcement from Google. They have started to host the main Javascript libraries including…
- jQuery
- prototype
- script.aculo.us
- MooTools
- dojo
This means that if you are using a Javascript library it does not need to run from your own server, but can pull it directly from Google.
“Why would I want to do that?” I hear you cry. Mainly to improve performance. First, according to people much cleverer than myself the Google servers are faster and can deliver libraries much quicker. I know little about server performance so I will have to take their word on this.
However the main reason is that if enough web developers use this approach we will see a significant caching benefit. Lets say a user visits headscape.co.uk and this site pulls its jquery library from Google. Boagworld.com does the same thing so when the user visits that site it uses the cached version (from the visit to Headscape) rather than re-downloading it again. As more and more sites pull their Javascript libraries from Google the likelihood that a user already has a cached copy of that particular library increases.
Of course allowing Google to host your Javascript does require a level of trust. What if Google goes down? What if Google turns evil and starts using Javascript to manipulate your site? What about the data this approach gives Google about your site?
However, if these concerns do not worry you, then there are definitely tangible benefits.
Prototyping website interaction in flash
Next up we have a tutorial demonstrating a quick and easy way to prototype complex website interactions.
In some ways the static Photoshop comp is becoming less useful. Modern websites have numerous interactive elements that are hard to convey through static images. There is a need for something that can demonstrate this functionality.
We have spoken before about wireframing interactive websites, but not how to demonstrate changes in visual look and feel. This article on boxes and arrows suggests that Flash maybe the answer.
The advantage that flash has over something like a clickable PDF is that it allows for easier updating when the client wants to make changes. However, it does require basic Actionscript skills. Fortunately, the tutorial talks you through these step by step and none of it is too challenging.
If you are looking for a way to better demonstrate interaction in your design comps then this might be the answer.
The rule of thirds
The final news story today is another post from those lovely people at Smashing Magazine (we love them since they said nice things about our podcast!) The article entitled “Applying Diving Proportion To Your Web Design“, introduces the reader to the fascinating subject of the golden ratio (also known as the divine proportion or rule of thirds.)
If you haven’t come across this principle before then I highly recommend reading more. The rule of thirds emerged in the Renaissance but has always excited in nature. There seems to be something inherently pleasing about these proportions and they occur again and again. There is something about human perception that is naturally drawn to this composition. We can use this to our advantage when designing websites.
The article goes on to demonstrate how the golden ratio can be used in all aspects of design from photography to web design. In particular it focuses on the benefits this can provide to the grid structure of your sites.
Admittedly if you have not come across the rule of thirds before this can all sound like hocus pocus. However it really does work. Following principles like this can dramatically improve your designs. What is more they can be followed by anyone even if you would not consider yourself a designer.
Back to top
Paul: So joining me today is Patrick Lauke from splintered.co.uk, is that best way to refer to you?
Patrick: Yeah, it’s one of my many monikers, yes.
Paul: Just so many presence on the web, you’re just so well known. Good to have you on the show, Patrick, it’s been a while.
Patrick: Thanks for having me.
Paul: I don’t think you’ve actually been on Boagworld before have you done Dot Net with me, but I don’t think you’ve done Boagworld.
Patrick: Exactly, yeah, I’ve only had the pleasure of sitting on the Dot Net one.
Paul: Well this is the proper grown up, you know, professional version compared to Dot Net.
Patrick: Super!
Paul: So the reason I wanted you on the show, Patrick, I have to be honest is as much for me as it is for my listeners this time round, because you are our resident accessibility expert, and we had a conversation a long time ago on the show about WCAG2 and we talked a little bit, not with yourself but we’ve talked on the show before about WCAG2 and it was coming along and all the rest of it, but it suddenly occurred to me we haven’t done anything on it for ages, and I’m wholly ignorant on the subject and the current state of affairs, so I thought, I know, I’ll get Patrick on the show, I’m sure he’s bothered to read it and knows what’s going on. Hence you’re here.
Patrick: Excellent.
Paul: So you’re not going to let me down, you have actually read WCAG2 have you?
Patrick: I have, I’ve been fairly involved with it, yeah.
Paul: Good! That’s encouraging. OK so perhaps the best place to start is, where’s it currently at, what’s the stage of development at the moment?
Patrick: Right, well literally a few weeks ago it entered what’s called the Candidate Recommendation Stage, all part of that W3C terminology they use. It wasn’t…it has been in last call for about 2 years now, but yes, Candidate Recommendation really means that now the WCAG working group and the general public has been kind of sending in comments etc on the status of the document. They’ve all reached kind of a broad consensus about, yeah, it’s fairly…it’s pretty much there, you know, it’s fairly accurate, technically there’s no big howlers in the actual wording of the things. I mean there might still be a few minor, minor details that change from now until the end, but pretty much the actually core of it is as good as it’s going to get.
Paul: OK.
Patrick: And really the…kind of the purpose of this Candidate Recommendation Stage, you know, why aren’t they going straight out and releasing this now as a standard, is really to give people an opportunity to start test driving, you know, what WCAG2 says in its current state, so working group thinks it’s pretty much there, let’s test it out actually in the real world, so give people the opportunity to run it…run their websites through their paces according to WCAG2, see if, you know, things are feasible, if it’s realistic to kind of say, yeah, this will be the standard from now on, and they’ve actually…they want to make it quite official, so if you have an intention of kind of doing that, you have a website and you want to actually officially say, OK, I’m going to use that website to test WCAG2, they’re now asking for people to basically register their interest and to actually, you need to then implement that, you need to say, right, I’m going to run WCAG2 on my site and by the 30th of June you want to be able to basically say right, I’ve finished it, and then give feedback and basically say yeah, no problem, or you know, we tried and tried, but this is actually not realistic, it might need to be modified, but unless there are major, major issues that come out in the wash as people are now trying to implement it and test drive it, it should be fine really. One of the main things with WCAG2 is, as with any kind of Candidate Recommendation documents, is really that there are a few items where even though we’ve got consensus, the working group isn’t 100% sure that they’re going to make it in their current stage, so they’ve kind of gone very ambitious with some of them, but they realise that yeah, it might not actually make it through, and they’re called….quite fittingly, items at risk, which in the latest CR document, Candidate Recommendation document, they’re clearly marked, and they’re basically…the testing phase is really about, let’s have a look, specifically these kind of items at risk, can they actually be implemented in the kind of more stringent way that we’ve worded them? If not, we might have to scale them back. I mean there’s one for instance where it says, it talks about, you know, colour contrast, and they’ve worded it currently that the contrast needs to be on a ratio of 5:1, so if you’ve say got, you know, text and background colours, you need to have…want to do your calculations for the various algorithms, there needs to be a contrast of 5:1. Now they’ve put that at risk, because some people still felt that it might be a little bit….setting the mark a little bit too high, and they were already saying, OK, well if it turns out that it is too ambitious to say, right, you need to have that ratio, that they’re happy to kind of jump back to 4.5:1 or even 4:1, so it’s kind of things like that, we’re really now at the nitty-gritty stage with these kinds of things, of saying, you know, can it actually be implemented.
Paul: So this is getting very close to the point where, you know, your average website owner and your average web designer needs to be…we need to be looking at this now, don’t we really? I mean we’re getting that close?
Patrick: Yeah
Paul: OK, I mean it sounds like things have gone a long way since the kind of early stages where WCAG2 was quite heavily criticised. I mean what kind of shape do you personally think it’s in at the moment?
Patrick: Yes, I mean looking back, I think it was May 2006 where Joe Clarke wrote his kind of vitriolic post, to Hell with WCAG2 on A List Apart, we have definitely come a long way since then. I think it was a good wake-up call back then for somebody like Joe, somebody of Joe’s stature, to really come along and, where web designers maybe at that stage weren’t really that interested in WCAG2 to actually say, look guys, you need to start looking at this because in the current shape it’s in, it’s really not feasible, and what Joe said at the time, there are many things that he criticised, but you know, overall he was spot-on with a lot of the things. The main thing was that the whole document at that time was extremely bulky, it was one big monolithic document which tried to do everything. There was loads of Orwellian-style language, everything was made up of Newtons, and they pretty much invented…because the problem with WCAG2 it’s a kind of full shadow of it, is that because it tries to be technology agnostic, it tries to avoid in the main document and talk about anything relating to actual technology, so it doesn’t mention specific HTML elements or things like that, so to make it very tech-agnostic, that document at the time really re-defined almost anything, so it didn’t talk about web pages, but it started ta
lking about web units, and basically the glossary was almost bigger than the actual document, so you know, that was very problematic because even people who’d been doing web development for years, if you just gave them the document as it was, they would have had to completely re-learn whatever all the terms were, it was of no practical use.
Paul: So has all that gone now?
Patrick: Yes. The language has been simplified. I mean it’s gone now from 2006 onwards it’s gone through, I think it was 2 or 3 last call stages. Well it went back from…in 2006 it was at last call stage, literally the stage before we’re saying, OK, we’re up to Candidate Recommendation. They actually scaled that back. W3C don’t admit that was because of Joe Clarke, and OK, it was probably not exclusively because of his article, but I think the general kind of feelings that it stirred up, or that it tapped into, kind of made the W3C reconsider. They’ve scaled it back to a public working draft, which is kind of one step previous to that. Everybody had a pretty good look at it. There’s been rounds and rounds of comments, I mean I’ve submitted in the 2 year period that it’s now been since that article, I’ve submitted loads of comments. I mean ranging from really small things like, oh you missed a comma there, or that’s not very clear, to kind of very substantial things about the actual core concepts that are being discussed, and in that process, a lot of really hard copywriting and editing has happened since then. They’ve also split out the document into far more manageable sub-documents themselves. One of the main things, for instance, is that the whole structure of, you know, WCAG2, it’s actually a suite of documents. The main guidelines document itself is only a handful of pages, I think it’s…yes, 19 pages I’ve printed out today. That is purely the core guidelines document, and that’s the only part if you will, that is actually normative, that’s the only one that is the actual guidelines. Then there was a lot of extra documents that really are just what’s called informative, so you can read through them, but you can’t actually refer to them in terms of, you know, just if somebody sort of says, your site isn’t accessible, you can’t point to an informative document and say, yeah, but I’m following that particular thing.
Paul: OK
Patrick: One of the documents will be the techniques document. You can’t actually point to that and say, well I’m following these, because the only thing that’s important are the actual guidelines, so they’ve really slimmed it down, broken it up into separate documents, you know, 19 pages printed out, it’s nothing, you can pick that up, you can read it through. It’s roughly the same size now of WCAG1 if you will. So they’ve simplified the language. There were loads more contentious kind of fundamental problems with WCAG2 as it was back in May 2006. I mean one of the main ones that really caught, you know, the eye of a lot of developers, was the concept of base lines where basically at the time they were saying, even though the concept itself is good, but it’s pretty much read like, as a website owner I can basically say, right, to work with my site, you need to have Flash and you need to have this and you need to have that, which was completely opposite to, you know the very austere WCAG1 which basically said, you can’t have anything. This seemed to open it up completely and allow for website owners to basically say, right, you know, we are going to do a whole Flash website if you will, and our baseline will be, you need to have Flash to use this site. But the concept was good at the time, but the wording pretty much came out like that, so these kinds of things, base lines, at its core, is actually still in the current document. They’ve basically re-worded it and turned it on its head, where before it was talking about website owners can say what technology they’re using, now it’s far more, if as a website owner or designer, I’m using a technology, I need to make sure that I know for a fact that it’s supported by accessibility…assistive technologies, for instance screen readers, so they kind of turned it on their head. The onus isn’t any more on the user to say…to have the latest technology, but on the developer to make sure that the technology they use needs to be accessibility supported. So loads of kind of fundamental changes like that have happened really, and no, definitely to go back to the original question, it has improved quite dramatically since May 2006. I mean I’ve now familiarised myself extensively with it. It’s good bedtime reading material!
Paul: You’re not convincing me of that one. Not unless I want to go to sleep I guess!
Patrick: I know. OK, I’ll be blunt, it’s better toilet reading. You kind of print it out and you put it there, instead of a novel you’ve got that there. But it is very good. I mean it’s now down to the level of…it almost reads like common sense. You kind of…you go through it and you just find yourself nodding and thinking, like, that’s not contentious. OK, there are still a few here and there where I might slightly disagree in a heated argument, but overall there’s nothing really there that makes me think, ooh no, that’s never going to be realised, so absolutely, it’s in very, very good shape I would say, and this Candidate Recommendation Stage looks like it’s going to be very successful really, and fingers crossed, I think; I’m not 100% sure now of the timeline that W3C are working by, but I wouldn’t be surprised if, say by the end of calendar year, we might see actually WCAG2 being released and getting out and becoming a proper recommendation.
Paul: Cool. So then what’s the big differences from WCAG1. I mean with WCAG1, you know, every kind of standards-based designer became very familiar with that. I was a great fan of that, you know, single sheet which listed everything by priorities and I would go through and I’d check myself off, and I kind of knew where I stood with WCAG1. With WCAG2, it’s much more of an unknown entity at the moment, so kind of give me the potted version. Where are the big changes?
Patrick: Right. No you’re quite right, it’s actually a lot more vague WCAG2, but it’s that way for a reason. Right, so WCAG1 really was very much, I mean it’s a product of its time, I mean it was 1999, the web was still quite in its infancy, and it is very much HTML focused, WCAG1, there’s no denying that. There’s a few mentions of things like CSS, but pretty much it’s all about how to use HTML to create content that at the time would be deemed accessible. I mean JavaScript was pretty much bad; I mean you could use it but you need to make sure there’s a fall-back. Non-W3C technologies were completely out basically, unless you provided a W3C alternative, so things like Flash and PDF etc, when they first started becoming more and more used, that directly clashed with WCAG1 at the time. Now WCAG2, as I mentioned before, it’s far more tech-agnostic. It tries to basically not t
alk about specific technologies. It doesn’t directly reference HTML or CSS or Flash or Flex or various other things in the actual core guidelines. Now the reason for that is WCAG1 as soon as it was released, the thought behind it was that it would be updated on a very regular basis, but from 1999 onwards, nothing has really happened, and because it was so heavily influenced by the technology of its day, it aged very, very badly. I mean nowadays, if I hear people saying, we’re building against WCAG1, I almost have to chuckle a bit, because it is pretty much just going back to, you know, we’re doing the web like it’s 1999, you’re not really allowed to do anything, and it’s completely opposite to what’s actually happening with the web. I’m not going…well I am going to say Web 2.0 to sound all trendy, but you know, all those things, Ajax, Flash, PDF etc, particularly say PDF, there is now…there are now easy ways, or relatively easy ways, to create reasonably accessible PDFs, I mean the technology itself has moved on, the format has moved on, screen readers are quite capable of dealing with well-structured PDFs that are created in a certain way. We’re not really talking about, you know, you need to test your pages with links because, you know, people might just use a text only browser. Things have moved on, but WCAG1 is pretty much kind of frozen in time of 1999. There have been a few kind of…people who’ve been working towards WCAG1 have started kind of re-interpreting it a bit for the modern days. I mean in my own practice in my…one of my other identities, in my day job as web editor for the University of Salford, I’ve never actually said, we’re going to make our pages WCAG1 compliant, but always said, you know, we’re going to take inspiration from WCAG1, filter it through our own knowledge of what the technology landscape actually is today, and try to do the best we can to actually serve the users and you know, how they currently use the web.
Paul: So….so are you, you know, you said that you’d never claimed in your day job, you know, to be WCAG1. Are you intending, you know, are you more confident in WCAG2 to be able to say that, that we’re going to be WCAG2 compliant, or is it not that kind of thing?
Patrick: I think …I think yes, WCAG2, it would be a lot easier to say we’re working towards WCAG2, because to kind of go back a bit and explain WCAG2’s kind of…the thinking behind WCAG2 and how it’s structured. WCAG2 as I said, doesn’t talk about HTML, CSS, it really just sets out very general principles, when then break down into guidelines, which then in turn break down into success criteria. Now again it probably sounds like there’s a whole new language to learn, but it is fairly straightforward, so if you think, web pages themselves need to be the four principles. They need to be perceivable, operable, understandable and robust. So those are the four kind of guiding principles, which you know, make sense. It was already implicit in WCAG1, but this kind of just spells it out. These are the kind of four things that we want to make sure. Now under each of those principles, say perceivable or whatever, there are guidelines which still provide…they don’t go into detail, but they provide some very, very basic overall goals, so what we want to achieve is X. They’re not testable, because they’re still very, very generic, they’re saying, we just want to make sure that people can, say, use a keyboard to do things. They don’t go into detail about what that means particularly. And then under that you’ve got the testable, what are called success criteria. Now these are very small kind of little atomic sentences if you will, that say, right, very specifically, if you’re providing this, then make sure that that happens. Now I’ll pull out an example, I’ve made some notes here, let me just go through…yeah, I’ll give you an example here. So in the big WCAG2 document, you’ve got principle number 2, operable. User interface components must be operable. So, you know, you can’t argue with that, fair enough. Underneath that, there’s loads of guidelines, I’ve pulled out one here, guideline 2.4, navigable, which states that you should provide ways to help users navigate, find content and determine where they are. Again, that’s a very, very broad goal that doesn’t say anything about you need to use a link, you need to put title in here, or you need to make sure you use access keys. None of that. It basically just very generically tells you that. Now under Guideline 2.4, there’s loads of smaller success criteria. Now I’m just going to pull out one of them. The first one, 2.4.1, which basically is called bypass blocks, and I’m just going to read it straight from the thing, ‘a mechanism is available to bypass blocks of content that are repeated on multiple web pages’
Paul: Yes
Patrick: Now again, this doesn’t say anything about HTML or whatever, but it is quite testable. You can actually pull up your web pages and say, right, are we following this? Is there a mechanism available to bypass blocks of text, blocks of content, sorry, that are repeated? So I don’t know if that gives a flavour of…
Paul: Yeah it does.
Patrick: …against WCAG1. Now you couldn’t write a validator to actually just run through this and check for that, that is one of the core differences I think with WCAG2 compared to WCAG2. I mean even WCAG1 we all agreed that you can’t just run it through Bobby and then, you know, if Bobby gives you the thumbs up, that’s good. You still have to do some manual checking. But there were a lot of things that because it was so HTML-centric, you could pretty much run it through something and it gave you a fairly good indication of whether you were achieving that particular check-point in WCAG1 or not. Now the way the success criteria are worded, yes you could say, OK, if we accept that, we want a skip link, and the skip link will fulfil that particular success criterion, we could write an automated tester that just looks for skip-links, the presence of skip-links, however you want to code that, but it’s not to say that that is the only way in which you can pass that success criterion. The actual guidelines don’t say exactly what you’re supposed to do. They pretty much focus on the end result and particularly what I’m interested in, they focus on the end result for the user for the most part, so it really puts the onus on the developer to understand, these are the user needs, and this is the kind of very generic thing that needs to happen. You can then, from that success criteria, jump over to the techniques document for instance, which actually goes into detail, if you’re using HTML, here’s some of the ways in which you could achieve this success criterion, and then you can test against those, but the techniques document is only informative, it’s not the be-all and end-all. You could follow whatever’s said in there, or you could actually come up with something that’s completely separate, is not mentioned anywhere in the techniques, but if the end result of an actual real user is still, OK, they can still bypass blocks of text that way, then that’s fine.
Paul: Which is great, because it kind of gives people the freedom to innovate and come up with original ways of solving accessibility problems.
Patrick: Absolutely, and it puts…it puts the focus straight back on doing something that is good for the user, rather than right, we’re just going to go and make sure that we tick that particular box because the guideline says we need to do X in HTML and, well, we’ve done it, so we’re cool. This kind of forces you to actually think about solutions. I mean you can… you can go into the techniques document, and what’s mentioned in the techniques document, is pretty much they’re tried and tested ways in which that situation has been solved, so you know, you can be I’ll say lazy, but you know, you can get guidance from that techniques document, but that’s the important thing to know, is it doesn’t mean that you have to necessarily use one of those techniques, and absolutely you’re right, this will stimulate a lot more creative kind of ways in which these success criteria can actually be met. And as I said, it then applies to any technology. You could say, right I’m going to provide that functionality in Flash if I’m doing Flash, or maybe I need to do that in PDF, or whatever, so it is a lot more open. Which obviously is a problem if you’re very set in the ways of I’m going to run it through a validator, and I’m going to get a clear yes or no answer, because you pretty much need either a lot of user testing to say, OK are the users actually able to do this particular thing that the success criterion says, or you get experts that kind of help you with that, and there it’s a lot more likely that you’re going to get 2 or 3 experts and they might not necessarily agree on what’s the best way to implement something, so that is kind of…not the problem I would say, but the slight shift in mentality that website designers and website owners will have to make, that it’s less easy to make a very kind of cut and dried, yes it’s accessible, not it’s not accessible. I mean it was problematic before, now it could be even more woolly, which you know, is a bad thing in a way, but also a good thing because it does force you really to focus on the actual core of the problem rather than trying an easy way out and just implementing some mark-up that a guideline suggests.
Paul: Yeah, I mean yeah, I can see how it potentially might create some legal problems further down the line, but it certainly gets people beyond that kind of arse-covering check-box mentality, which has good to be good. So it sounds like a lot of the time we’re kind of going to be working as web designers on the success criteria level where we’re going through and making sure we conform with these various success criteria. What about priorities? WCAG1 had Priority A, AA, AAA or whatever you want to call it; Priority 1, Priority 2, Priority 3. I mean, did, you know, is there anything like that any more or has that gone away completely?
Patrick: No, that’s actually still there. At one point there was a bit of a change in terms of how it’s going to be worded, whether you could achieve full compliance or not by following…having to do all the success criteria for a particular level or not, but no, they’re pretty much there in their old form if you will, so it’s still called Level A, AA and AAA. One of the things that WCAG2 has tried to do in its wording of these Levels is to say that it wants to remove the kind of idea of hierarchy that AA aren’t less important than A, and AAA aren’t less important than AA. They’ve written a lot of nice words around it to explain why it’s actually still worth doing AAAs when you’re not fulfilling all of AA etc, but I think they’ve actually muddied up the waters a bit because in effect, you can’t claim, say, AAA, if you haven’t claimed AA, so the hierarchy is actually still there, so probably this explanation was quite confused, but it actually reflects exactly how confused the WCAG2 document is about that. They’ve tried to kind of have their cake and eat it at the same time, I think, because they have to…necessarily have some hierarchy, but they’re really trying to stress that they’re all equally important, you know, but some are just more important than others. So…interesting.
Paul: Yes. So I mean what, you know, we’ve got potentially, you know, if you’re right, until about Christmas to sort out our act and to kind of really get thinking about WCAG2. What kind of steps would you recommend for people that are owning and running websites in order to kind of prepare for this?
Patrick: I would say that because WCAG2, as I say, is a whole suite of documents, you’ve got the actual guidelines which I mean now I can read them and they’re quite understandable to me, but I’m obviously very close to the subject at hand. I can kind of understand where they’re coming from. But as part of the suite of documents, there are kind of better documents possibly to start with, depending on what your current level is. There are ….there are simple things like Understanding WCAG2, which kind of takes a helicopter view of WCAG2 and gives a lot more context that explains why, you know, certain guidelines are important, how, you know, people will use them, how they will benefit from them etc. It goes more of a context. It’s obviously a lot weightier than the actual core guidelines, but that is…if you’re a bit rusty with, you know, I haven’t looked at WCAG2 at all, you’re a bit rusty with what WCAG1 even was about, beyond just being a document that you checked some boxes against, that’s certainly worth reading, just to really get a feel of understanding why….why are we changing things, why wasn’t WCAG1 good enough, so that really gives you a good kind of introduction to the subject. And I think that’s an important step towards actually implementing WCAG2 would be for people to buy in, as with anything, if you’re trying to push it through at an organisational level. People need to understand the rationale behind it. You can’t just dump this document on say your developer’s desk and say, right, these are the new rules, you know, white is black, black is white, this is what you need to do now. They need to buy in from actually understanding what the rationale behind it is, so the understanding document will really give them all the information they need. Some, you know, technically minded people might be tempted to jump straight to the techniques document, which is fine, but again with the caveat that I mentioned before that the techniques document is actually only informative, so whatever’s written in there is not the law. Some techniques that are currently in there might even be proven later on to be maybe not optimal in certain situations etc, so it’s not the law; it can help you initially get, if you’re really technically minded, you might read the success criteria and say, yeah, OK, that’s all nice language, but what does it actually mean, you know, if I’m doing HTML, what….what are you expecting me to do? The techniques document can help, it will give you actual examples. If you’re using HTML do this, if you’re using Flash do that, etc, so it brings it back down to something that as a techie, you might be more comfortable with, but again, understand
ing that that is not the law; those are not the guidelines, and that there might be even better or more creative ways around the problems, but it’ll get you into the right frame of mind I would say.
Paul: Cool
Patrick: There’s also documentation that just pretty much compares WCAG2 to WCAG1,
Paul: Ah, that’s good
Patrick: Yeah, if you’ve got a lot of experience with WCAG1, that will kind of help you roughly map, you know, what used to be WCAG1’s check-point about this, is now this far broader guideline that covers a lot more aspects, so it’ll help you kind of move towards the thinking behind WCAG2. And I think that is the main thing as a website owner or as a designer; it’s more of a shift in perception if you will, more of a shift of understanding of what accessibility is, more than, you know, the change of how is my mark-up now going to be affected by it. It’s really moving beyond that kind of very HTML specific, you must do exactly this, to a more, you need to understand how users actually use your website and how to creatively kindly of help them in that pursuit really.
Paul: Cool. I mean that sounds good; there’s lots of different ways you can kind of start the process of learning it
Patrick: Absolutely
Paul: …which is good. I mean I guess my last question, you’ve almost kind of answered, which is, you know, if you’re somebody from a WCAG1 background that is comfortable with WCAG1, the one thing that you’re thinking is, hang on a minute, I kind of knew this, I had my head around this, you know, I’ve suddenly got to change to this new system, you know, is it going to involve more work, is it going to be painful? The fact that you’ve talked about this document that does transition, you know, between WCAG1 and WCAG2 sounds helpful. Overall, do you think it’s going to put more pressure on designers or is…more going to be expected of them as they develop stuff?
Patrick: I think it’s going to be interesting for a variety of reasons. I wouldn’t say necessarily there’s going to be more work involved. If you’ve been working similar to the way I’ve been working, that you take WCAG1, you take what you want from it, and you filter it through your knowledge of, yeah, that screen-readers can actually work well with PDFs, so I’m ignoring the non-W3C technologies I’ve banned that used to be in WCAG1, so if you’ve actually been doing accessibility based on WCAG1 in the real world rather than simply just following it as a set of check-points that you just tick the boxes, I wouldn’t say it’s going to be more work. Certainly if on the other hand, if you have been somebody who hasn’t been too understanding or involved with WCAG, you pretty much had it as a function in your, say, Dream…copy of Dreamweaver or whatever, I’ll just quickly run it through this validator, I’ll run it through Bobby, although Bobby’s now gone, thank God, various things like that, you know, if you really just saw it as a check-box exercise, yes there will be…it will be more of….I don’t want to say paradigm shift…well there you go, I just said it….absolutely, no cliché will be left unturned in this particular episode…you really need to start understanding it more. But if you’ve actually been doing what I would term in a quite elitist way, real web accessibility over the last few years, there’s no major, major big surprises there, and there’s…I wouldn’t say there’s a lot more work involved. Now it would be interesting, I think, one of the aspects will be if you’ve been working in an organisation and you’ve been trying to appease management say, and one of the things that management might have erroneously picked up is, we need to make sure our pages are Bobby-compliant, for instance, is that will be a difficult, I would say, or challenging, should we say, situation because you will have, already at the time you might have been crying, saying, well, the validator can’t check everything, you still need to do manual checks, but at the end of the day, some managers, all they wanted was to see the thumbs up and the smiling policeman with the helmet on their website. This time around it will be a lot more difficult, and yes, as I mentioned before, there will be automated tools that will help you in determining whether you’re doing certain things right according to WCAG2, but because, as I said, the techniques…there is no definitive list of techniques that are OK, and there are no definitive lists of techniques that aren’t OK, it’s practically impossible to write an automated checker that will be able to check against everything, so tools…automated tools will really just be relegated to certain interpretations of WCAG2. I know that there’s a few organisations in the States that are currently working on, you know, validators. I think the….name escapes me now, but the Fraunhofer Institute in Germany, they’re currently working on their own version of a WCAG2 accessibility tester for instance, and I had an interesting discussion with representatives from Fraunhofer the other week when I was in Germany at a conference, and they’d pretty much agreed that their tool will only check against, basically, their favourite techniques if you will, from the techniques document. Now who’s to say, as we said before, that those are the best techniques? They’re ours. You might come up with a really creative way that no tool has been primed to kind of sniff out in your mark-up or in your Flash or PDF or whatever, so you’ll always get a very, very subjective, based on what the developer’s written into their tool, very subjective assessment of your website, so bring it back to the point, it will be extremely difficult I think for a manager to be able to say, right, I just want to make sure that we pass that particular test, unless you then go and dig out exactly what that tool is looking for, and you end up back in the situation that we used to be in, where you’re trying to write it to get a good grade from a tool, rather than actually thinking about what is best for, you know, users with disabilities or users in general, so that, I think that will be the more challenging part, as I said, the paradigm shift, getting managers who might not have understood it up to now, to really kind of confront the fact that automated tools aren’t the be-all and end-all, and that yes, everything is a lot more subjective now, so really I would say the only solution to that is really start thinking more exclusively about proper user testing, getting actual end-users in there. You could give them the success criteria from WCAG2 and basically say, can you confirm that this is something that you can do on our website, so it becomes a lot less about automation and a lot more about actual end users.
Paul: Cool. I mean it all sounds really exciting, you know, a bit apprehensive, you know, a whole new thing to learn and all the rest of it, but I think the whole freedom of approach side of things, that you can approach problems in different ways and sold things in different
ways, is very refreshing and it all sounds really exciting. Patrick, thank you so much for coming on the show, that’s been really enlightening, and I look forward…
Patrick: a delight
Paul: Yes, and I look forward to getting you on again, maybe to get into some specifics once WCAG2 is up and running. Good to talk to you.
Patrick: Yes, super duper. Okey-doke.
Thanks to Alison “Anna’s Mum” Debenham for transcribing this interview.
Back to top
This fear undermines the power of wireframes. Wireframing should be about thinking out loud. It should involve throwing ideas out there and discussing different approaches. You should come away with a final set of wireframes borne out of many iterations and approaches.
