Tip: if you’re short on time, skip to the end of this article which lists the key findings.
Any reader of this blog who works with the web in Europe will probably be aware of the EU’s Privacy and Communications Directive which came into force last May, and which proved such a challenge to implement that organisations were given a whole year to work out how to comply.
The law requires that website owners obtain informed consent from visitors before any “not strictly necessary” cookies are stored or retrieved.
Critics of the law have focused on the difficulty in implementing a satisfactory, but not too intrusive, system to gather the informed consent; as well as the potential vicious circle where a user refuses consent, meaning the website can’t place a cookie to retain that preference, and is therefore forced to ask the same question every time.
As a result, thousands of organisations are still labouring to find the best solution, and the clock is ticking, counting down to 26th May 2012, when the ICO plans to start investigating and fining:
Any website found guilty of using technologies to track a user’s browsing behaviour without their consent or sending unwanted marketing emails to consumers could face a fine of up to £500,000.
The new monetary penalty is part of raft of new powers granted to the Information Commissioners’ Office (ICO) to regulate breaches of privacy regulations.
Source: Which? News
Whilst I don’t intend to comment upon the good or bad points of the law itself, I am interested in what implementation of the law may mean for the accessibility and usability of any websites striving to comply, and whether the threat of a fine may be seeing hasty, inaccessible solutions.
Accessibility and usability concerns
A number of organisations have now implemented a variety of solutions, with fairly mixed results. Importantly, some people have started to raise concerns about potential accessibility and usability issues.
After an initial investigation, here are a few examples. I’m focusing on UK government websites as that’s my field, although the findings apply to any site. I want to make it clear that it’s great that people are trying to take a lead in this by coming out with their own early solutions, and I’m sure they’ll be continuing to iterate and improve, so the below comments are intended to be constructive feedback.
Information Commissioner’s Office
The ICO’s own solution is a functional but perhaps uninspiring effort, and could easily be ignored or even missed due to banner blindness. The explanation of what the cookie does is vague (“help us make the website better”) although the privacy notice does go into much more detail. However, the privacy notice opens in a new window, without explicit warning (just a mention in the link’s title attribute, although WAI guidance calls for such a warning in the link text itself).
It’s also persistent – there’s no option to say “no” and have the banner go away. This would normally be seen as a usability fail, potentially forcing people to accept just to get rid of it, which might challenge the legitimacy of the “consent” gained.
But accessibility issues make things worse. The bar is not easily accessible by keyboard users. It appears towards the end of the source code and is the last set of links in the tabbing order, meaning you have to tab through dozens of links to get to it. It’ll also be the last thing a screen-reader user hears, and it’s highly unlikely that a user would get to that point in the page.
A final major problem is that the message appears over the top of the “skip to” links and render them completely useless to sighted keyboard users. This is a serious example of not only the opt-in box being inaccessible, but also of it messing up existing, site-wide accessibility features.
Torridge District Council
Torridge District Council offers the following yellow bar at the top of their website:
The message here is fairly simple, and refers directly to what the cookie does. The options are simple – yes or no – and there’s a link to more info. All good so far.
However, just as with the ICO, the box comes last in the tabbing order for keyboard users, and it’s highly unlikely that anyone will wade through the dozens of links to state their preference.
Civic UK’s Cookie Control
The Scottish Government recently posted guidance for all of its official websites, recommending the use of Civic UK’s Cookie Control. This takes a different approach to the two previous examples, bringing up an arguably intrusive, bright “pop-up” box .
This time, the tabbing order appears to be correct, taking you first to a control that toggles the pop-up on and off, then into the pop-up itself. It’s still not perfect for sighted keyboard-users – there’s no change of state on focus, meaning the appearance of the buttons doesn’t change when you tab to them (as they do if you hover a mouse cursor over them).
But a new problem presents itself after a few seconds – in Civic’s own demo the pop-up box disappears. This might make sense at first – getting it out of the way of users who aren’t interested in making a selection (although the pop-up comes right back when you move to another page).
However, what about users who need longer than the 10 seconds or so that you’re given to read the information and make your selection?
Guideline 2.2 of WCAG 2.0 requires that for any time limited action, you provide the ability to turn off, adjust or extend the time given. These options are not evident in this solution, so would probably result in any website using this as-is failing WCAG 2.0 at the most basic level of conformance (level A – the mandatory minimum for UK government websites).
It’s worth noting that the website owner can customise the timing of this solution to stay visible for a longer period, which may help, although WCAG 2.0 would require you to specify at least 72,000 seconds (20 hours).
UPDATE – see the comments below for a response from Civik UK.
Fife Direct’s recent implementation is certainly one of the better looking ones. Using an unobtrusive dark bar at the top, which correctly comes first in the tabbing order, it overcomes all of the problems described so far. It also provides a link to “more info” which expands the box to give more details and options, including a very useful option to “allow just one cookie to hide the cookie bar”.
Why is this an actual problem? Try printing the page (or, to save paper, just click on “Print Version” at the top). Over a page of text about cookies before you actually get to what you intended to print. By which time, the person may well have hit the printer’s “cancel” button thinking they’d done something wrong.
And to make things even worse, the text remains in the source code even after you’ve accepted cookies. That’s going to mean a lot of wasted paper.
Based on these observations, I recommend that anyone working on a method for gaining cookie consent take note of the following:
- Ensure the solution can be easily tabbed to by a keyboard user, and that all of the controls are accessible by keyboard
- Ensure that the solution does not affect existing navigation or accessibility features
- Keep the text short and link to more information on a single, separate page (probably your privacy page), ensuring the link is accessible too
- Avoid intrusive pop-ups which may confuse the user or block other key functions or content
- Don’t put a time limit on any controls, or, if you do, ensure the limit can easily be deactivated or changed
I’m sure we’ll see more issues cropping up, and I’d love to hear from anyone with details of any others. Equally, if I’m wrong about any of the above, do please get in touch!