When, how and why did Lloyds begin its accessibility journey?
The journey started in 2003, two years after I joined Lloyds TSB, when I was a project manager in one of our web development teams; a question was raised at a management meeting regarding whether our work was “Disability Discrimination Act compliant”. I had an interest in disability and IT from my days as an undergraduate in the ‘80s so I volunteered to investigate.
I quickly established that there was no clear understanding in Lloyds of what “DDA compliance” meant in relation to IT and the closest I could find externally was the need to adhere to the W3C’s Web Content Accessibility Guidelines (WCAG).
Being a web developer myself, I asked the question, “why wasn’t I aware of WCAG and why was it that, nearly 10 years after their publication in 1995, that they weren’t being used as a matter of course within organisations like Lloyds?”
The conclusion I came to was that guidelines alone were not enough; an organisation like Lloyds works to standards which have to make sense to the business and the people who are using them. WCAG was written in a language that was too hard for non-techies (or even some techies!) to understand. So we needed to repackage them into an internal standard that worked for our people.
Secondly, we needed to put in place governance to ensure that all project teams used the standard during design, build and test, plus we needed to have a way of dealing with non-compliance to ensure that issues weren’t swept under the carpet.
Thirdly, we needed to educate designers, developers and business people so they understood the importance of accessibility and had the skills and desire to put it into practice.
What was the process for creating a business case for accessibility?
The business case was something I developed almost on an empirical basis, i.e. I demonstrated the need, demonstrated that it wasn’t rocket science to achieve and it was something we could do ‘up front’ with minimal cost (vs the cost of retrofitting).
Step one was to convert WCAG into something that we could use as an internal standard. I basically removed a few checkpoints that made no sense or would never be agreeable for a bank, rationalised others to reduce repetition and reworded others just to make them clearer. The result was something that was to all intents the equivalent of WCAG v1 AA. I had this verified by external accessibility experts to ensure that I wasn’t taking Lloyds down the wrong path.
Step two was my “guerrilla campaign” to raise awareness which ran from mid 2004 to June 2005. This took two aspects— a roadshow where I’d rock up to various head office buildings and deliver presentations on accessibility to anyone who would listen, secondly dropping bombs on website owners by creating accessibility reports on their sites/systems that highlighted the issues and—critically—showing them prototype pages I’d created that looked identical but were at least AA compliant.
The importance of that last point can’t be overstated—never take a senior stakeholder a problem, always take them the solution, in this case I was proving that it was possible to have pages that looked good, were accessible and could be created by a humble project manager.
After a few months of this I’d gained the attention of some senior people in the bank, for example the head of the intranet, head of Internet Banking and some supportive business managers.
This lead to two tactical moves that helped secure the formation of an IT Accessibility team.
Firstly, I managed to persuade our IT Service Introduction team to introduce checkpoints into our “Gateway” process that would ensure accessibility was incorporated during the project lifecycle, with me volunteering to act as the approver.
Secondly, one of advocates in the business agreed to commission some accessibility testing with an external company that used testers with disabilities.
I took this opportunity to invite the Director of Group IT to attend and watch some blind people testing one of our websites. This he did and spent about 30 minutes with us. On the way out I suggested that this was something that we should do as a matter of course. Furthermore, I said, here is a proposal that suggests how we go about it. He flicked through it and said yes, I agree.
The proposal was fairly simple—it proposed a couple of FTEs to look after the standards development, testing/testing oversight and education. Funding could be achieved by a small levy on projects to cover the cost. I recommended that the team sat in the Enterprise Architecture & Design team in IT as this was the home of standards and governance.
In June 2005 the IT Accessibility Centre of Excellence was launched with three full-time colleagues. I led the team until 2010 when I took on my current role as a general disability SME.
What were the goals of the accessibility implementation?
My goal was to ensure that accessibility was never treated as an afterthought or add-on, instead it had to be a non-negotiable requirement, just like security or resilience which is applied to every website or application we developed or purchased.
To achieve this it had to be clear what the rules were (i.e. the standards) and have robust governance in place to prevent people from breaking the rules. Basically, I wanted it to be easier for projects to use the standards than have the hassle of having to raise waivers to get round them.
Note that we started with Web accessibility but soon expanded to create additional standards that covered Application Software, PDF, Flash and Microsoft Office. The governance approach varied slightly, e.g. it’s one thing ensuring that every website complied with the web standard, but we couldn’t realistically hope to police every Word document or PowerPoint presentation! In the latter case education was more important than governance.
What was the implementation process like? Did any challenges or surprises emerge?
On the whole my recollection of the implementation process was that it was pretty straight forward at least from an internal perspective—colleagues both in the business and IT generally “got it” and could see it was the right thing to do, wasn’t difficult to do and just got on with it.
The bigger challenge was dealing with suppliers who were not used to one of their clients asking questions about accessibility during procurement or in light of an issue. The response invariably was “no one else asks about this” or “it complies with Section 508”.
This has got better over the years, mainly through I believe organisations like Lloyds Banking Group working with peers through bodies like the Business Disability Forum in the UK to apply pressure to suppliers, but sadly some of the big enterprise software vendors are still unable to provide basic compatibility with assistive technology.
Do you think web accessibility will become mainstream?
I think it is now mainstream.
Firstly, businesses in the UK (and I hope elsewhere) now increasingly seeing disability as a business issue rather than a fringe interest. For example, at Lloyds Banking Group gone are the days when I felt we were having to push accessibility onto an unwilling business, now the business are keen to understand what more they can do to support customers with disabilities. Furthermore there is clearly a healthy degree of competition between us and other banks on improving services for disabled customers and being an employer of choice for people with disabilities. Whilst none of us are perfect there is a very strong push for continual improvement and this includes the accessibility of our public websites and internal applications.
Secondly, web technology has grown up over the past 10 years; something as simple as using CSS to control presentation and layout are now taken for granted and supported by all browsers, likewise libraries such as jQuery and Dojo provide accessible widgets out of the box.
For web accessibility, is self-governance, government regulation or a mix of both required to make services more accessible?
I think it’s useful to have a very general law that compels organisations to take the inclusion of disabled people seriously (with penalties if they fail to do so), but it’s less useful to have something more specific.
The reason I say this is that the law moves far slower than technology; if you have a law that says in order to be legally compliant you must adhere to this specific standard or these specific technical checkpoints then as soon as technology moves on then that law is at risk of being out of date.
Consider Section 508b—this was published in 1998, shortly after WCAG v1, is a subset of WCAG v1 Level A checkpoints (so a pretty low bar to start with) and is now well past is sell-by date. But many US-based suppliers use it as their reference point and are reluctant to go beyond its stipulations.
So my preferred route is to have something like the UK’s Equality Act 2010, which provides legal ‘encouragement’ without being prescriptive, backed by self-governance and market-forces to deal with the details.
What’s your view on the role of accessibility standards, such as BS 8878 and WCAG?
Without knowing what “good” looks like we wouldn’t have a clue what we were aiming for. So whilst I had my reservations about the way WCAG v1 was written we would have been shooting in the dark without it.
WCAG v2 is a great improvement because it moved the guidelines into a modern and pragmatic age by recognising that the additional “non W3C technologies” that we were all taking for granted (e.g. JavaScript) had become an essential part of the user experience and web application construction. Along with WAI ARIA Web Accessibility Initiative’s Accessible Rich Internet Applications suite) there really is no excuse for not making modern web applications accessible and, moreover, usable for people using assistive technology.
That being said I would still recommend that an organisation adapts the guidelines to remove ambiguity, make them authoritative and help them make sense for the people in the organisation and enable them to work with them; I’m not talking about wholesale change, just making them easier to understand and apply.
BS 8878 is a different beast; it is not a technical standard and we were very clear when writing it (I was a member of the drafting committee) that we didn’t want to confuse things by having yet another set of guidelines for people to follow.
Instead it’s a code of best practice in ensuring that accessibility during the product lifecycle, for example what factors to consider during design and development, how to go about testing, how to approach procurement of third-party products, etc.
BS 8878 seems to have been reasonably successful in the UK. Could Australia benefit from its adoption?
One thing I really like about BS 8878 is its honesty in saying during product design and development that decisions will have to be made which will potentially impact its accessibility. For example, factors such as constraints around choices of technology or the needs of the primary audience.
Rather than ignoring these factors, the standard makes people think about them up-front, consider approaches that might minimize the impact (e.g. complementing inclusive design with user personalisation) and documenting decisions made and the rationale for them.
I think this along with a solid framework for ensuring accessibility throughout the product lifecycle would benefit Australians just like anyone else across the globe—with the exception of the annex on the law there’s nothing in there that really makes it a UK specific standard.
Final thoughts?
If you’re struggling in an organisation that doesn’t “get” accessibility, remember the George Bernard Shaw quote about “the unreasonable man”. Don’t accept the status quo; bend your organisation to your point of view. If I can do it, anyone can.
For more on web accessibility know how, visit Media Access Australia's resource for web professionals, Access iQ.
Top of page