We all know that achieving conformity with the laws and standards around accessibility is something every website should consider a priority. It is the right thing to do, for one, and it is the law, too. But how does a website actually conform to the various standards regarding accessibility? The answer is, it’s complicated. To completely conform to standards, you need to follow a few steps thoroughly and comprehensively. In this week’s post, we’ll review those steps and how to best complete them as you endeavor to be fully accessible to all users.
Testing & Auditing
The first step in conforming to current standards is to test your existing website. Testing, however, isn’t as easy as it sounds. The truth is, no fully automated system makes you genuinely compliant. While some software packages such as Chrome come with built-in accessibility checkers, and other products such as Accessibe allow you to install plugins that can solve common accessibility flaws, they cannot offer a comprehensive solution. In fact, those plugins are not enough to protect you from legal action anyway, as the courts have regularly determined, because they don’t actually remediate any of your site’s functions and require users to exercise additional steps to enable.
To properly test, you need to also consider the human element. While often overlooked by automated tools, the true goal of being accessible is to allow people to use your products. Therefore, testing needs a manual component to determine whether or not a website is contextually conforming.
As an example of this, let’s consider ALT tags. ALT tags are short or “alternate” and are a way to assign text content to a visual element of a webpage, such as an image. Let’s say a webpage has an image of a surfer. An automated system would treat an ALT tag with the description of “Image” as conforming to an accessibility standard. However, a manual, human test would know that the text is not necessarily contextually correct. More appropriate would be a tag that states “Image of a surfer on the ocean” or similar.
This is just one example of the gap between AI and manual testing. Both need to be addressed as part of a testing and auditing regiment. As the test is conducted, it must strictly adhere to the most relevant WCAG 2.1 standards. A thorough audit should list all issues found on all templates and cite the pertinent criteria that failed when appropriately conducted. With these findings, you can proceed to step two: remediation.
Remediation of accessibility audits is the next step in your journey to conforming. Remediation, and the difficulty of completing it, is a highly variable step in the process. For some sites with relatively stable content (IE, not changing often) and limited interfaces or templates – remediation can be a breeze. So many fixes are front-end code dependent and not something that involves backend coding or CMS adjustments (though a CMS may be needed to make some of those adjustments).
However, for sites with complicated integrations or frameworks, remediation can be quite a task. For example, one client of ours is using a CMS that relies on multiple third-party extensions. If the extensions are not conforming, then the site can never be either. Other sites with hundreds of disparate templates can also be massively problematic. All in all, remediation can be a nightmare, or it can be a breeze. Ultimately, that may be determined by how forward-looking you were when initially building the platform.
For remediation to be successful and easy to complete for the developer, whether in-house or contractors, you need to make sure the audit was verbose enough to explain what issues existed and the prescribed fix. In our audit practice, we focus heavily on assisting clients in understanding the specific fixes and how they can best be implemented. This makes remediation easier for those who may not be thoroughly trained in accessibility techniques.
At this point, you’ve audited, remediated… But you have one problem – you may or may not be conforming to the standards. You need to now retest and identify any remaining issues. Sadly, the reaudit is rarely much more manageable in terms of conducting the test. All of the same templates need testing again. But, the process should go faster because the list of items identified will diminish, thus cutting back on report details and ultimately saving time.
Why retest? Simply because there is no way you can have a third party provide you any statement of conformity without knowing that every template was tested, remediated, and ultimately passed a new test.
What if some items still fail? Proceed back to step 2 and remediate further!
The developer in me wants to make one point right now… In testing, it’s easier to test a finalized app or website and not one still undergoing development. Code evolving during testing makes everyone’s life more difficult and could mean you have many rounds of testing before finalizing your accessibility project.
So what kind of documentation can you be provided when you pass your retest? Well, there isn’t any official “certification” per se. But, third-party providers, such as NP Group, can provide you with a “Statement of Conformity,” which would identify that you underwent the process on specific interfaces, and as of a certain date, achieved conformance with the WCAG standards.
You can also seek to develop a VPAT document – either after or before remediation. A VPAT, or Voluntary Product Accessibility Template, is a document that explains how software complies with various requirements for IT accessibility. Since a VPAT is essentially a current situation analysis or status report, it can be done at any point. However, how helpful a flawed report is for your ultimate objectives can prove pointless unless you remediate.
Either way, it should be considered a best practice for companies to develop and publish an Accessibility Statement that shows their commitment to accessibility and inclusion. Having an audit completed, as well as an Accessibility Conformance Report (ACR) or conformance statement, plus a public statement on accessibility are great ways to minimize any threat of an accessibility complaint.
One exciting thing about the web, as a medium, is that it’s ever-changing. Because of this, maintaining accessibility standards is very challenging. This is where automated testing can come in very helpful. Having an ongoing monitoring solution in place can aid you in continuing to conform with the standards, provided you act upon the findings it alerts you to.
Using our example above, a monitoring solution would help you find new content areas that were published, perhaps without proper accessibility standards employed, and alert you to the particular issue. From there, you can fix it in a contextual and relevant way. This is an essential tool for websites that have many administrators, especially in larger organizations.
The other benefit of monitoring is that it will help you if you were approached with a complaint or lawsuit. Most monitoring solutions will have an archive of your activity regarding accessibility, and as such, can shed light on how seriously your organization approaches these problems. Many claims and cases are judged by how proactive the website or company has been in monitoring and addressing these issues. Having a paper trail is very helpful.
Becoming accessible is complicated and, in some cases time consuming, but ultimately rewarding for your organization plus, of course, your users. Taking it seriously and conducting a thorough audit and remediation is the best way to ensure conformance with regulations. Most of all, maintaining that conformance with proper monitoring and a cultural adaptation of accessibility techniques will ensure your company stays ahead of the curve on an ongoing basis.