“The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.”
— Tim Berners-Lee
Websites, applications, and other digital platforms are often not built accessibly and exclude users and visitors who have disabilities. When software is not built to accessibility specifications, remediation is often a valid solution for complying with all contractually-required accessibility standards.
The Federal Government requires Vendors ensure and document that all electronic and information technology (EIT) sold to the government is equally accessible for all users and meets Web Content Accessibility Guidelines (WCAG) success criteria.
Under Section 508, agencies must give disabled employees and members of the public access to information comparable to the access available to others. In March 2017, the U.S. Access Board published a final update for Section 508's accessibility requirements for information and communication technology (ICT). The update was intended to provide a stricter definition of “accessibility,” and to bring the requirements in line with the technology of the 21st century.
Section 508 compliance testing is the process of checking information and communication technology (ICT) to ensure it meets accessibility requirements. ICT includes all pages of your website, software, applications, intranet sites and tools, and electronic documents.
Begin accessibility efforts auditing the task flows on your application that are most frequented by your users. Review your most commonly used templates and top-visited pages, and then scale your efforts from there.
The Web Content Accessibility Guidelines (WCAG) are organized by four main principles, which state that content must be POUR: Perceivable, Operable, Understandable, and Robust. WCAG is the most-referenced set of standards in website accessibility lawsuits and is widely considered the best way to achieve accessibility.
Information and user interface components must be presented to users in ways they can perceive. This means that users must be able to comprehend the information being depicted: It can't be invisible to all their senses.
User interface components and navigation must be operable: The interface cannot require interaction that a user cannot perform.
Information and the operation of a user interface must be understandable: Users must be able to understand the information as well as the operation of the user interface.
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies: As technologies and user agents evolve, the content should remain accessible.
It’s important to know the differences between automated testing, manual testing, and functional user testing because each method catches different types of accessibility issues. Manual and Assistive Technology User testing pick up what Automated testing cannot.
80% of WCAG success criteria requires some type of manual review and verification. For example, when using automated and manual testing in the physical world, automated tools can check that you have the streets labeled at an intersection, but manual testing makes sure those street names are actually correct.
Ultimately, the end goal of accessibility testing is to identify barriers that need to be removed so that all people—regardless of ability—can perform the same functions on the web. Focus on making user experience (UX) inclusive for all.
Automated tools and software can test for accessibility as a gate within the software development pipeline, and they come with varying benefits and features. For companies that want to improve web accessibility, automated testing tools alone can only get you so far. These solutions can determine pass or fail for only about 20-30% of WCAG success criteria.
Web applications should be usable for people of all abilities. As advanced as software is, there are still plenty of situations where an algorithm can’t recognize the nuances of website accessibility or usability. Because of this, manual testing provides the most detailed feedback about accessibility defects.
Manual accessibility testing is the process of inspecting your website or application by hand to check for accessibility issues that may cause a problem for users with disabilities. This type of testing is critical for catching issues that may not be caught by an automated test. Seventy percent of WCAG success criteria require human review in order to properly interpret criteria and navigate gray areas outside of technology’s purview. For example, to be accessible, an image must have alternative text that is meaningful, but the mere presence of alternative text doesn’t guarantee that it is meaningful. A human must look at the picture and the accompanying text to determine whether or not the text accurately describes the image.
In WCAG 2.0 AA, 34 of the 38 success criteria need to be manually reviewed by a human. WCAG 2.1 AA increased the need to conduct manual accessibility tests by adding 12 new success criteria that all need to be tested by humans and cannot be tested by automation. WCAG 2.2 takes this even further.
The point of testing and remediation is to ensure that web apps are actually usable for users who have disabilities. In addition to meeting WCAG success criteria, functional test the application with people who use assistive technology, such as screen readers and speech command/dictation software. Testing with AT software packages helps confirm the the site or app accurately operates including:
When you involve people with disabilities in your testing process, it helps your company and employees build empathy and understanding for the people who use your site and the challenges they experience. You may have willing assistive technology users within your company, and there are quality digital accessibility services that can provide AT users to test software/apps, including Fable and Knowbility.
Accessibility remediation is the process of bringing your digital assets — such as websites, applications, and documents — into compliance with recognized standards of accessibility with the goal of providing a better user experience for all users. Typically, accessibility standards are based on Web Content Accessibility Guidelines (WCAG) 2.0 or 2.1:
Any accessibility remediation effort will first start with accessibility audit services. By evaluating and testing the enterprise web application, mobile app, and electronic documents against WCAG 2.0, Section 508, or other recognized accessibility standards, both your team and ours will discover what accessibility issues need to be addressed and in what priority.
After the audit, we will work with your development team to document how to proceed in for defect tracking software, explaining what accessibility issues need to be fixed, with appropriate levels of priority. Many digital assets can be remediated directly by either your in-house team or our accessibility specialists; others may need to be recreated or converted to render them fully accessible. Still others may be third-party components that need discussions with those providers to move that component closer to being fully accessible.
Accessibility remediation services are available for:
John excels in accessibility audits, remediation, and accessible website/application development with considerable history providing application development, training development, and accessibility consulting services to corporations, non-profits, state and federal agencies. This expertise has been leveraged to create, remediate, and maintain some of the largest government sites within the United States operating under Section 508 and WCAG 2.1 requirements.
6-12 month engagement per enterprise web application, while integrated with Vendor development team.
The VPAT®, which is a template developed by the IT Industry Council (ITI), is the most common method for completing an ACR since it provides all the relevant Section 508 Technical Standards and instructions on how to complete a report in one tool. While the use of the VPAT® itself is not required, it is not voluntary to complete an ACR if you wish the government to consider purchasing your product.
The Voluntary Product Accessibility Template (VPAT) is a standardized document that explains how information and communication technology (ICT) products such as software, hardware, electronic content, and support documentation conform to the Revised 508 Standards for IT accessibility. The VPAT provides specific statements in consistent language to demonstrate how the features of the product meet the required standards.
VPAT documents are a good way to respond to the accessibility requirements of Government RFP/RFQ solicitations. VPATs help Federal agency contracting officials and assistive technology users assess ICT for accessibility when doing market research and evaluating use.
Industry is expected to test its products against the applicable Section 508 Technical Standards and then report which standards the product supports, partially supports, or does not support. This is so that the agencies can consider accessibility when purchasing the product. This information is provided by industry in the form of an Accessibility Conformance Report (ACR). If the product supports all of the applicable Section 508 Technical Standards, the product is considered compliant with Section 508.
Yes. Completing an ACR is a win-win situation for industry and the government. When industry develops an ACR, it opens the door for the federal government to purchase your product. Your ACR shows customers that your company takes accessibility seriously. Even if the ACR shows that not all the applicable Section 508 Technical Standards have been met, it allows your product to be evaluated against comparable products for accessibility. If you have an ACR and a competitor’s product doesn’t, you will always be the most conformant with the Section 508 standards. Completing an ACR raises your awareness of your product’s accessibility and allows you to take steps to make your product more accessible and reach a broader customer base.
About 2-3 weeks to test and either create or update a VPAT, per web application.