Do you really care about accessibility? Stop box ticking!
We need to think about accessibility as not only ensuring web content is accessible but making sure that a culture of accessibility permeates through an entire organisation.
A culture of accessibility will mean the online services and experiences we create are truly accessible and usable.
Accessibility is not just a technology problem; it’s a service delivery problem which touches many parts of an organisation. You create online services according to the accessibility guidelines, you check the content for its accessibility, and then you sit back and think job done?
If we just think about accessibility as a technology problem, then we’re just looking for ways to make sure that we’re compliant, we’ve achieved some subjective rating against a standard. Which in theory is great, but web accessibility is not always so straightforward.
When we’re creating online experiences, we need to make sure that everything produced is accessible, but by solely focusing on the end experience for the public, we are potentially hindering our efforts in other areas. Take for example procurement.
Considering accessibility in procurement
Procuring software is where accessibility requirements must be added in from the start. If we’re purchasing a content management system or a development tool we don’t want any content produced by that tool to be inaccessible.
Buying accessible software will mean our future accessibility efforts will be easier as the product already has that support provided.
Push your technology vendors to be as specific and honest as Drupal over its accessibility compliance
However, asking if the product is accessible leaves us at the mercy of the vendors. It’s in their best interest to put a positive spin on their product. When we ask if their product is accessible, the provider will typically answer yes, even if the accessibility is so narrowly defined to be practically unusable.
Make sure vendors prove their software is accessible. Don’t accept what they say as truthful and accurate.
Rephrasing the question can get a more definitive response, ask, “has your product been tested for compliance against WCAG 2.0“.
We can go further still and ask whether their product is independently audited for web accessibility and can we view the report. Put the responsibility on the vendor to prove they understand what is required, don’t accept what they say as truthful and accurate.
Before purchasing anything, organisations will need to do their due diligence that the software to be procured is fit for purpose.
Potential procurements undergo security checking, and stability checking so why not include accessibility checking? Run a few online checking tools over it, ask for test accounts to be set up and if possible get assistive technology users to see if the claims they make are truthful.
This will allow you to focus your energies on other areas, like getting your developers up to speed.
Training developers in accessibility
Training developers is where significant improvements can be made, after all, they’re the ones creating the online services. It’s important to know that accessibility guidelines are difficult to understand and have a lot of confusing statements – for instance, the WCAG 2.0 guideline on colour contrast doesn’t read particularly well.
Developers have too much work to do already, and unfortunately, web accessibility is a non-core skill for many. A skill that needs to be understood.
You can’t expect your developers to fully understand any accessibility specification and be confidently able to apply it. It takes time and effort to understand a specification and its nuances entirely. Look at ways in which you can make it easier for them to build in accessibility.
I believe that people do not want to make average online experiences or ones that are deliberately difficult to use, but they often have competing priorities and time frames.
That’s why making it easier to build in accessibility support is so crucial. Can you introduce easy checklists and procedures that developers can follow while developing? Procedures that can become part of their skill set.
Look at breaking down the accessibility compliance into easy tasks which developers can perform in the context of their everyday work. For example, when they create a component they check that it’s keyboard accessible and has sufficient colour contrast.
Some accessibility techniques are as easy as including extra attributes or using the HTML elements in a way which the specification intended. That quickly fixes some of the more obvious accessibility problems.
Build empathy and understanding with the developers by humanising their work. Emphasise the fact that their work has an enormous positive benefit for people who rely on the support that comes with well-built tools.
YouTube has great videos of assistive technology users navigating websites that developers have failed to build correctly. These can serve as excellent examples of what not to do. By making it relatable, people can begin putting a face to why accessibility is important.
Make it easy for your developers to source accessible components internally between teams, and make it straight forward to apply.
Style guides and reusable pattern libraries can help as well, don’t go reinventing the wheel unless necessary.
The Australian Government's design system has many repeatable patterns which has accessibility built in
If you have a component or design pattern that you have proved works, use that. Make it easy for your developers to source accessible elements internally between teams, and make it straightforward to apply
The impact of security on accessibility
Security is an often-overlooked area of web accessibility, but it can undo all your hard work. Many large organisations will have IT security policies for securing web based systems, one of the most popular methods is with CAPTCHA.
These terrible obscured text and image challenges ask the person to confirm their “humanness” by completing a puzzle or deciphering the text.
Captchas are a pain for any user and a real barrier if they have an impairment. Understanding the text, deciphering an image, interacting with a keyboard are all challenges if the user has a cognitive, vision or mobility impairment.
Asking a user to confirm if they’re human before they can interact with your service, that’s a really lousy user experience full-stop.
The technique may be good for security, but it’s terrible for accessibility, and asking a user to confirm if they’re human before they can interact with your service, that’s a lousy user experience full-stop.
You can’t confidently say you have an accessible website if you use captcha. Current captcha implementations are not accessible
Google now promote an invisible captcha, which isn’t shown at all, great stuff, but what’s the catch? It will revert to the image challenge if it detects erratic user behaviour. As you can’t be 100% certain of your users never seeing that problem, you can’t confidently say you have an accessible website if you use captcha. Current captcha implementations are just not accessible.
Instead of captcha consider alternative methods. Combine multiple security measures, including checking how long it takes for a form to be posted, a hidden form field that attracts bots and email verification. If one method is compromised, you have fallback options of two more.
However, a pragmatic approach to security must be taken as well. There may be instances where captcha is used, and you can’t change the outcome.
In those instances, build up a support system around it, so if a user cannot use the captcha, they can contact someone within the organisation who can verify them another way, it’s not a great outcome, but it will help.
Motivating management and leadership
To have a long-lasting culture of accessibility, it needs significant understanding and downward push from management. In big, public facing organisations, it’s pretty straight forward to get buy in from management.
The benefits of accessibility
Emphasising the benefits of a good user experience and it’s increase in conversion are significant motivators which result in affirmative action. Also, don’t forget the law is an added motivator, government bodies in particular, must provide accessible web content.
But what do you do when there is significant indifference and a lack of understanding about the benefits?
Make the accessibility of an online service tangible, describe it in terms which will make different groups of people understand and relate to it.
Look for ways which will make people take notice. For example, can you reframe accessibility into one of building a better user experience, which will equal more customers? Can you demonstrate that completion rates of product purchasing workflows increase due to the ease of use?
Make the accessibility of an online service tangible, describe it in terms which will make different groups of people understand and relate to it. It’s a sad fact that sometimes making something accessible because it will help people isn’t as strong a motivator as it should be.
Can you find the business case for emphasising accessibility, can you sneak accessibility into the design?
The dangers of ignoring accessibility
The threat of legal action is another significant lever to pull. If your attempt to highlight the positive aspects have failed, the risk of legal action can be what makes people take notice. If the organisation is in danger of being sued, this can often be the final straw to prompt change internally.
A good example is a recent case in Australia concerning a vision impaired woman, who had difficulties over many months of using a supermarkets online ordering.
She attempted to contact them many times, and the updates the supermarket put in place didn’t work. Reluctantly she took the case to the Australian Human Rights commission where they attempted to mediate with both parties and find an acceptable outcome.
When that too failed, she reluctantly took them to court for breaching the Australian disability discrimination act.
That resulted in the supermarket settling out of court and fixing their website and online ordering. If they had implemented accessible features initially and listened to customer feedback, a costly court case and bad PR could have been avoided.
Appoint an accessibility champion
Designate an accessibility champion in your organisation, a person who’s unafraid to mention when accessibility isn’t the best it can be, and who can educate and advocate for building inclusive experiences, and who reports directly to the senior management.
Accessibility is more than a compliance exercise
You see, accessibility is more than just completing a web accessibility audit once an online service is ready for a production release. If we just think of it as a technology problem, then we’ll always limit our efforts to performing an accessibility audit once an online service is ready for a release, which is a compliance exercise.
Any issues found will go onto a defect list ready to fix on the next update. But retrofitting accessibility never works, at best it’s a sticking plaster which makes something a little more accessible. Instead, build it in at the start, think of accessibility at every stage.
Web accessibility is as much about managing people’s attitudes, perceptions and motivations than it is about correctly coding a website.
I like the message from Mike Paciello of the Paciello Group when discussing web accessibility; emphasise the carrot and not the stick. Treat accessibility as a creative challenge, a challenge of building a better digital product which your users will enjoy.
Use diplomacy to get the accessibility message across, use posters, stickers, presentations. Use multiple approaches and multiple methods to have people understand that it is important.
Both the UK Government and Barclays have produced a range of accessibility posters, even us at CANAXESS provide free information cards and stickers; the support is out there you just need to use it.
Web accessibility is as much about managing people’s attitudes, perceptions and motivations than it is about correctly coding a website.
References
- Blog post originally published in Boagworld 12th September 2017 Do you really care about accessibility? Stop box ticking!