If you can’t be bothered to do either of those things, you might instead want to have a quick glance at the things which struck me as interesting…

• The survey had 665 valid responses
• Only 4.7% described themselves as beginners with screen reader technology (but as they point out, we shouldn’t draw inferences from this, because there is no way of knowing if this survey sample is fully representative — which we also need to bear in mind when looking at the other results)
• JAWS is the primary screen reader for most (2/3 of correspondents) but 5 other screen readers have shares over 1% so we can’t assume screen reader = JAWS
• 83% have updated their screen reader in the past year (but if the survey sample is artificially tech-savvy, this might be artificially high also)
• When asked which browser was used with their primary reader, the top four, in order, were IE8, IE7, Firefox 3, then IE6. It’s worth noting that the IE6 percentage is significantly lower than reported by most site analytics, although it’s difficult to tell whether this relates to screen reader requirements or sample selection
• More than 74% of users report that javascript is not disabled in their browser, with almost 15% don’t know. Is javascript still the big bogeyman barrier suggested by WCAG 1.0?
• There’s something very interesting about alt text. I’ve always been working on the assumption — long backed up by other professionals — that screen reader users would prefer to have decorative images to have a null alt text so that they would be ignored by the screen reader. It would instead appear that over 75% would prefer either “smiling lady” or “photo of smiling lady” to indicate such an image (of a smiling lady). Not particularly convinced this result should see a change in best practice however — but I’m open to persuasion if this is what people want…
• The most problematic three items were CAPTCHA (presumably particularly those which are visual-only), Flash, and ambiguous links. Looks like another vote for the end of ‘click here’ as well as a reminder to all those companies who produce inaccessible flash-only versions that they are causing accessibility problems
• …in comparison, lack of ‘skip’ links doesn’t seem to bother many people
• Social media use seems to be (mostly) tied in with perceived accessibility, with the most used social media tool (YouTube) being seen as at least ‘somewhat accessible’ by 78% of people (although not the highest), and the least used (MySpace) reporting the least accessible (assuming that the graph is correct, and not the figures, which were wildly out of whack with the graph at the time I put this together). MySpace, which is least used, is reported as one of the most accessible; some of the most used are reported as the most accessible, so there does not appear to be a direct link between accessibility and use, . This information would be better presented in next years survey as a % difference between screen reader users and users in general — as it would be more possible to draw comparisons as we could see differences in trends: it’s impossible to know to what extent (if any) these percentages are affected by accessibility without knowing the % use in the general population
• In short, there is no “typical” screen reader user.

On his Muck&Brass blog, resident Niall Connolly has called members “jackasses” and claimed a council leaflet was “like a Nazi call to arms”.

Former vice chairman Anthony Canvin, 61, said: “There’s some sick, stupid people out there.”

BBC News

My first thought was wow. Not wow as in “hurrah”, but wow as in “cripes, I’m a bit surprised at that”. At this stage, I’d not actually read anything of Niall’s Muck and Brass blog. I’d heard about it on the BBC. (Mainstream Media 1, Blogger 0)

Reaction

But I was a bit surprised at this response by Jim Hawkins, who has in the past been critical of blogging, suggesting that it does not have as much value as proper journalism…

@ThePickards Regardless, it’s a shame. One whining anonymous critic takes down most of a council but doesn’t have guts to stand for electionJimInTheMorning

…this instinctive “blogger must be wrong” response struck me as sadly typical of mainstream media (except in regard to Iain Dale who turns up bloody everywhere), and — and I hope Jim will forgive me for highlighting his mistake hiere — shows that even mainstream journalists aren’t always 100% accurate in checking their sources, since both the BBC article (which Jim retweeted) and the blog itself named the author as Niall Connolly.

Jim’s counter — that we can’t be sure he actually is Niall, since the BBC haven’t managed to contact him today — seems a weak argument since he appears to have been blogging since 2006 without anyone questioning his identity before. Besides which, before assuming someone’s identity is fraudulent, it might seem reasonable to check them out: and since the person claiming to be N. Connolly has in his possession a photo of a franked envelope sent to N. Connolly (publicly available on his blog for anyone to spot), it would seem a little perverse to be suggesting he isn’t…

Is It Right To Criticise?

The other question is of course whether or not it is “a shame for democracy”. There’s a perfectly simple answer to this. Or rather there are maybe two. And these are “No, it isn’t”, and “It depends”.

The fundamental question to the “no it isn’t” camp is whether we, as individuals, as bloggers, as private citizens, in the media or not, anonymous or not, have a right to criticise our elected representatives. My vote would be a clear and unequivocal yes: with of course the caveat that if you’ve been telling stuff which turns out not to be true, you have to pay the penalty (as Damien McBride and The Sun have found out recently).

That’s my personal belief: we all have a right to be critical of our elected representatives. And, in theory, we should be allowed also to sing their praises should such a situation ever arise.

If you’re not convinced on this, then maybe you’ll fall into the second camp: “it depends”. This camp would suggest that hang on, if the guy’s criticisms are reasonable, then maybe he is right to be critical: if he’s being unreasonable, then no.

Surely everyone would agree with these two being the only reasonable camps: after all, the only other possibility is that your elected representative can do whatever the hell they like and you’d be the one in the wrong if you were to say anything about it.

Challenge The Media

So what has Niall actually had to say? Have any of the journalists (and let’s just watch today’s papers to see) actually read his blog before drawing their conclusions? Well, this is where it might just get interesting…

There are, at the time of writing, only eighty-five posts on the blog, so while it might take a little effort, it’s certainly possible to at least skim the posts and pick out the relevant ones. (And read some half dozen of the council minutes too)

So I have done. As I say, if the story is picked up by other sources tomorrow, let’s see which “proper” journalists have done the same (and without “coincidentally” picking up on exactly the same points as me)…

What’s The Story?

In 2006, there’s no real vitriol only a few references to the council, one of which simply states that the age profile of the town is somewhat elderly, and the makeup of the town council reinforces this profile. There are a few references to the Somerton Town Plan of 1977 — isn’t it right that someone is taking an interest like this? — and then he ponders whether the council are doing enough to engage with the community.

I don’t know if anyone at the meeting was under forty but it certainly didn’t look like it. So where is the wider community? Clearly they don’t get involved and its useful to ask why not? Maybe the very nature of ‘local politics’, certainly as they are pursued in Somerton, just turns people off.

I can’t think of any situation where — assuming the comment to be true — a Council wouldn’t seek to determine why this should be the case and try and engage with younger people. If he’s wrong, or the council were engaging with the youth in other ways, then surely it’s simple enough to say so.

Of course, the bigger question seems to be whether or not things are going through proper channels:

It was proposed to the meeting that Tony Canvin, the well known builder and local and district councillor, would use his ‘buying power’ to negotiate the best deals. It was proposed that there would be no tendering evidently because tendering is a tedious process which doesn’t offer any benefit.

This strikes me as seeming a bit unusual. I would have thought that tendering for deals would be a requirement, and that anyone who was a local builder should have to declare their interest at this point, and then have no further part in the process.

Reasonableness

And then you’ve got the questions of whether the criticisms are reasonable:

Somerton’s dominance in the Precept League is again underscored when you consider the average Precept charged by the 121 Town Councils in South Somerset. The average Precept charged per property across those Councils is a paltry £24.85p and Somerton exceeds that by close to 400%.

Now assuming these figures are accurate — and I’d presume these figures are, by nature, publicly available, so anyone can check — then surely it’s not unreasonable to ask why you’re paying four times more per head for your town council than those residents of other councils. Is this not a reasonable question? And here I’ll introduce some of my research:

Somerton’s plans for 2007-08 showed that it was expected that there would be a shortfall of £40,000, which would have to be met from reserves. Of course, when it came to the 2008-09 prediction, there were revised figures for 2007-08 which showed that the council didn’t make a loss of forty thousand at all. It would appear that they actually spent — with an income of around £275,000 (including £220,000 precept) more than one million pounds more than their income.

Not only is this a rather spectacular amount — particularly as the next highest amount which needed to be paid from any of the other town council balances was less than seven thousand, it’s also around 25 times greater than the council expected.

I think it’s perfectly appropriate for anyone to question why this should be the case… Blogger 1, Mainstream Media 1

Accuracy and Correction

Then there’s the question of whether a blogger is allowed to say things he knows to be factually inaccurate. Would a blogger who wasn’t honest and decent allow something inaccurate to stand, would they quietly drop the allegation (as I’m sure has been done before) without actually publishing a clear retraction, or would they publish a clear correction? Let’s look at Niall:

On the 14th October an anonymous comment was posted to Muck&Brass suggesting a connection between Wild Meadow Farm and Hawthorns SW. Muck&Brass has been assured that there is no financial connection between these two companies. Muck&Brass: Correction

Note, this isn’t retracting an allegation he has made, this is correcting an allegation an anonymous source made during the comments. If only the media published their corrections, retractions and apologies on their front pages…

Not only that, but you also have this:

Recently this blog has received a number of comments which have not been published because they contain information which cannot be verified. I would ask those contributors to contact me directly in order that I might learn more about the issues that they raise.Muck & Brass: Request for Information

Blogger 2, Mainstream Media 1.

The Lone Nut Theory

Next, I’ll look at the implication that the blogger is a lone nut: as with the JFK Walnut commission investigation. What about other sources? Do other people agree with these sort of views? Well, yes…

Terry Bastyan, speaking on behalf of residents living in the Badgers Cross Lane, said: “We feel let down by the council because you are supposed to be representing us. “The only reason all these people are here is because two of us found out and let everyone know. “We fully support recycling, but question the need to move from the current site.”

The current site is owned by Somerset County Council and managed by Viridor. The proposed new site is a disused quarry owned by Mr Canvin.

This Is Somerset

Does this seem to then be a lone voice? Well, no… (look at the local election results also — which also demonstrates that if he didn’t stand for election, he was actively involved in the process).

Blogger 3, Mainstream Media 1

Is There A Case To Answer?

But of more import seems to be the activities of one Councillor Tony Canvin, who has been the one at whom most of Muck&Brass’s vitriol appears to be aimed at. Is he being unfair and just picking on the poor man? Or does he have a point? Well, let’s take a look…

A proposal to relocate Somerton Household Waste Recycling Centre from Bancombe Road Trading Estate to Badgers Cross Lane has been submitted by Tony Canvin.This Is Somerset [2]

Okay, then, if we were to work on the assumption that what is in these articles is accurate (it has been produced by “proper” journalists, after all), doesn’t anyone else think that it is inappropriate for a councillor to submit a proposal for the council to move one of their centres to some land he himself owns? I’m not saying it’s against the rules — I don’t know the rules — but as with MPs expenses, it’s one of those things where my opinion is that if it isn’t against the rules, it ought to be.

M&B has received a number of emails regarding a ‘new’ planning application which seeks permission for an amenity site out at Badger’s Cross. This development will effect everyone in Somerton and has been rumoured for over a year yet it has not been discussed by Somerton Town Council and it is fair to ask, ‘Why not?’.

This application comes from none other than ‘Mr Somerton’ himself, Tony Canvin (aka Cllr Canvin) …

Muck & Brass: It’s That Damn Badger Again

Niall also makes a sound point that leaving a meeting for five minutes here and there does not necessarily mean that there is no conflict of interest:

Obviously the applicant’s consultants were quick to point out that, in a situation such as this, where the applicant faces possible accusations of ‘conflict of interest’, the applicant would leave a Council Meeting whilst their application was being discussed. But the community is beginning to appreciate that the issue is not the relatively short period of time when the application is being considered that is under scrutiny. Under scrutiny is the far longer period of time, possible a year or 18 months before the application is made, when the applicant can use their extensive access to the process to prepare their position. In the face of this advantage, the community is starting to feel abused.Muck & Brass: Shaved Heads and Earrings

Now, I don’t know whether there is anything actually wrong in all of this, but to me it poses an interesting question — the council may well have resigned en masse because of criticism from a blogger, but the question should be posed (and of course answered by the council, and former members, where appropriate) as to whether that criticism was justified. If so, then perhaps they have been forced to resign through their own actions, rather than because of blaming one blogger.

And of course this is before we look at other claims: councillors shredded a letter of questions sent out to them and sent the shredded bits back; suggestions of intimidation and vandalism and so on…

Blogger 4, Mainstream Media 1

Money Where Mouth Is?

And it appears Mr. Connolly has been prepared also to put his money where his mouth is…

Whether the wider community agrees or disagrees with the views expressed in this blog, the information provided to the External Auditor is all based upon fact, backed with documentary evidence. In the light of that evidence, I believe that the community of Somerton has been very badly let down by its Town Council and its Town Clerk.Muck & Brass: Thank You

Of course, I’m not claiming to know what the facts of the case actually are. That’s why I’d like to see Somerton Town Council — and former councillors — put their side of the story. My personal opinion is that it would be appropriate for some outside and independent agency to investigate these claims and stories and report publicly whether or not any wrongdoing has taken place, and either clear the name of the councillors, or take whatever other action may be appropriate.

However, I would suggest that those people who immediately assumed that the council was in the right have obviously not looked into the allegations which I think suggest there is a case to answer. For those of you who judged someone before knowing the facts (which, admittedly, I still don’t know — that’s why I suggested an external, independent, public investigation) — shame on you.

Blogger 5, Mainstream Media 1

Summary

To sum up though, I hope Jim will forgive me, but his thoughts — democracy is the loser, anonymous, whining blogger — and so on, seem very much to be a case of “kneejerk reaction first, establish facts later”. Which is strange, because that lack of attention to the facts, and the lack of investigative reporting (such as that carried out by Niall), is always something that the mainstream media seem to criticise bloggers for.

Perhaps this is simply proof that bloggers can be better, after all; perhaps there is still a place for the independent crusader and local resident to actually make an impact on local politics. Perhaps local government ought to be accountable to its residents. Perhaps people shouldn’t jump to conclusions just because they are biased against bloggers.

…or perhaps all of the allegations and suggestions are false. I don’t know, and because I don’t know, I didn’t jump to conclusions based on prior bias, and that is rather the point.

I don’t really have a problem with the use of acronyms, provided that they are expanded (whether via HTML or in text) on at least their first use in a given page or message. What I do object to however is the assumption that if you use an acronym or abbreviation, other people will understand what you mean, and if not, they can always look it up.

Well, no. If you can’t be bothered to make your message sufficiently clear in the first place, I don’t see why I should bother to dig around trying to figure out what you are trying to say. And sadly, I find that the accessibility community are one of the worst when it comes to this.

The idea of accessibility is to make websites (or other things) more easily usable by people, most frequently specifically “people who are disabled”. This is emphatically not just about using alt tags (note: always call them tags, it annoys the purists). Accessibility is not just about the blind.

If you want to make your sites accessible, you need to consider other impairments: motor impairments — users who can’t use a mouse; hearing impairments; other visual impairments; dyslexia and other cognitive impairments and so on. And he we come to something which is a cross-over between general good practice and accessibility — the ease with which your content can be understood.

Obviously cognitive impairment is not a binary position: it reflects a continuum of impairment. You can understand therefore that if your page is slightly easier to understand, this will tip the balance for some people between being able to use it and not.

And this is where we come to the counter-intuitive a11y abbreviation. It looks like “ally” (and many pronounce it as such), but it means something entirely different. It means “accessibility”. How on earth do you get from “a11y” to “accessibility”, you may well ask. Ahah! Here’s the clever bit (or, in my opinion, the bloody ridiculous bit).

What you do is you look at the number of letters between the first “a” and the final “y”. You’ll find there are 11 of them. So you scoop all of those out and replace them with the number 11. You’ll also see this in i18n and similar. They are the sort of abbreviation which are completely and utterly obscure and opaque to anyone not already “in the know”.

As far as accessibility goes — something which is supposed to promote understanding — the use of a11y is therefore very clearly b6s.

I understand that there is a need sometimes (for example when on twitter) to use an abbreviation, as accessibility is quite a long word. But any abbreviation used should be one from which the word “accessibility” can be reasonably inferred without esoteric knowledge.

One possible suggestion would be to use the abbreviation “access” (6 letters). It’s significantly clearer than “a11y” (4 letters) and significantly shorter than “accessibility” (13 letters). It does have one drawback in that people frequently use “access” (particularly on twitter) to refer to Microsoft Access databases.

So there’s two questions.

1. Do you agree that a11y is a poor abbreviation for accessibility, and we ought to use something better?
2. What should we use instead (and why)?

My personal belief (after having looked around on twitter) is that #access might clash too much with other things, so a different option may be preferable; but also that #access is preferable to #a11y. But can we come up with something that is better than both of them?

I don’t really think we should be looking at something specifically related to the web, as people might want to use an equivalent tag to mark accessibility in other software (or in a non-IT capacity).

So let’s have your thoughts on the following, and any others you can come up with:

• #a11y
• #access
• #accessibility
• #accessy
• #disability
• #disacc
• #webacc

It is mandatory for Government sites to have stats audits:

In the current climate of open, transparent and accountable government, it is now mandatory for government websites to have stats audits.Adam Bailin, Digigov: Benefits of Government Website Auditing

Now there are various different ways to analyse the stats, but in order to identify unique visitors, a lot of stats thingummies will use the storing of cookies. You with me so far?

Now the EU are currently discussing exactly what to do over file-sharing. Part of this telecoms package includes this:

Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his/her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia about the purposes of the processingElectronic communications networks, personal data and the protection of privacy

Note that: in order to store or access a cookie, the user must already have given consent. This is not the same as the current “right to refuse” which means (as I understand it) that you’ve got to include information about what the information is used for and how the user can opt out (such as by having a ‘privacy’ page with this information linked to at the bottom of your site).

Struan from Out-Law.com was fairly clear on what he believes it means. You must provide a notice and give the user the option of giving or declining their consent before setting or accessing a cookie, with only one limited exception:

There is an exception for cookies that are “strictly necessary” to provide a service “explicitly requested” by the user. Consequently, no cookie notices are required to serve a cookie that helps a shopper get from a product page to a checkout; but notices are required for cookies that are used in traffic analysis or advertising.[...]

[...]sites can deliver cookies to a user’s computer only if the user “has given his/her consent, having been provided with clear and comprehensive information” unless, as now, the cookie is “strictly necessary” for a service “explicitly requested”.

European Commissioner Viviane Reding expressed concerns about behavioural advertising this month. “European privacy rules are crystal clear: a person’s information can only be used with their prior consent,” she said.

Out-Law.com: Online advertising is threatened by Europe’s cookie law

So if you want to use cookies for advertising (not a major thing for UK public sector sites at the moment, but people are heading down that road) or use cookies for analytical reasons, you must first give people the opportunity to decline first. That’s an active thing: you must explicitly get their consent (as I understand, for every different cookie, as you’ve got to explain what the information will be used for).

What right to refuse did I get?” our source asks of his own visit to a homepage placing a selection of cookies on his computer. “You might imagine some sort of pop-up: ‘do you refuse this – yes / no’. You could phrase that many ways but it seems to me you need to ask for a reaction before storing or gaining access to a machine.” Can you imagine a pop-up box to explain 30 cookies, or 30 pop-up boxes? [more from] Out-Law.com: Online advertising is threatened by Europe’s cookie law

And of course if you are a public sector site, you need to comply with either WCAG 1.0 or 2.0, so you simply can’t do this. WCAG 1.0 says:

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

WCAG 2.0 is a teensy bit different. You’re not allowed to cause a “change of context” (new windows, change of focus, change of content of text on the page) unless you have informed the user first. This includes when any component receives focus (such as opening a new page):

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)WCAG 2.0 Success Criterion 3.2.1

…or when you change anything on the page…

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)WCAG 2.0 Success Criterion 3.2.2

That is, every time you want to set or access a cookie, you’d need to inform the user before you pop up a window (or change the text on the current page) to ask the user if they will allow you to set or access that particular cookie.

So on the one hand you must inform the user what you will use the cookie for — and allow them the chance to withhold permission for it — before you set any cookies; and on the other hand, you can’t have any popups asking about setting cookies unless you’ve already informed the user first.

In other words, every time a user starts a new “visit” to the site (whatever their “landing” page was intended to be) you are going to have to:

• Take them to a page (or series of pages) which explains all the cookies they are likely to encounter on your site and ask their permission to set them (except for cookies essential to the user-initiated process, such as shopping baskets)
• Ensure that these permissions are recorded and stored for the remainder of that visit
• Then take the user to the page that they originally wanted to visit

I can foresee a couple of teensy problems. Firstly, if you don’t do this, you’ll be breaching EU law (?) — assuming the current telecoms bill is passed — or alternatively you can instead choose to breach accessibility requirements. On the other hand, if you do do this, you’re going to massively inconvenience, not to mention severely piss off all of your users.

And of course that’s before we start trying to work out what constitutes a new ‘visit’ for someone who has refused to allow you to set cookies…

So, in line with Struan’s objections, I’d suggest that we hope that (and maybe do what we can to help) the new telecoms bill is not passed…

I’m looking at what parts of WCAG 2.0 that I think are appropriate to set as a minimum standard for public sector sites in the UK. Personally, I think there are three key points that need to be considered.

• Public sector organisations come in a variety of shapes and sizes, and aren’t just Local Authorities and central government departments. Is it appropriate to demand that all public sector sites should have the same level of compliance?
• We need to ensure that all public sector sites achieve a level of accessibility that is achievable and where it is not unreasonable to apply sanctions (of whatever type) if an organisation fails to meet the required level. Currently, too many sites fail to achieve the required standard: is this a problem with the sites, or is it a problem with the standard against which they are measured?
• We need to ensure that public sector sites are not discriminating against people with disabilities: all sites should be required to have at least a basic level of accessibility.

Comparison against WCAG 1.0?

So, taking these three points as my starting criteria, and looking at WCAG 2.0, and comparing it to the previous mandated standard — WCAG 1.0 at the Double-A level — what do I notice?

Firstly, I notice that there are a different number of criteria. To achieve WCAG 1.0 at the most basic level, we need to pass 16 criteria. To achieve the same against WCAG 2.0, we must pass twenty-five. Does this mean WCAG 2.0 is more stringent, and tougher to pass? Well, that’s something we need to consider — although the Double-A level of WCAG 2.0 only has 13 criteria compared to 30 for WCAG 1.0. Could we argue that with 46 tests on one site and 38 on the other, the two are roughly equivalent?

Well no, not really. Unfortunately it’s not as simple as that. WCAG 2.0 represents such a significant culture shift from WCAG 1.0 that in attempting to determine a suitable conformance level it does not make any practical sense to include WCAG 1.0 as a comparison. Instead, we’ve just got to look at WCAG 2.0 and see what we think is appropriate.

Accessibility Supported

The idea of what is an accessibility supported technology could be one of the most problematic features of WCAG 2.0, but — if you’ll indulge me for a moment first — I hope to be able to come up with a relatively simple answer. First, it’s important to remember that you must only rely on accessibility supported technologies:

Accessibility Supported

Using a technology in a way that is accessibility supported means that it works with assistive technologies (AT) and the accessibility features of operating systems, browsers, and other user agents. Technology features can only be relied upon to conform to WCAG 2.0 success criteria if they are used in a way that is “accessibility supported”. Technology features can be used in ways that are not accessibility supported (do not work with assistive technologies, etc.) as long as they are not relied upon to conform to any success criterion

WCAG 2.0

Right. That’s the “quick and simple” definition. Of course, you’ll be wondering what the full explanation looks like, if that’s the quick and simple one. So here is the more complicated bit — how do we determine whether or not a technology counts as accessibility-supported.

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

1. The way that the Web content technology is used must be supported by users’ assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users’ assistive technology in the human language(s) of the content, AND
2. The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:
   1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS); OR
   2. The technology is supported in a widely-distributed plug-in that is also accessibility supported; OR
   3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported; OR
   4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:
      • does not cost a person with a disability any more than a person without a disability and
      • is as easy to find and obtain for a person with a disability as it is for a person without disabilities

Note 1: The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported

WCAG 2.0: Accessibility Supported

Right-ho. This bit looks complicated, but let’s break it down. To qualify as an accessibility-supported technology, the technology must be freely available, and either free or the accessibility-supported agents don’t cost more than the standard ones, and that particular use of technology has been tested for accessibility support.

Note also the note: the W3C aren’t going to tell us which technologies count as accessibility supported, this is something we’re going to have to work out on our own. And it will change over time.

So where start? HTML and CSS, obviously. Javascript? We’ll come back to that one. Flash and PDFs? Well, I’d say so: assistive technology can handle these pretty well, just so long as they have been put together in an accessible manner. You can’t just slap it on the web and assume it’s fine. But if you build it properly, it should be.

So that’s HTML, CSS, Flash and PDF I’d allow. What the COI need to do is to state which technologies are appropriate for public sector sites. Someone needs to take on this responsibility for UK public sector sites, and I think the COI is yer man.

Is Javascript Accessibility Supported?

Well, some bits are. And some bits aren’t.

And now I’ll look at Javascript. For Javascript, I’d allow use of particular pieces of javascript, where that particular script/command has been checked and documented as being accessible. For this, I think it would be useful for someone (the COI again?) to keep a list of javascript commands and techniques which have been found to work with assistive technologies: if someone wants to do the testing for an additional bit, and make their documentation available to the COI, then it gets added.

I think the time has come to accept that Javascript does not necessarily make a site inaccessible, and that sites can rely on javascript and still meet accessibility requirements — provided that script has been tested as being accessible. The most obvious example of this for me is that javascript which is ubiquitous within .NET sites — the javascript postback.

When working for a Local Authority, I ended up in a discussion with Microsoft about this who seemed quite content that this technology was accessible (and my test case, which I got screen reader users to look at, seemed to confirm this), but that obviously Local Authorities couldn’t use it, because under the current rules they were not allowed to rely on javascript — despite this javascript being tested and accessible.

This is obviously nonsense. Which is why I think we need to take a more complex view with javascript: let’s record accessible uses of javascript, and then people can use these. If they want to use something not already recorded, they have to carry out the testing and prove that it’s accessible.

Conformance Claims

…are optional, but if you do want to include them, they need to be made in a very specific way. This is not a case of sticking one of those accessibility badges on your site. You’ve got to provide much more information than this. Indeed, if you do venture to stick an accessibility badge on your page then this is deemed a conformance claim, and it must be accompanied by all the other necessary information.

So I’d suggest that public sector organisations are discouraged from including conformance claims. If they want to include some sort of information, a description of what testing they have carried out (and who with) may be may appropriate, but I tend to think this sort of thing is of no benefit — it’s self congratulatory backslapping only: describing what you’ve done does not in itself make the site more accessible, and you ought to be doing it because it’s right, not because you want to claim some credit for it and feel smug or superior.

Success Criteria: Perceivable

Criteria in this section:

• Provide an equivalent text alternative for non-text content (Level A)
• Provide an alternative for pre-recorded audio or video except where the media is a media alternative to text. If the media is time-based, the time information must be associated with it.(Level A)
• Provide captions for pre-recorded audio, except where the audio is a media alternative to text (Level A)
• An alternative for time-based media or audio description of prerecorded video is provided for synchronized media, except when the media is a media alternative for text and is labeled as such (Level A)
• Information, structure, and relationships conveyed through presentation can be programmatically determined (use headers, lists and so on properly) (Level A)
• When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined (Level A)
• Instructions provided for understanding and operating content do not rely solely on sensory characteristics (don’t say “fill in the fields with a circle next to them”, “put your answer in the box to the left only”) (Level A)
• Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
• If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)
• Captions are provided for all live audio content (Level AA)
• Audio description is provided for all prerecorded video content in synchronized media (Level AA)
• The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 (except logos, decoration etc) (Level AA)
• Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality (Level AA)
• If text can be used to supply the visual presentation of the information, text is used to supply the information, unless it’s essential to be presented in a particular way (e.g. a logo) or the image can be customised by the user (Level AA)

All perfectly reasonable (bar maybe one, but I’ll come to that). I’m also delighted to see that you can’t have constant jangling background audio (not that you tend to find that in the public sector, but it’s a personal bugbear of mine).

This “media alternative” is a key thing in this. Initially, these success criteria seem a little onerous: thou must providest captions and so on, but that isn’t really the case at all. The media alternative specifies that where the media provides no more information than is available in a standard text equivalent (transcript or so on), then that text equivalent is fine. So in many cases, you don’t need captions, audio descriptions or so on, provided that you have supplied a good enough text alternative to the media.

As regards level AA, I tend to think that if you’re sophisticated enough to have live streaming audio content, you ought to be sophisticated enough to put captions on it. This does however mean that you need to be careful when you’re considering putting video conferencing, or live council debates on your website — you have to have someone sticking captions on it.

The potential fly in the ointment is the second Double-A one: success criterion 1.2.5. This requires that any public sector organisation must provide audio description of video content even if all of the information that can be obtained from that video is also supplied in a text alternative.

I have to be totally honest here and accept that while having the information in text format is probably not quite as good as an audio equivalent, I feel that this puts an overly onerous burden on public sector sites to little practical benefit: the early success criterion demands that the text alternative contain all of the information in the video, and I would have thought that this should be sufficient.

For me, the accessibility standard ought to be set at a level where someone with a disability can carry out all of the tasks, and access all of the information on a site, but not at a level that requires public sector organisations to undertake specifically complex work for little benefit. The standard ought to be achievable and it ought to be reasonable. And for that reason, I would recommend that the COI do not include success criterion 1.2.5 as part of a level that is mandatory for public sector sites.

Other than this, I think the rest of the perceivability success criteria are perfectly reasonable and appropriate.

Success Criteria: Operable

And the operability criteria:

• All functionality of the content is operable through a keyboard interface (Level A)
• If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface (no keyboard trap) (Level A)
• For each time limit that is set by the content, it is either adjustable, extendable, switch-offable, essential to the activity, over 20 hours, or related to a real-time event (Level A)
• Moving, blinking, or auto-updating information that starts automatically can be stopped, paused, or otherwise adjusted (Level A)
• Pages do not contain anything that flashes more than three times in any one second, or flash below the general flash and red flash threshold (Level A)
• Provide a mechanism to skip navigation and similar repeated blocks (Level A)
• Use meaningful page titles (Level A)
• Focus order follows in a meaningful manner (Level A)
• The purpose of each link can be determined from the link plus surrounding context except where the purpose of the link is intended to be ambiguous to users in general. Like this one. (Level A)
• More than one way is available to locate a page except where it is the result of, or a step in, a process (i.e. provide navigation, search, site maps etc) (Level AA)
• Headings and labels describe topic or purpose (Level AA)
• Make the keyboard focus indicator is visible (in other words, use :active and :focus pseudoclasses as well as :hover) (Level AA)

“Public sector websites shouldn’t cause seizures” seems perfectly reasonable to me, as do the other criteria. I can’t see any reason why any public sector site should not be expected to achieve all of these things. Most of them are done anyway, and the ones which are not already standard across the public sector ought to be standard across the public sector.

The whole lot of these ought to be mandatory. None of them are difficult to achieve, all of them will impact on people with disabilities, there’s simply no excuse for non-compliance with this lot.

Success Criteria: Understandable

And the success criteria here…

• The default human language of each page can be programmatically determined. (Level A)
• When any component receives focus, it does not initiate a change of context. (Level A)
• Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component (Level A)
• If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)
• Labels or instructions are provided when content requires user input. (Level A)
• The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular (Level AA)
• Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated (Level AA)
• Components that have the same functionality within a set of pages are identified consistently (Level AA)
• If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
• For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
  • Submissions are reversible
  • Data entered by the user is checked for input errors and the user is provided an opportunity to correct them
  • A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission

There are a couple of things here which are worthy of note: I’ll skip over language as that’s easy enough to apply using the lang attribute or xml:lang depending on what and where you’re doing it, so instead I’ll stop at change of context. By this, it means that you shouldn’t change the on-screen content or send someone off to a new page unless they click a link or button or you’ve already told them this will happen.

A common example of this is drop-down lists which, upon selecting an option, immediately take you off to that selected option. The obvious problem with this is that if you’re using a screenreader, you may not know this is going to happen. For example, on the Redbridge i council site, if you change the drop-down selection in ‘view events of type’, it will automatically change the selection of events viewed underneath. This is done in a keyboard-accessible manner (it does change as you scroll through the list, which is a good start!) but obviously there is no on-screen warning that this will happen.

Again, it’s an easy enough fix: either provide specific instruction on what will happen, or add a submit type button.

Beyond this, the requirements are again fairly simple: provide meaningful error messages, give as much detail about the error as possible, and there’s also the key bit about submitting a page which performs some sort of update action. This is likely to be majorly beneficial to most users — it gives you a bit more confidence if you can double-check your details before you submit them — and is really not that difficult to achieve.

Again, there’s no real excuse for any public sector organisation not being able to hit these checkpoints. They don’t require anything special to achieve; they’ll benefit a wide variety of users and they should be considered good practice anyway.

Success Criteria: Robust

This is almost a little rump section: there’s not a great deal to it, as there are only two success criteria here…

• Markup parses successfully: elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique (Level A)
• For all user interface components the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A). This success criterion is primarily for authors who script their own components. Standard HTML controls already meet this success criterion when used according to specification.

As regards the second one, if you’re using HTML controls in the standard manner, you’re fine already. As regards the first, parsing isn’t exactly the same as validation — but anything which is valid HTML must parse ok. And as public sector organisations were previously expected to have valid code, successfully parsing code should already be in place.

Again, there’s no reason why any public sector sites shouldn’t be able to comply with these without any problem.

Success Criteria: Triple-A

So far, we’ve just looked at Single-A and Double-A success criteria, but are there also any Triple-A success criteria which we should expect to be mandatory for public sector sites?

No. There are a lot of different success criteria at the AAA level which would be useful to certain groups of people with disabilities, but these will generally only impact on smaller groups of users, will only be relevant in certain circumstances, or will add additional accessibility beyond the basic requirement.

For these reasons, I’d suggest that public sector organisations are encouraged to comply with as many of the AAA success criteria as is feasible for them to do so, but that these should not be mandatory.

However, there are certain things that I would particularly recommend, which I think are fairly easy to achieve and will generate real, practical benefit:

• Do not justify text
• Provide information about the users location within a set of pages (menus, breadcrumbs etc)
• Use section headings to organise the content
• Provide mechanisms for identifying unusual words, jargon, acronyms or abbreviations
• Use simple, plain English

In Summary, Then…

Other than 1.2.5 (provide audio description, irrespective of whether or not text equivalent is available), there are no success criteria at either level A or level AA which appear to be particularly difficult or unreasonable to expect them to be achieved. On this basis, I don’t feel that there is any need for different ‘levels’ of requirement depending upon the size of, or the resources available to, a specific public sector organisation.

I would therefore recommend that the COI set the required conformance level for WCAG 2.0 to be at the WCAG 2.0 Double-A level with the sole exception of 1.2.5, which I think may be unreasonable for some public sector organisations to achieve (this would still require equivalent text to be available with all of the information contained in the video, but it wouldn’t require a separate video with audio descriptions added). I think this would be a very reasonable, practical level of accessibility to expect, one which ought to be achievable for all public sector organisations, and one which should ensure that anyone who is disabled still has access to all of the information and functions provided.

I would be worried that any standard which required conformance against 1.2.5 would either see public sector sites ignoring the accessibility standard, or would see public sector sites simply choosing not to use video and multimedia, which is why I believe this, and this alone, needs to be removed from the requirement before we can set the rest of WCAG 2.0 at the Double-A level to be mandatory for the public sector.

I’d also recommend that the COI encourage compliance with Triple-A level success criteria, and in particular the ones I have listed above which I feel will provide the most benefit with the least effort, but let’s keep it simple, and just make these advisory only.

Having quite a bit of knowledge of accessible web design and in testing against it (feel free to contact me if you want a quote for a site audit, with recommendations for fixes, by the way!), I understand how difficult it is to achieve the triple-A level of accessibility conformance level for WCAG using either version 1.0 (1999) or version 2.0 (2008). I also know that “out-of-the-box” accessibility is impossible: you simply cannot achieve it unless your content editors also know and understand accessibility requirements.

Which was why I was more than a little surprised to see this tweet:

Redbridge AAA-rated for accessibility at the moment, built into the CMS. Immediacy, used by BBC for their Intranet. #digieng@72prufocks

My first reactions were “triple-A? bet it isn’t” and “built into the CMS? now I’m really convinced they don’t understand accessibility”. So, given that Redbridge i seems to be frequently lauded as an example of what local government should be doing, I thought I’d better take a look to see if it is accessible, or if it is likely to present any significant barriers to disabled users.

Whilst not proving the site inaccessible, the fact that the home page failed to validate was probably not a good start for a site which was allegedly claiming triple-A compliance, as it knocks that out of the water straight away…

And the short answer is that it isn’t accessible. Never mind the triple-A level of compliance, it fails to meet the single-A level of compliance for either WCAG 1.0 or WCAG 2.0. And of course if you’re not achieving even the single-A level of conformance:

A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document.WCAG 1.0: Priorities

I wouldn’t normally be quite so public about this criticism, but for the fact that Redbridge i appear to be claiming a conformance level they come nowhere near achieving, and for the fact it appears to be frequently held up as an exemplar of what public sector sites should be doing when it is in fact failing the disabled, and it is failing them badly.

It wasn’t even that I had to look far to find problems with Redbridge i. I managed to find enough failures on the home page alone to demonstrate that it does not achieve any WCAG conformance levels. Rather than go through every checkpoint and success criterion though, and the site in great detail (I’m not being paid to do that), I will instead walk you through how Redbridge fails different groups of users — and the checkpoint references appropriate, if you’d like to read on, Macduff…

Redbridge Fails: Visually Impaired Users

Firstly, there are visually impaired users. Now Redbridge does offer some useful things here: the accessibility page offers the user the chance to change the text size across (most of) the site, and to change the screen colours. This is a good thing, and it is something that is certainly not offered as standard across Local Authorities. Redbridge deserve credit for this.

But good intentions only go so far if they are not carried out well. For a start, Redbridge i is very script-heavy. I haven’t gone to the trouble to check whether every single piece of javascript works with every piece of assistive technology, which would mean that practically, and as far as WCAG 2.0 is concerned, this is okay. But if Redbridge want to claim conformance against WCAG 1.0, they need to ensure all functions (or equivalent functions) also work without javascript. And this is not the case.

Here’s an example of the Redbridge Jobs section, surely one of the most important parts of any Local Authority site. Assuming you have javascript enabled, you need simply change the value in the drop-down box, and it will pick up the jobs of this type automatically. Fantastic, eh?

Er, well, no actually. Here we’ve got a failure against WCAG 2.0, at level A — the most basic conformance level — on the homepage itself. Now, being an accessibility sort of a person, finding a level-A failure on the homepage of a site which apparently claims triple-A is not what I would call a good sign.

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A) WCAG 2.0: On Input

If you go around changing the content on the page without warning the user that you are going to do so when they don’t do something where they would expect a change of content (button-click or following a link), this is likely to cause problems. So there’s a level A failure at WCAG 2.0 on the home page.

Aha, but what if they aren’t measuring against WCAG 2.0, I hear you ask. Surely as the COI have just recently announced the public sector can now use WCAG 2.0 as a yardstick, the conformance was probably measured against WCAG 1.0?

Don’t worry: it fails that as well. If you don’t have javascript, the little jobs section provides no mechanism by which you can filter jobs by category. Which is obviously in breach of the Priority 1 checkpoint 6.3:

Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.WCAG 1.0 Checkpoint 6.3

Without javascript, you cannot use this dropdown box to filter by category. It is useless. And to me, this demonstrates a great lack of awareness about what is actually required for accessibility. There is one simple thing that could be used to fix both the WCAG 1.0 problem and the WCAG 2.0 problem. And that is to use a submit button to update the data. It’s hardly rocket science. And, they could possibly drop some of the “browser does not support script” messages which appear all over the site while they’re on.

So there we have it: one simple problem that highlights the fact that Redbridge does not properly get accessibility, and fails both WCAG 1.0 and 2.0 at the most basic priority levels. But of course that’s not all…

There’s data tables not marked up properly:

This is actually quite a common error: people realise that the top row of a data table contains header information, so they mark this up accordingly using <th> cells. But they forget that generally at least one item in each row is the header for that row also.

Take the sixth <td> cell in the table. It contains the value “full-time”, which is associated with the header “hours”. Unfortunately, this is not actually associated with any other value, when in practice it would be more useful if the data value in the first column “accountant” was marked up as a header for that row, because then someone would actually be able to ascertain which jobs were full-time…

This fails WCAG 1.0 at the single-A level — and let’s face it, the checkpoint does specifically mention row headers:

5.1 For data tables, identify row and column headers. [Priority 1] WCAG 1.0: Table Headers

…and similarly it fails WCAG 2.0 at the first priority level…

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A) WCAG 2.0: Info and Relationships

Oh, and don’t get me on to poor use of alt text. Decorative images with pointless alt text all over the shop. #FailFailFail.

Redbridge Fails: Mobility Impaired Users

Frequently, people with upper limb disability (or some other problem, such as Parkinsons) will struggle to use a mouse. So they will navigate through a site using the keyboard only. So one of the useful things brought in by WCAG 2.0 (but in place before that at sites where people properly “get” accessibility) is keyboard focus.

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)WCAG 2.0 Focus Visible

Basically, if you hover the mouse over a link on Redbridge i, the link will change in some way (the navigation gets a little blue glow behind it; the underline on some links disappear and so on). If you repeat with the TAB key to move to the same place using the keyboard, you will find, at best, a very faint focus indicator put in by your browser because those designing the site have not thought to include equivalent :focus or :active pseudoclasses in the styling.

WCAG 1.0 fails to address keyboard only users as effectively, so there’s no outright failure of WCAG 1.0 here, but in terms of practical accessibility and also WCAG 2.0, this is a problem.

Redbridge Fails: Hearing Disability

Let’s take checkpoint 1.4 from WCAG 1.0:

For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1]WCAG 1.0: Synchronize Equivalents

For a movie, captions must be synchronised with the presentation. Okay? And that’s Priority 1 in WCAG 1.0, and er… let’s see … exactly the same in WCAG 2.0:

1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)WCAG 2.0: Captions (Prerecorded)

So if there’s a video with meaningful audio (as opposed to some background music), then it should have captions for either WCAG 1.0 or WCAG 2.0 for even the most basic conformance claim. But if you look at the Redbridge Trading Standards Video, it doesn’t have captions, so that’s a conformance fail for WCAG 1.0 and WCAG 2.0.

When I first started looking at this, I thought this was just a technical fail: that it would fail to meet the conformance criteria, but not actually fail people in terms of practical accessibility, because they have produced a transcript of the video. And, had that actually been the case, I would have given them credit for doing more than most Local Authorities actually do.

Only they’ve demonstrated a critical lack of accessibility awareness by missing out help for anyone with hearing impairments. For anyone with vision impairments, the “transcript” is fine: it contains a text equivalents of the images of text which appear on the screen. For anyone with hearing impairments however, it is useless — it contains the text showing the details they will have already been able to see, but there is no way of accessing the information that they have been unable to hear.

May I therefore suggest that as well as remembering that accessibility isn’t just about the blind, the people behind Redbridge actually look up the definition of the word transcript, because all the ones I could find specifically mention that it is a text equivalent of recorded speech, which seems to be the rather important bit they have missed out of theirs…

Redbridge: Built Into the CMS Fail

You cannot have a Content Management System that produces accessible output automatically. The best that it is possible to manage is a system that is capable of producing accessible output, providing your content editors use it correctly. And in order to achieve that, your content editors must have at least a basic understanding of accessibility (or at least that they have to use the CMS in a particular way).

If they don’t, you get #Fail.

For example, in order to achieve WCAG 1.0 at level AA or above, any direct quotation must be marked up with quotation markup — <blockquote> or <q>. Whether or not I think this is actually necessary is another matter: if you say you conform, you need to do it:

Your content editors must therefore know that any direct quotation must be marked up. And the CMS you are using must have the facility to allow them to do this. Otherwise you can’t reach WCAG 1.0 at the Double-A level. (Redbridge failed this on the You Can Make a Difference news page).

Then you’ve got the PDF minutes of council meetings in breach of WCAG 1.0 checkpoint 11.1, which tells you to use W3C technologies if they are appropriate for a task (and there’s certainly nothing in those plain-text minutes which required them to be PDF rather than HTML).

You also need to ensure that anyone adding a list of items knows not only that they need to be marked up as a list, but how to achieve that, and similarly that headers should be marked up appropriately rather than just being deemed headers by the fact the font is put in bold. I have to say actually that Redbridge i did achieve these last two things pretty well so far as I can tell (given an hour to scan the site) but this does not detract from the point that this is not CMS-out-of-the-box, this is content editors who know what they are doing.

Redbridge Terms and Conditions

On a slight aside, I did attempt to read Redbridge’s Terms and Conditions before using the site, only to discover that they didn’t actually seem to make sense.

By using or accessing any part of the Council’s website you agree to be bound by the following terms and conditions:

• By using Redbridge i you agree to be legally bound by these terms, which shall take effect immediately on your first use of Redbridge i. If you do not agree to be legally bound by all the following terms please do not access and/or use Redbridge i.
• The Council may change these terms at any time by posting changes online. Please review these terms regularly to ensure you are aware of any changes made by the Council. Your continued use of Redbridge i after changes are posted means you agree to be legally bound by these terms as updated and/or amended.
• If any of the following terms and conditions is illegal, invalid or unenforceable this will not affect the validity or enforceability of the remaining terms and conditions
• The relationship between you and the London Borough of Redbridge will be governed by English law. You agree to submit all disputes to the jurisdiction of the English courts.

Redbridge Terms and Conditions

In other words, the terms and conditions are that I must obey the terms and conditions, in so far as they are valid in English law. Seems a bit, well… circular to me….

Redbridge: A Model for the future

I am not trying to imply that Redbridge i is crap: it isn’t. In terms of interactivity it is indeed leading the way in showing councils what they should be doing. I do not wish to imply that Redbridge is not something sites should not strive towards in terms of allowing user customisation — allowing users to have the site displaying the information they want, rather than what the council is telling ‘em they want.

That’s all good stuff.

But it does have accessibility issues, and these need to be mentioned for a few reasons.

• If people are holding this site up as an example of what councils should do, they ought to know where the site doesn’t do so well, so they know how they can improve on it
• So Redbridge i can improve on it themselves and truly make their site a shining example of council sites
• If people are thinking that they have achieved WCAG-AAA compliance, or that level of compliance can be achieved ‘out-of-the-box’ with any software, they need to be educated otherwise.
• Those claiming particularly high levels of accessibility conformance need to be held up to scrutiny: otherwise people will follow them and may unwittingly copy bad practice.

So to all those at Redbridge i who’ve read this, and feel like I’ve given them a kicking, I’m sorry. Yes, I know my site isn’t perfect either (but I don’t claim to be, and I don’t have your resources). But rather than give me a kicking, find out who it was who claimed that your site was Triple-A accessible, and shout at them. They are the ones who put you up there to be challenged and knocked down.

But rather than get grumpy about it, why not look to fix the problems, and truly turn Redbridge i into that shining star?

*Ahem*. Now comes the blatant plug bit. if anyone would like me to advise them on what they can do to improve their site — public sector or otherwise — get in touch, let me know what you’re after and I’ll sort you out with a quote.

Information Society and Media Commissioner Viviane Reding has for the first time talked of a ‘European Disability Act’ that could compel EU nations to adopt web accessibility rules together so that all of Europe’s websites become accessible at the same rate.Out-Law.com: European Commission floats idea of web accessibility legislation

As indicated by the headline, we shouldn’t take this to mean that some pan-European accessibility legislation is going to be brought in imminently, but rather that the EU is taking seriously the problems of web accessibility faced by disabled users and is looking to shift to have a more consistent and coherent approach across the EU in order to prevent sites discriminating against, and in some cases effectively locking out those with disabilities.

The UK already has the Disability Discrimination Act which relates to this sort of thing (which I’ve covered before) which impacts both the public and private sectors; the EU already have the 2006 Riga Declaration on e-inclusion which basically states that public sector websites must achieve an appropriate level of conformance, and now we’ve got the potential of something else.

It’s also noteworthy that specific mention is made of the new accessibility guidelines, showing that there is an understanding that the new guidelines (published December 2008) are significantly better than WCAG 1.0 which dates back to 1999. This, together with the COI‘s acceptance of WCAG 2.0 as a standard for the UK public sector shows that the time has come for WCAG 2.0: it’s no longer something we should just be thinking about, we should be using it now.

We should in my view encourage the European-wide adoption of the global web accessibility standard, the new Web Content Accessibility Guidelines. We should do it together and in step so that the online services industry can reap economies of scale and the users get a decent and reliable framework. I believe the way we should do this is to develop together with stakeholders a European Disability Act.Viviane Reding speech

It’s really a shame that there needs to be such an accessibility stick with which to beat people to force them to make their sites accessible to disabled users. If you don’t care whether or not your site is accessible to people with disabilities, then in my eyes, you’re a bit of a poor excuse for a human being. And if you’re a web designer who doesn’t include accessibility as standard in web design, then you shouldn’t claim that you’re a professional.

After all, this is supposed to be the 21st Century, and it’s not even as if accessibility is hard to achieve when properly built into a site in the first place (and even if it needs to be shoe-horned into a site once developed, it’s generally possible to make quite significant improvements without too much pain). But the idea that any individual, company, or organisation can be allowed to get away with producing websites which do not satisfy basic accessibility requirements is disgraceful.

It is discriminating against groups in society for no good reason. It’s the equivalent of sticking a sign on the front of your site saying “no blacks”. If you think that sort of overt discrimination on the grounds of race is wrong, then it’s time to stop tolerating it on the grounds of disability.

Fortunately, IE does support a thing called conditional comments which allows you to add code to your site if you are using IE, or even a specific version thereof. Thus it can be used to add an additional stylesheet particularly for IE6.

But it’s the second problem with IE6 that causes the most headaches. And that is that it is still widely used. Sure, the percentage of IE6 use is declining, but not as fast as we as developers would generally like, and you will tend to find that a lot of people (particularly those on work PCs in corporate environments) are using IE6 and don’t really have any choice in the matter.

There are certain things like IE6 No More which are campaigns to get everyone shifted off IE6 and onto a proper browser, in order to make life easier for web designers. Of course, one of the problems with IE6 is that because of the way Internet Explorer is so tied into Windows (at least, it was before people started complaining about it — I couldn’t swear to the current status) is that you can only really have one version of IE on your PC at any one time, without having some somewhat complicated setups.

Fortunately, I came across something on the IE Blog which looked as though it may be somewhat useful (this actually came out a smidge over two weeks ago, so apologies if you’ve heard it before!):

The Expression Web team recently shipped SuperPreview for Internet Explorer, a FREE tool for performing cross-browser debugging across Internet Explorer, including versions 6, 7, and 8. This tool also helps developers and site owners in migrating their sites from earlier versions of Internet Explorer to the standards-compliant Internet Explorer 8. This is a subset of the full version of SuperPreview (which also supports Firefox) and which ships with Expression Web 3. You can download it here.IE Blog: Supporting Web Standards Development with SuperPreview

It’s not quite as good as being able to run the two browsers side by side, but it does have some very useful features. Basically it allows you to compare how a given webpage will be rendered by two different versions of Internet Explorer and see what the differences are — you select an element and it will show you the render positions on each of the pages. This is of particular help in deciding if you need a specific stylesheet for Internet Explorer 6, and if so, what should go in it.

In this case the rendering difference (IE6 on the left, IE8 on the right) is mainly due to the whacking great IE6 No More campaign logo I serve up to those browsing with IE6: beyond that there are only a few pixels rendering difference — certainly not something worth specifically catering for.

But this little tool will make checking your sites against Internet Explorer 6 a whole lot quicker and easier so it’s another thing to thank Microsoft for. Although given that they are the ones who lumbered us with IE6 in the first place, it’s probably the least they could do…

So get yourself along there and download SuperPreview for Internet Explorer. That’s the free one, as opposed to the full version.

Full details, including booking instructions and so on, are available on the event page at PSF’s site. It looks like we may also be running a second version of this event at some point in December in Wales, so if you can’t make it to Birmingham, then by all means contact me or Nick and let us know about your interest and we’ll keep you informed if and when we run the event elsewhere.

There will be five basic sections to the event:

1. Introduction to WCAG 2.0 and background of development history
2. Transitioning from WCAG 1.0 to WCAG 2.0
3. Beyond WCAG — Practical Accessibility
4. Accessibility Testing
5. Accessibility and Social Media

…although obviously if people have specific questions or issues about something not covered by one of the topics above, I will do my best to answer them as well!

The event is designed with the public sector in mind, particularly since the recent COI blog post indicated that they are happy for the accessibility of public sector sites to be measured against the WCAG 2.0 yardstick now, and at some future point (after a transitional period), measurement against WCAG 1.0 will no longer be an option.

So why not book up, come along, and I’ll talk to you about it…

There. How’s that for a hard sell? If you want to give me your opinion on whether or not this was a hard sell, why not book up for the event, come along, and I’ll talk to you about that as well

[NB If you're from the private sector and would like to come along, I'm sure 'tis possible to arrange, but you'd need to speak with Nick first]

To this end, I’ve knocked together a little excel spreadsheet to be used for recording Accessibility Audit Results. It has been designed more specifically for the UK public sector, who are generally required to comply with either WCAG 1.0 or 2.0 at the Double-A level of conformance.

The spreadsheet therefore allows you to record results against WCAG 1.0 or 2.0 for up to 25 pages for all checkpoints and success criteria up to and including the Double-A level of conformance. The abbreviated text for each checkpoint/success criterion links to the appropriate WCAG document to provide further information where required. Please note that at present, the triple-A conformance level details have not been included at this stage as these are not usually mandatory for public sector sites.

The spreadsheet requires you to input “PASS”, “n/a” or “FAIL” for the checkpoints/success criteria against which each page is measured. You may include additional text after this, but each cell should begin with one of these three values if you wish the conditional format colour coding and automatic calculation of compliance levels. The document is available under a Creative Commons Attribution Share-Alike licence, so you are free to make other works from it as you see fit, so long as the original attribution text is retained. I would also appreciate it if you could drop me a line to let me know what you have done with it, but this is not mandatory.

So, fill yer boots. Here’s the Accessibility Test Log (XLS, 99kb)