Forms Digitization and Modernization: Guidance for Incorporating WCAG Compliance Into Your Redesign

Accessibility_WCAG_blog_daniel-ali-ju1yFZkrxVg-unsplashFor firms focusing on digital transformation, customer-facing forms are an area that got a lot of lip service but little true attention. But COVID-19 highlighted the problems with the document- and form-centric processes - which are critical for customer onboarding and servicing processes in financial services and insurance firms, particularly those requiring retention of documents of record.

Firms need to get business done without meeting clients in person and without relying on mail. But when firms accelerate their move to digital forms, they quickly realize that they have a much larger inventory than they realized, and a myriad of complexities and requirements they must address.

One of these requirements is accessibility for people with disabilities, which apply to online forms experiences just as they apply to online Web and mobile application experiences. This paper provides an overview of the requirements and offers practical tips for addressing them as part of your forms digitization initiative.

How Accessibility Laws Apply to Digital Content

Laws like the Americans with Disabilities Act (ADA) provide regulations for companies to ensure facilities are accessible to people with disabilities, whether that means widening a doorway, setting designated nearby parking, or offering an entrance ramp instead of stairs. We can easily visualize these modifications to a building and readily accept them as tools for accessibility. But what about when the accessibility barriers are online, instead of in person?

This is where the Web Content Accessibility Guidelines (WCAG) by the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) comes in. The WCAG’s stated goal is to provide “a single shared standard for Web content accessibility that meets the needs of individuals, organizations, and governments internationally.” In order to meet this goal, the WCAG specifically outlines how to make Web content accessible for people with disabilities.

If this sounds outside of your wheelhouse of expertise, it’s because it probably is. 

The WCAG is a technical standard primarily intended for Web content developers and the like. However, if you’re a marketing or customer communications director for a bank or insurance company, this technical standard matters because it results in good practices for user experience and increases accessibility to your services online (where a lot of your clients are). It also matters because there are consequences for being WCAG non-compliant, whether that’s losing your clients online due to poor user experience, unfinished online forms necessary for capturing data and doing business, or even facing a lawsuit due to inaccessibility for disabled users.

“If a citizen feels that the website discriminates against them for a disability, then they can file a complaint or a civil suit and try to force the business to fix it,” says Eric Stevens, vice president of marketing at 4 Point. “And this is really the central problem — the combination of lack of clarity, civil litigation as the enforcement method, and a general willingness to engage in litigation in the US could create a significant problem for companies that do not make their Web content accessible as soon as they can."

WCAG Requirements and Success Criteria

The WCAG lays out requirements and success criteria for organizations to modify their Web content and make it accessible to people with many different disabilities, including:

  • Blindness and Low Vision 
  • Deafness and Hearing Loss 
  • Speech Disabilities
  • Photosensitivity
  • Limited Movement

The WCAG guidelines aren’t meant to address every user need for people with these disabilities, but to make content more accessible to a wider range of people with disabilities, including older users with changing abilities due to aging. It even includes criteria for mobile devices.

Get the Whitepaper version of this post.   Click here for your copy.

The WCAG is all about clarity and comprehension — ensuring that content is clear, understandable, and communicates the right intent and information to the audience. But those ideals — clarity and comprehension — are cornerstones of good user experience. Here’s an example of how making things easier for users with disabilities improves the user experience for everyone :

  • Imagine a Web form that is designed to capture information, such as name and address, from a user. Now imagine that the developer didn’t take the “tab order” into consideration (which happens a lot). The developer was expecting people to click into each field in order to select it and enter their information. But that experience may 2 make it difficult for a person with disabilities to navigate the fields since they would often use the tab key to move between fields. If the tab order is not correctly defined, then the fields are not in order, and the person filling out the form would need to think about which field they just got jumped into.
  • Now we implement proper compliance. We put in a correct tab order, and the movement between fields makes sense for anyone using the tab key. Any fields that “auto-tab” and move to the next field when you finish the previous field will now move to the next logical field. This simple change makes a big difference for everyone who uses the form content. The same applies to labels on fields. Making them clear and informative helps everyone.

Ensuring Web Content Accessibility through the WCAG

For many organizations, the requirement to add accessibility to their online content is an opportunity to rethink how they use forms, how they gather information from their users and customers, and to implement a comprehensive and powerful architecture that allows them to comply now and in the future. WCAG defines four key principles that should be used to plan out the changes required to make your Web content accessible:

Perceivable - the need for content to be seen and used by people with different disabilities. For example, images should provide a text-based description that allows screen readers to tell a visually impaired person what the image is. Many organizations may feel they’ve complied with this requirement with the addition of “alt-text” to images, providing generic alternative text to describe an image (e.g., “cake”) rather than a fully descriptive ones (“A three-layer cake, with chocolate frosting and strawberries on top”).

Operable - the requirement that the website and the content can all be navigated and used effectively for a person who might not have the ability to operate a keyboard or a mouse. This includes providing enough time for users to navigate the site, the ability to select a button using non-traditional input devices, and avoiding content that causes seizures or physical reactions (e.g., anything that flashes more than three times per second). This principle also describes the need to make it easier for users to find content and navigate to the information they need.

Understandable - the need to make the content clear, readable, and understandable. It also describes how the website should behave in predictable ways. This helps users avoid errors and also makes it easier for them to correct errors.

Robust - describes how the organization should build accessibility into their processes so that future changes are immediately accessible, and they won’t need to re-do development or content every time they add new features to the website.

These principles are listed in order of “easiest” (perceivable) to “hardest” (robust) in terms of implementation, though all four are required to meet accessibility for users with disabilities.

"Robust: that’s hard. Period,” says Stevens. “Making any system or application robust can be a challenge for any software developer. That’s why we spend so much time on architecture and scalability: to ensure that the solution will operate correctly for all of the volumes and use cases we expect. But being able to predict all the different combinations and use cases and how people will see, or hear, or interact with all aspects of the content and the Web environment is extremely difficult."

Despite the challenge, this new architecture will also help the organization eliminate manual activities, link front and back-end systems more effectively, and reduce operation costs — all while improving customer experiences and customer satisfaction.

The WCAG’s Testable Success Criteria

In addition to the 4 key principles, the WCAG also defines testable success criteria. These success criteria are assigned to one of three levels of compliance, including A, AA and AAA. Some examples of the differences are shown below.

 



But implementing the WCAG can be difficult, time-consuming, and sometimes out-of-reach with the current technologies used by many organizations. At many firms, the source for forms is not a Web content tool but rather a generic tool like Word - which has very little capability to add in accessibility features to meet the WCAG, and making them compliant would require re-building them entirely. In other cases, the forms were originally developed as part of a line-of-business application, and thus requires significant re-coding and even new development in order to make them compliant.

Key Questions to Ask

When considering accessibility requirements, recognize that forms can exist in many formats, each of which may require a separate process to make accessible. To get a handle on it, we recommend asking the following questions about your forms:

  • How critical is this form to your business?
  • How important is this form to the customer?
  • Who fills it out?
  • Is the form used in a “print, fill, and send” style?
  • Is the PDF form used for “fill, print, and send”? Is it used for “fill and submit”?
  • Do you provide multiple formats (e.g., HTML and PDF and Paper) for a single form?
  • Is the form used for a physical “wet” signature as well as e-sign?
  • Is the form assembled using back end data?
  • What happens to the data on the forms that are submitted?
  • Who owns this form?
  • Who maintains this form?

Building Accessibility Into Your Form Digitization Project Scope

When companies conduct an audit and assessment of what needs to be changed for both digitization and compliance, they often realize that primary customer-facing forms and documents are generated for the users from back-end systems or based on old technology. 15% of medium and large organizations have more than 5,000 forms - and 20% of organizations don’t even have an accurate count of how many forms they have.

"Lack of understanding of the scope of the project is I think the major pitfall or problem companies will have,” Stevens says. “We work with a lot of organizations who don't have a good understanding of all of the web content that they have and show to all their customers, stakeholders, and constituents. If you don't know where all the content is, and you don't know who owns all the content, and you don't know what the content is used for, then making it accessible will be a challenge to say the least. Being able to find and describe

Once firms get a handle on their total inventory of customer-facing forms, we recommend that they address accessibility requirements as part of a more comprehensive approach to digitization that includes the following elements :

  1. Rewrite — Improving readability and ease of use, limiting jargon, and improving the customer experience.
  2. Redesign — Updating the look and feel of forms to improve experience, meet brand standards, and address new digital delivery channels and their requirements (including accessibility).
  3. Refactor — Creating a modular approach to content management and reuse to save significant time and effort in the document creation and maintenance processes.

Given the complexities involved in getting accessibility right, we encourage firms not to short-change it. If you include it in your initiative from the beginning, it becomes a part of your new, efficient operating model. If your organization is one of those with thousands of forms, try beginning with a priority order in small batches of 20-50 depending on volume or complexity, or putting similar forms together based on form functions, departments, or fields. Once you’ve implemented redesign, accessibility, and modularity, then it’s time to test and deploy.

Compliant forms will result in reduced costs, improved user experience, happier and more engaged customers, and a new standard for forms with accessibility already in place.

Need help with digitizing and optimizing your forms? Click here to get in touch with us.

This whitepaper was a joint effort with 4Point, a leading services and solution provider for Adobe Experience Manager, Marketo, and related solutions. 4Point is an Adobe Gold Solution Partner and works with major organizations to help them automate their processes, improve their customer experiences, and reduce their operating costs. 

Photo by Daniel Ali on Unsplash

Rich Medina
Doculabs Vision Team
Our blogs are a group effort, from writing to editing to brainstorming topics. We collaborate to provide you with our best thinking that will help you use technology to improve how your organization operates. The Doculabs blogging team is Richard Medina, James Watson, Marty Pavlik, and Tom Roberts.