Upcoming changes to cookie laws

As I’m sure most readers are aware, the European e-Privacy directive is due to be implemented in the UK in May and will result in a change in the law relating to cookies (small files stored on your computer’s hard drive). This change is getting increasing coverage on techie mailing lists and even on more mainstream news sites such as the BBC.

The law states that cookies or similar devices must not be used unless the subscriber or user:

  • is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information; and
  • is given the opportunity to refuse the storage of, or access to, that information.

The only exceptions are cookies that are “strictly necessary” for provision of a service. The oft-cited example being session cookies for e-commerce sites etc.

The law will mean that consent must be obtained for all other cookies, including cookies used for Web analytics (such as Google Analytics), personalisation or any other non-essential purpose (e.g. advertisement tracking).

The Information Commissioner’s Office (ICO) is yet to issue clear guidance to developers on how to obtain consent. For example, this could be interpreted as having to implement functionality ensuring that users confirm consent in a web page/pop-up etc when a non-essential cookie is to be set. Alternatively it may be that consent could be implied by browser settings. Obviously any intrusive mechanism of consent is likely to present a barrier to users so developers are awaiting the guidelines from ICO with interest.

The ICO has said that they will give organisations time to adapt and so won’t be in a position to start enforcing the law immediately. So, for now, it’s perhaps just a case of being aware of the impending change and waiting for guidance from the ICO.

Further reading:

Update: 25/05/2011

The law comes in to effect tonight and, although the ICO has now issued guidance, the steps Web developers should be taking remain far from clear. At this time it’s hard to see how a site setting non-essential cookies (such as those used for Web analytics) could comply with the law without intrusive interstitials or pop-ups. These approaches could be seen to dramatically decrease usability and offer a competitive advantage to similar sites operating outside of the European Union.

In an ICO press release today they say that organisations have up to 12 months to comply with the new law.

Launch of BS 8878 Web accessibility

Last week I attended the launch of BS 8878, the British Standard for Web accessibility. The launch event was a mixture of talks and panel sessions held in central London.

What is BS 8878?

BS 8878 is a standard intended to help those commissioning or building Web sites/apps/content ensure that the output is accessible to all. The key difference between BS 8878 and documents such as the W3C’s Web Content Accessibility Guidelines (WCAG) is that BS 8878 provides guidance on the process of producing accessible online content/services rather than details of the actual technical implementation. BS 8878 also provides guidance on how to take, justify and record decisions that may impact accessibility within the design/production of Web content/services and, importantly, how to communicate those decisions to users.

The main content of the standard has 16 steps categorised in to three different areas:

  1. First stage: doing the right research & thinking before you start…
    1. define the purpose of the web product
    2. define the target audiences for the web product
    3. analyse the needs of the target audiences for the web product
    4. note any platform or technology preferences and restrictions of the web product’s target audiences
    5. define the relationship the product will have with its target audiences
    6. define the user goals and tasks the web product needs to provide
  2. Second stage: making strategic choices based on that research
    1. consider the degree of user-experience the web product will aim to provide
    2. consider inclusive design and user-personalized approaches to accessibility
    3. choose the delivery platforms to support
    4. choose the target browsers, operating systems and assistive technologies to support
    5. choose whether to create or procure the web product in-house or contract out externally
    6. define the web technologies to be used in the web product
  3. Third stage: production, launch and maintenance (lifecycle)
    1. use web guidelines to direct accessible web production
    2. assure the web product’s accessibility through production
    3. communicate the web product’s accessibility decisions at launch
    4. plan to assure accessibility in all post-launch updates to the product

The standard provides a good, practical framework supporting the process of creating accessible Web content. My only concern is that, for a document that should be widely read and adopted, a £100 price tag may unfairly and inappropriately limit its exposure.

Sound bites from the launch event

I was surprised how "embedded" accessibility has become in some corporates and think that the approach of getting buy-in from the top is something that the HE sector could learn a lot from. The power resulting from this buy-in can’t be underestimated in order to create products and services of exceptional value to all. What became evident is that it released the "champions" to just get things done.

Other interesting things I got from the day were:-

  • The Equality Act 2010 (which replaces the Disability Discrimination Act) makes it possible for a Web developer to be sued if they follow a client’s instruction that resulted in inaccessible content (since you’ve built a site/service that discriminates).
  • If you take steps to optimise your site for mobile devices then there is a stronger legal argument that you must make it accessible on all mobile devices than if you had not taken those steps and it just worked on some devices by chance/accident (but not specifically through design/development effort).
  • I suspect many of us know this anyway but Struan Robertson (Pinsent Masons, the law firm behind OUT-LAW.COM) said that compliance with any level of WCAG would not protect you from a legal challenge. The best way to demonstrate your site is accessible is to have evidence of use by users with disabilities (ideally through testing with these user groups). That said, he thought that complying with WCAG2 AA would mean that not only would you be less likely to be sued but, if you were, the case would be less likely to succeed.
  • The talk from Nomensa and BSkyB was also very interesting. After launching Sky TV Accessibility (built using Nomensa’s accessible content management system, Defacto) Sky saw a 20% reduction in calls to their help centre. In addition, the complexity of the calls they did get increased.

Avoiding rate limits when polling feeds

One of the cool things about the web is the ability to integrate content from a variety of sources. For example, you might want to pull in news data from an RSS feed and have the news items displayed on your web site.

This is easy to do with a script (such as a program written in Perl, PHP or Python etc) running via a cron job. The script then stores a fragment of content that you can use within your pages.

However, many services limit the number of content requests you can make in a specific time frame. For example, Twitter limit the number of requests a client can make to their service each hour. This prevents the service being swamped. Exceeding this limit, depending on the service, might result in an error or the IP address of your server being temporarily blocked from accessing that service.

Hitting the buffers

Under normal circumstances you probably won’t need to request a feed so many times that you hit the limits yourself. However, imagine the scenario where your web site is hosted on a shared server. You may only be requesting the feed once every two hours but, if other users on the same server are requesting data from the same service at a much higher rate, the combined number of requests might push you over the limit.

In this situation you might find that your requests will fail even though you are making requests at a low frequency.

Creating another source of the feed

If your access to a service is being limited by factors outside of your control then it’s often helpful to find an alternate source of the feed. This is rarely provided by the host service themselves but came be easily set up using Yahoo! Pipes. Yahoo! Pipes are a great way to aggregate, filter and republish data from online sources.

However, at the most basic level, you can set up a simple pipe that requests the RSS feed from the external service and then republishes the data as RSS at a http://pipes.yahoo.com address (see the ‘Get as RSS’ link for your Pipe).

Screenshot of a simple pipe created in Yahoo! Pipes

Once you have created the Pipe you can then request the Pipes version of the RSS feed rather than the original (remembering that you should still keep the rate of requests at a low level).

The result is that the request for the feed comes from the Yahoo! Pipes service and not directly from your script and you can circumvent the issues caused by other users on the same hosting. This is because services like Yahoo! Pipes are intended to be polled and are often white-listed.