EU ready to set laws for accessibility testing
Banks and other financial firms will have to ensure their apps and websites are accessible to disabled customers. They can save money by embedding accessibility testing in DevOps environments, says Paul Smyth (pictured), Head of IT Accessibility at Barclays.
The EU parliament is drafting a directive that will force private sector companies to accommodate disabled people when offering their goods and services. It has already adopted a directive requiring all public sector websites to adhere to accessibility guidelines.
The draft directive will specifically describe the standards banks and other financial services firms have to meet and references the international standard for online accessibility; the Web Content Accessibility Guidelines (WCAG) created by the World Wide Web Consortium.
Among the of steps that banks will have to take are:
-Websites of banks have to be laid out in a logical manner which allows for flexible time for navigation.
-Websites have to provide the option to adjust font sizes.
-Colour layouts will have to be designed so that there is enough contrast between text and its background and that it can be viewed by the colour blind.
-Any text should also include audio alternatives and videos should come with captions.
-The language used should be as free from jargon as possible.
The move seeks to harmonise pre-existing legislation across the continent, bringing it all up to a minimum standard. In the US, firms must comply with the Americans with Disabilities Act (ADA) of 1990, the equivalent to the incoming European Accessibility Act.
In the US litigation has been a strong driver of accessibility testing. This is a trend that is likely to continue as the Department of Justice has increasingly been making statements in favour of plaintiffs in ADA lawsuits, tipping cases in their favour.
Most accessibility testing is still done manually, agree the firms that specialise in this area. But testers are increasingly relying on automation tools to speed up the process. Deque, a company headquartered in Virginia and founded in 1999 estimates that aXe, its open-source automated testing platform, is now used by 25 thousand testers every day. Deque also provides a proprietary product called WorldSpace, which supports iOS and Android analyses, and integrates with developer tools such as Jenkins and SonarCube.
Dylan Barrell, CTO at Deque, said that the spread of automated tools for accessibility testing, which can catch between a quarter and a half of WCAG violations (different experts gave different numbers), can help build-in quality in at the beginning, saving money and time. Barrell said that beyond tooling, education is the single most important part of accessibility.
“It takes six months to a year to take a developer that knows nothing about accessibility, and to get him up to speed with best practice,” said Barrell. “We recommend that a company sets up a centralised group that manages accessibility, that then is push out its expertise to all those development teams, how do you get teams to do more of that non-functional testing.”
Accessibility testing in the UK
In the UK, the planned European accessibility legislation will be unlikely to have a major impact because the existing UK Equality Act has very similar requirements.
Good public relations, rather than the fear of litigation, is spurring the uptake of accessibility best practice among UK financial firms. Only one lawsuit centering on web accessibility, where the Royal National Institute for the Blind sued the airline BMIbaby, has been taken all the way to judgement in court. Other cases have been settled out of court.
Paul Smyth, Head of IT Accessibility at Barclays said that banks’ concerns go beyond mere regulatory compliance: “We do not think that existing legislation around accessibility is stringent enough. It cannot keep pace with the rapid development of technology. We hold ourselves to a higher standard than either the Equality Act or the European Accessibility Act.” Smyth said that Barclays complies to WCAG standard AA, which is the second level, between A and AAA.
“We want to create a service that’s accessible for everyone,” said Smyth. “Our mantra is: ‘designing for difference.’ As we go down the digital route, we want to make it easier for everyone to use our services. We don’t want to leave people behind.”
There are also good commercial reasons to care about accessibility, says Smyth. “To put it bluntly, pensioners are our wealthiest customers. Why wouldn’t we make sure the site works for them?”
Smyth said that the biggest challenge facing his team is understanding how to integrate accessibility best practice with agile and DevOps approaches to software development. Working in a waterfall model is straightforward provided that project teams consider accessibility requirements from the start. There is a check-list of issues to look out for in the finished product, and any changes that need to be made are flagged up.
“If you find and fix accessibility issues at the end of a large waterfall project, it can be ten times more costly than building in accessibility from the start. With an iterative approach like DevOps we can do accessibility testing often,” said Smyth.
Members of Smyth’s team embed themselves to projects, providing tooling and training to developers and testers. They reuse design patterns, style guides, and component libraries. If they can get accessibility right at the component level, explained Smyth, then they are more likely to get it right with the finished product.
Steve Green, managing director of TestPartners, a testing firm that deals with accessibility issues, is more pessimistic. Awareness of accessibility peaked ten years ago. Since then, said Green, there has been a decline. He blames at the feet of popular development frameworks like JQuery of AngularJS. “They provide great out-of-the-box functionality, but the trade-off is that accessibility is much worse,” said Green.
These frameworks are compilations of code and tooling that accelerate development. The problem is, according to Green, that the creators of these frameworks often ignore accessibility issues.
The problem is compounded by the myth that certain frameworks come with “baked-in” accessibility, which is simply not the case, he said.
New technologies can be an obstacle to improving accessibility, said Green, because they create an increasingly diverse range of customer interfaces and platforms. And as time-to-market becomes a key driver of app development processes, many banks simply are not willing to delay a product launch to make sure that it is accessible, he added.