Common Defects and Consequences of Web Accessibility Gone Wrong
Web accessibility is increasingly becoming a concern for nonprofits and businesses, large and small. In Ontario, for example, there has been a slow rollout of regulations that affect most industries and nonprofits. However, a government mandate finally arrives on January 1, 2021 in the form of Accessibility for Ontarians with Disabilities Act (AODA) digital compliance. Any organization that qualifies for mandatory compliance must have their public digital assets (e.g., websites, downloadable PDFs) up to spec by this deadline. (Digital assets for internal use need not be compliant, but I’m sure one’s employees and volunteers would certainly appreciate it.)
Other provinces (and other countries) may also have regulations and mandates, including penalties for non-compliance. However, they all have one thing in common: the WCAG as their accessibility foundation.
What are the Web Content Accessibility Guidelines?
As an evolving, internationally developed accessibility standard, the Web Content Accessibility Guidelines (WCAG) is freely available documentation outlining web accessibility success and failure explanations and criteria. It is to the WCAG that everyone turns to for their accessibility requirements because it is nation agnostic, focusing instead upon usability.
The WCAG is broken down into three tiers: A, AA, AAA. The tiers indicate items with the highest impact on accessibility (A) to those that improve an accessible experience but are not essential (AAA.) In Ontario, regulations will require affected organizations to be compliant with both A and AA standards. Other provinces and countries may vary, but such a degree of compliance is typical.
Common Web Accessibility Compliance Hurdles
Making one’s digital assets web accessibility compliant can be much more difficult than expected. There are numerous tools to help make testing for compliance easier, but none are perfect. Such tools will only catch an estimated 25% to 33% of potential accessibility defects on typical websites. Much of the WCAG is contextual and subjective, so automation has difficulty testing for these aspects.
Some of the problems I’ve found that automated accessibility testing tools overlook:
- Consistency: Currently, the most widely used accessibility testing tools don’t check for consistency across multiple pages within a “series.” Consistency across pages is vital for user expectations of similar components doing the same thing in different instances. There are non-accessibility tools that can perform this function (e.g., sitemap tools), but they lack any other accessibility capabilities. This means either using a mix-and-match of various tools or constantly manually referencing an internal standards document. On big websites, this poses a high risk of overlooking consistency defects.
- Content: Content cannot be codified and quantified, for the most part. The WCAG often presents its accessible content guidelines in vague terms like (to paraphrase) “being logical” and “being in an order that makes sense,” beyond using content for labeling and the like. Most content-related WCAG requirements are beyond testing tool capabilities due to subjectivity and context not expressable as quantifiable metrics.
- Image Context: Automation has no way of discerning between decorative and informative images. It cannot, for example, discern if an image has text on it requiring an ALT attribute. Similarly, automation doesn’t test for how web accessibility requirements change if an image is made functional (e.g., it is a clickable link.) Likewise, testing tools cannot tell if an image provides information already available in adjacent content, thus repeating itself if added to the image’s ALT.
- Component Combination Conflicts: A website can meet all coding, content, and design compliance requirements when viewed in isolation. However, testing tools are very limited regarding how they check if these components combine in an accessible fashion. For example, otherwise compliant code, design, and content can result in a user experience that makes sense to people viewing it on screen but is confusing to screen reader users.
Relying too heavily on web accessibility testing tools rather than human testers with sufficient knowledge and awareness can be catastrophic. Competent and empathetic testers are necessary to spot by eye everything that is missed by testing tools or reads as a false negative.
The Costs of Web Accessibility Compliance Defects
Don’t lose sight of the figurative and literal costs of failure when determining budgets and project time frames for web accessibility. Often, quality assurance (QA) alone is tasked with accessibility testing, almost as an after-thought. It is kept for the workflow’s end instead of something to be checked during the entire digital production process. As a result, defects are identified when there isn’t enough time remaining in a project’s timeline to go back and fix them. Instead, they get greenlit to “fix later.”
Accessibility compliance doesn’t care that you didn’t efficiently budget or plan your production timeline, however. All that will matter is you’ve left a web accessibility defect in your digital asset, and that defect is discoverable and a risk.
In Ontario, potential consequences for failing to meet A and AA requirements include:
- Enterprise Fine: A $100K maximum fine per day for non-compliance.
- Individual Fine: Directors and organization officers face their own separate $50K maximum fine per day. These fines arise when the individual made choices knowingly producing defects. Such decisions are why managers who don’t take accessibility seriously are a high risk.
- Inconsistent User Experience: Bounce rates go up, and conversions decrease because users have difficulty interacting with digital assets. Not only does this result in reduced client satisfaction, but increases the likelihood of users going to competitors who offer a more accessible experience.
- Messages are Altered or Unclear: Inaccessible messages can result in miscommunications and misunderstandings. Users become confused, and legal and financial liability may increase. For example, offering a rebate of $300 with a “1” superscripted after to indicate a footnote will, if the footnote isn’t made accessible, be a problem. Superscripting is a purely visual cue, so screen readers ignore that part of the intended context. A screen reader will read the rebate as “$3,001” rather than “$300” without informing the user of the footnote. Consider the financial and legal ramifications of such a miscommunication.
- Impedes Full Usability: Some website functions will be too confusing for accessibility technology users. In some cases, screen reader users will be completely incapable of completing the intended task.
- Civil Lawsuits: Users can directly sue the company, potentially costing far more money than the government’s fines cover.(Also, the costs can be in addition to the fines.)
When considering risk, most organizations focus on the enterprise fine and lose sight of the rest. (Indeed, the organizations I’ve helped with web accessibility were surprised when I brought up the individual fine. They were entirely unaware of it.) Now that you know some non-compliance consequences, let’s look at how compliance defects get missed.
Web accessibility defects survive through production to go live for several reasons. The most common is that no one successfully identified the defect in time. Another is a decision-maker who isn’t prioritizing accessibility. They may refuse to fix the defect because it alters their preferences or plans. Instead, they push the defect through. How the latter happens should be obvious, so let’s look at some causes of the former.
- Disconnected Decision-Makers: In my experience, decision-makers overseeing accessible projects from afar rarely have an adequate level of web accessibility knowledge. They likely grasp the basic, most frequently seen issues and want to leave the rest to the teams involved. Unfortunately, this lack of understanding results in them approving defects. Not wanting to lengthen their timetables to suit the duration required for proper testing is another common issue.
- Contractor and Consultant Reliance: For quite some time, large enterprises have been increasing their reliance on temporary employees. Unfortunately, this results in a reduced understanding of the company’s standards and best practices without much loyalty to the employer. Without proper incentives, a temporary employee will frequently do what they’re asked and no more. So, a web accessibility consultant or contracted auditor will use the tools, means, and goals required by the employer. However, these temporary employees may not put the extra effort in to pursue defects the tools miss. Temporary employee turnover also means having to take time to train new employees, eating away at project timetables managers are already unwilling to modify.
- Testing Tools: All accessibility testing tools (e.g., Axe, Wave) have shortcomings ranging from producing false positives or false negatives to not competently identifying certain defect types. All current tools fall short when it comes to testing content, consistency, user experience, and context. For example, consistency across pages is critical, but testing tools check pages individually, in isolation. Even the leading, paid testing tools will miss a lot.
- Inadequate Training: I’ve yet to be involved in a web accessibility project that hasn’t suffered from poor or absent training. Some organizations have training sessions annually or semi-annually, but their employee turnover means it can be months before new employees receive training. Also, longer-term employees frequently don’t update or refresh their knowledge. A critical aspect of training I’ve yet to see adequately addressed is empathy and awareness building. These talents are difficult to train for but are essential for accessibility work that can think beyond a checklist to find defects testing tools miss.
- Lack of Standards: Logically, you’d think the first thing a nonprofit or enterprise would do to address accessibility is to create methodology and content standards. And yet, such a standard is more often than not woefully inadequate, incomplete, or doesn’t exist at all. How can the organization provide consistent web accessibility solutions if they have no standards of consistency?
- Project Scope and Management: A properly accessible digital workflow requires baking processes and quality assurance (QA) in from start to finish. Currently, accessibility is often relegated to the QA stage, which usually comes at the end of a production timeline. Unfortunately, if there is something seriously wrong, too often there isn’t sufficient time remaining to solve the problem or pivot to a new approach.
- Disgruntled Employees: A common problem for organizations that make extensive use of temporary employees is them leaving with hard feelings. It is common for temporary employees to feel like they are an abused, casually tossed aside, and undervalued resource. Now consider what can happen if an angry employee who was deeply involved in your web accessibility solutions wants to get some revenge. They leave the organization knowing where the defects are and can point them all out to the government. A single disgruntled employee with this sort of knowledge can result in plenty of fines.
- Not Prioritizing Accessibility: Regardless of government mandates, many organizations don’t take web accessibility requirements seriously. They are seen as a “nice to have” or an extra rather than a necessity. As such, when enterprise goals and intentions butt heads with web accessibility requirements, the latter far too often gets bypassed or ignored.
- Legacy Webpages: Many large organizations in Ontario have waited to the proverbial last minute to start tackling web accessibility. As a result, most will not have enough time to make their entire website accessible before the January 2021 AODA deadline. So, what is the plan for dealing with these old webpages? In most instances, not too much. The plan is to leave them as they are. My suggestion to clients has been to create a priority list of their webpages. Start with what must be made accessible before the deadline because they are too valuable to the company’s goals. Assign the least priority to nonessential and rarely used pages. Turn off and redirect low-priority pages place until they are fixed once the deadline passes.
What’s Next for Accessibility?
A properly accessible digital production process takes a lot of work, training, and awareness. Workforces affected by government-mandated web accessibility cannot afford to not understand. In Ontario, looking for a job in web production after January 2021 will require accessibility be part of your skillset if you hope to get hired. Most managers and other hands-off executives don’t realize that this applies to them, too, because employers can’t afford to have anyone making misinformed decisions.
If accessibility skills are something that will affect you (if they don’t already), look for courses in your area. I would suggest you do so with the understanding that they are going to take a “checklist” approach to the subject, however. Such programs likely won’t do much to improve your awareness or help you think outside the box, so find ways to keep learning on your own.
If you would like to see me write a blog on a specific web accessibility problem, process, or concern, email me at Steven Trustrum or leave a comment for this article.