Presentation: Accessibility on the BBC Sport Olympics Website

In December last year I was asked to speak at the BBC about the accessibility work we did on the BBC Sport Olympics website. Here’s the 10 minute presentation that I gave to a non-technical audience in which I set some context about web accessibility and how we approached it on the project. I’ve also provide a transcript of the presentation:

Transcript

Hi, my name is Alistair Duggin. I was the lead front-end developer on the Sport Olympic Website. The website was pretty massive, a lot of content, lots of interactive features. It had a page for every country, athlete, venue, sport and medal winning event. We also had the medal table which proved to be really successful with over a million hits and was favourited by over 10,000 people. We had a lot of interactive components set amongst our pages for news, facts, schedules, results, medals, favourites, a twitter module and a top-trumps style head to head module.

As a developer, when you work on this stuff you normally get given designs and it’s your job to make them look and work how the designers and product owners want them to. A big priority that we all had during the Olympics was to make it accessible to everybody. We’ve already talked about the effort we made to make it available on the TV, mobile and tablet, but we also needed to make sure it was available to everyone that was using a desktop computer.

Web accessibility is basically about making a website work for everybody irrespective of their device or ability. People surf the web in lots of different ways. Me, as a developer, I tend to have a quite a powerful computer, I’ve got a large colour monitor, I use a mouse or a touch pad, I’ve got speakers, the latest browser with the default font size, I’ve got Javascript, CSS and images enabled, and I’m lucky enough to have a fast internet connection. Lots of websites out there only work under these sorts of situations which is not what we wanted to do.

Users have a range of capabilities, assistive devices and settings. People who have poor vision may increase the font size or they may be using a screen reader that reads out the content of the website. People with auditory difficulties cannot rely on sound necessarily. There are people with motor disabilities, such as arthritis, missing limbs or Parkinson’s, where it is hard to use a mouse so you are potentially forced to use a keyboard or voice recognition software. You also have people with cognitive issues, such as dyslexia, who may choose to change the settings of the browser so they are seeing a font and a different background making it easier to read.

The number of people who don’t access the web in a default way is much higher than most people realise. There are over 10 million people who are registered as disabled; there are over 2 million with sight problems; one in twelve men are colour blind; 12 million people are over the age of 60 and, as we all know, with age we start to lose mobility and sometimes sight.

So our challenge was to build the website in such a way that it would work for everybody, irrespective of the device or capability. One of the biggest challenges was that the designers were pushing the boundaries of the interactive nature of the website. We had lots of Javascript for carousels, accordions and animated medal tables. Most of us had lots of experience of making static BBC websites accessible, but making Javascript heavy websites accessible was a new challenge.

Kate already covered some of the statistics; we had a massive amount of users and we had no accessibly complaints, which proves that we did a pretty good job.

To make something accessible you really have to understand the characteristics of what an accessible website is. Your content needs to be perceivable, so no matter if you are accessing the content through sight, hearing or through touch, as in braille, the device needs to be able to communicate that content to you. Another big part of accessibility is to be able to transform one type of content to another. So if you have a website that has an image, a screen reader will not know what is inside the image therefore you need some kind of alternate text that a screen reader can read out. The website needs to be operable: most people tend to use a mouse, however, lots of people use keyboards, which involves tabbing through, jumping you from links to buttons and forms. There are other people who use voice recognition software, they will tell the computer to go to a page or click a link. Another key characteristic of accessibility is that it is understandable. It needs to built using plain language and have icons which make it easier to understand and you need a consistent and intuitive navigation. The other part is that it needs to be robust, so if someone does choose to change their settings or if for some reason they don’t have Javascript enabled, you still want it to work. It may not work exactly the same for everybody, but you really want to be providing them with the same content and the same functionality so they can do the same thing that everybody else using the website can do.

Our approach was to think about accessibility at the start. You cannot build a website and then add the accessibility on at the end, it’s really a core part of the build. Due to the new Javascript technologies that we were pushing, we made sure that got advice from experts and had training. The main thing was to pay real attention to how you’re writing your code, and be aware of the different devices that people use. A technique that is vitally important to accessibility is called ‘progressive enhancement’ where, rather than looking at a page and thinking about its design and functionality, what you are actually doing is thinking about the content first. Once you’ve got the content there, you can then add a layer of mark up that describes what that content is. You can then add the visual design so that it looks how the designers wanted it to. After that, once that all works, you can add the layer of Javascript which can enhance the usability. The other key thing that we did was to test thoroughly. What you do not want to do is to launch a site without having tested it and then get an avalanche of feedback saying that people can’t use it.

The biggest part of our success was the attention we paid to detail. Accessibility, when you break it down, is not difficult but it is so easy to introduce a barrier anywhere in the build process. The attention to detail involves making sure the content is in a logical order, that text links are understandable (you don’t want ‘click here’ links as they do not make sense out of context), making sure that you have got appropriate heading structures, so that people who cannot see the screen can get an understanding of what’s on the page and how to navigate to it. If you are using Javascript to dynamically fetch content and insert it into the page, if you can’t see that page, you need to be made aware that the content has updated and you need to be taken to that content. So there are lots of really small things that are important, which are not difficult, but if you are not doing them, you will introduce barriers.

Another big part of our success, I think, was the thoroughness of the testing that we did. We did this whilst we were building it. We had code reviews to make sure that developers hadn’t accidentally introduced problems and we had an expert who tested it afterwards. Testing it involved looking at things like increasing the font size and making sure that everything still worked, turning off images to make sure you could still get an understanding of everything that was there, turning off Javascript and CSS, making sure that everything works when you just use a key board and also testing it with a screen reader. There were also automated tests that we did like validation and colour contrast. If you can test with real users, that will help as well.

In terms of benefit to the BBC in the future, I think we have set a new benchmark in how accessible you can make a website and also that accessibility doesn’t have to compromise the design or functionality of a website. Sometimes, as soon as you mention accessibility, people assume you will have to compromise, I think that we have proved that you don’t. I think that we also proved that by building in accessibility you actually provide everyone with a better user experience. I guess one of the next big steps is to spread the knowledge and approach that we had to other teams to help improve other products around the BBC.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>