Back in the spring of 2005 I was not an Accessibility Specialist, I was managing a team that produced TV trails. I then had a chance meeting with Tony Ageh, then Controller of bbc.co.uk, and we talked about accessibility… and the lack of it. He knew there was a need but it seemed that no one was offering an approach.
At the time my son was just 6 years old, he has spastic quadriplegic cerebral palsy and although there were switch games on the Cbeebies website (thank you Ian Hamilton, Cecilia Weiss and Emma Pratt Richens) for the under 6s there was little or nothing beyond that he could access and he was growing out of Cbeebies. As he said at the time, “its for babies. My friends play on CBBC and I’m being left out of all the fun.”
I wanted to know why this was the case so I contacted the senior management.
The thing is the BBC has a long history of accessibility and inclusion. It pioneered in-vision sign interpretation in 1957, then pioneered the first TV closed caption TV service in the 1970s based on the worlds’ first digital text based information service, Ceefax. It then introduced Bi-Media production in the 1990s for it’s reportage which made it’s broadcast News, Sport, Weather, Current Affairs, Live and Music programming accessible to people who are vision impaired without the need for audio descriptions and it worked as part of an industry consortium with partners including fellow broadcaster ITV, around the same time to launch the first audio described services, leading on the fist set of broadcast production tools.
So why, with this history, were we not making the same inroads into out digital output?
What came from that conversation was a discussion that escalated all the way up to the Exec board.
It transpired that like in Cbeebies there were pockets of good practice being led by individuals within teams, there was pioneering work happening and that there was potential but no organisation can rely on the perseverance of individuals in isolated product areas. The BBC needed an approach that was centrally managed and both scaleable or sustainable. There was so much opportunity in terms of pioneering inclusion for new services on emergent platforms and this became my brief.
Did I have any answers?
Not really, but instead of jumping straight to solutions I outlined an approach that would ensure the future of the BBC’s digital services had the potential to be as accessible and inclusive as possible. With support from the other members of Tony’s management team it took about 5months to shape, it got Executive sponsorship from the now Director General, Tim Davie and the DG at the time Mark Thompson, and after the BBC strategy paper Access For All, it gained approval from the entire Exec.
I was given permission to set up the BBC’s Digital Accessibility Team within a new team that was building a new product, and hired Lucy Dodd (now Puliccino), Andrew Strachan and Kevin Carey. There was one stipulation to the agreement to do this which was communicated to OFCOM, the RNIB and RNID (now Action on Hearing Loss) was that if we launched iMP (BBC iPlayer) it had to be “as least as accessible as BBC TV.”
The brief sounded straightforward but as there was no precedent we had a huge task on our hands.
As Tony was Project Director he gave us full support to research and implement what needed to be done, and with Ben’s technical guidance the requirements we produced were signed-off and we then became a support for the rest of the team. The brief wasn’t solely confined to BBC iPlayer as we were also asked to turn what we were learning into a resource for the rest of the organisation to use, and this is when we formed the Accessibility Group, which was effectively the first accessibility champions network.
That all sounds pretty straightforward, and in many ways it was, but it was also massively problematic. We still built nearly everything either using tables based layouts or using Flash for whole websites.
The digital division only controlled some of the digital output as most of the design and development teams sat in the content divisions, and even though there was a spirit of collaboration across the organisation the reality of each division building it’s own products was going to be a practical problem as we had multiple technical frameworks and different workflows to consider. There wasn’t a unified UX team in those days and component duplication was happening all over the place.
There was however an incredible energy to tap into as at the time the BBC’s first mobile services were bring developed, there were prototypes and early site specific products such as BBC Coast, BBC Stapler, and UGC projects like BBC Project Hull and BBC People’s War. The pace of change was fast and my small team was given the task to work as broadly as possible, but as Andy Conroy said to me at the time, “boil the ocean, but do it with one carefully chosen kettle at a time.”
The BBC iPlayer team we were embedded into grew incredibly fast and the pace of development and prototyping meant we had to research everything we could as there had never been a VOD service before (at that point iPlayer was peer-to-peer and not streaming).
We initially looked to WCAG v1.0 and reached out to the few industry experts that were around at the time to help us understand the guidelines from both technical and user perspectives.
This is when I first met people like Robin Christopherson and Molly Holzschlag, whom we invited to the BBC to run workshops.
As these sessions were so over subscribed, we could never find rooms big enough. Lucy set up user panels of people with various conditions so we could understand accessibility from a user outcomes and expectations perspective, and when cross-referencing that with the breadth of services appearing we quickly worked out that WCAG was not going to be enough. It was obvious our small team that auditing alone could not scale to meet the demands of the organisation, or enable us to deliver equivalence and comparative experiences for all our users.
WCAG is a great resource, but even if it provides a foundation to build accessibility from, it needs to be contextualised and we learned that a gap analysis between WCAG guidelines and the needs of you product teams will show you where you need to create your own product specific guides or guidelines based one your own technical and user research. The BBC developed it’s own Accessibility Guidelines and further good examples of how we filled gaps are the BBC Subtitle Guidelines (2005), BBC Mobile Accessibility Guidelines (2011), the first BBC Games Accessibility Guidelines (2007), BBC Semantic Markup Guidelines (2007) and the BBC’s Editorial Guidelines.
WCAG was and still is a great evolving resource, but by re-interpreting and building on those guidelines we could make the W3C guidance more relevant to BBC audiences, different age groups, different content experiences, different languages, emergent services, barrier groups not covered adequately by WCAG and adjust the guidelines to be easier to understand, be easier to test without the presence of a specialist and all without losing any of the goodness. We also got to be more responsive and fill in the gaps as we were driven by the pace of the organisation and not the industry or external politics.
This all sounds really smooth but to be honest we made some decisions which were a bit iffy but they always lead to great learnings we made along the way.
We definitely learned that when you are working on projects where there is no precedent, it’s OK to try and fail as long as you learn from the failure.
This is how I realised the truth in, “fail fast and fail often”.
If your organisation is setting out on it’s accessibility journey I have some simple pieces of advice.
- Focus on user requirements first and not compliance, unless the only reason you are interested in accessibility is to avoid being sued. Then maybe the rest of the advice isn’t for you.
- Find your community within your organisation. No-one can deliver accessibility by themselves, so find your a11y tribe and set up a Champions Network.
- Start with design. Disability is something designed into products and accessibility becomes a bolt-on because of this. Developers can’t fully fix poorly design experiences.
- Bookend UX with QA. Develop test scripts with QA that can be used across products that are directly related to the successful implementation of components in your design system.
- Training is key and it should be very specific to the disciplines being trained. The more knowledge there is in the organisation the less fire fighting you have to do.
- Auditing is not a useful activity as part of any development process. Audit to learn about things like labelling conventions, to do a health check for an annual board report, to understand where a product is, but never as part of a product lifecycle. Auditing is about compliance, not about users.
- Data… all types. The only way you can bring your accessibility programme to life is with good data. Embed mixed ability recruitment into you organisation’s design research programme and look for ways in which you can access reliable quant data to evaluate the impact and effectiveness of your programme.
- And lastly, and most importantly, don’t turn into the Accessibility Police. Give your teams support and encouragement, and if they fail, help them learn from the failure and work with them on how to improve next time. Look for the wins, however small, and celebrate them
#accessibility #a11y #BBC #UXDesign