Website Accessibility
This article summarizes some of the lessons I have learnt enabling our web application to meet accessibility standards. I don’t plan to set out here why this is important; the purpose of this article is simply to help anyone in a similar position.
I think it needs to be made clear at the outset that at a technical level there is nothing in the accessibility standards that adversely impacts the functionality of a website. Meeting accessibility standards is simply a sign of good design, planning and structure, and will likely enhance any website by making it easier and more predictable for everyone.
Background on Accessibility
Web Content Accessibility Guidelines (referred to as WCAG), developed by the Web Accessibility Initiative, can be found on the W3C website. This initiative is designed to develop web accessibility guidelines, technical specifications, and educational resources, through a process designed around broad community input and consensus development.
WCAG documents explain how to make web content more accessible to people with disabilities. For this purpose, web content generally refers to the information in a web page or web application, including:
page layout including text and images,
embedded information such as video and sounds, and
code or markup that defines structure, presentation, etc.
WCAG, currently in version 2.1 with 2.2 due in 2021, addresses issues such as poor visibility due font size or page contrast, the ability to navigate using only a keyboard, style of language, and embedded elements such as videos. Although it is unfair to summarize it so succinctly, which is why I recommend reading the source material.
Additional information can also be found at:
Accessibility Insights from Microsoft,
Developer Support from Apple, and
Accessibility from Google.
Useful Tools
There are many tools available to test your website, here are some we use:
axe from deque. I personally use the chrome plug-in, but they have a range of tools available for developers.
Screen Reader – Safari has a built-in screen reader, for Chrome I use this plug-in. It should also work on Edge.
Another handy plugin-in for Chrome is Accessibility Insights.
There are many many more.
Organizations often use external consultants to review and report on their website accessibility; these can be useful, but I feel it is akin to offloading core design functionality of your website. Accessibility should be viewed as a core feature and incorporated in your design and strategy – not an issue to be fixed later.
Challenges We Encountered
RiskDX is a sophisticated web application designed so that the user can complete an online insurance application, underwriting is completed in the background in real time and the policy is delivered to the applicant. The questions we use for the underwriting application take advantage of just about every form of input.
One input type, in particular, is a slider; for most users this is a more convenient form of input than entering text, especially on a mobile device. However, it is less than ideal for someone using a keyboard as their primary input, even though it works.
Branding is another challenge we face, as our system is branded to match the client’s brand; hence we have no say regarding potential contrast and font size issues, although it is our experience that most insurance companies have a brand guidelines that are compatible with the accessibility guidelines.
These two issues (input and branding) are effectively addressed the same way. The standard presentation of our application, used by most users, is accessible using a keyboard, compatible with screen readers and meets other standards to at least be “Level A” accessibility compliance. In addition, we added an accessibility icon in the footer of the webpage that:
switches to alternative keyboard-based inputs, for example replacing the slider with text input, and
removes some of the brand formatting such as background colour and links identified soley by colour.
A switch in the footer is used in many websites to switch to high contrast, although I think we have taken the functionality further than most. We also make the footer icon larger than I see in many sites, and one of our developers, Gnaneswar, also had the idea to include instructions explaining how to navigate using only a keyboard as this may vary from one website to the next.
I also hope that this icon will encourage feedback as to how we can improve since meeting the letter of the guidance is not always sufficient.
Fortunately, we do not have videos or other media that would need to be addressed.
Moving Forward
I am not an expert on this topic and there are many issues to consider (which is why the guidelines are community developed). We plan to enhance accessibility as we continue to develop our software and all new features will consider accessibility in advance.
For an application such as RiskDX, it is easy to dismiss accessibility requirements as being too complicated, and, since we integrate options to purchase through an advisor and provide call-centre support, it is still possible for anyone to purchase insurance. But everyone deserves the options our software is designed to address: the convenience of completing an insurance application anytime you want and not having to talk to someone if you don’t want to.
We have added accessibility functionality to our core system so there is no additional cost or effort for our clients. Hopefully, I will see accessibility as a requirement on RFPs in the future, unfortunately it wasn’t on the last one I was sent.