If you glean anything at all from what’s written below, know this; you SHOULD NOT ignore government issued accessibility regulations. In this post, we’ll discuss Section 508 of the Rehabilitation Act of 1973 (Amended 3/20/2017) in particular, as well as, how it effects you as an eCommerce web-store manager.
As of January 18, 2018, your website should have complied with the section 508-based standards. If you’d rather review the literal letter of the law and skip my handy blog, knock yourself out with this puppy. Over 50,000 words of riveting legal jargon about the updates to the Section 508 regulations relating to, among other things, “…computers, information kiosks and transaction machines, telecommunications equipment, multifunction office machines, software, Web sites, and electronic documents.”
Unless you are yourself a sentient computer, you almost certainly want to skip the step of reading and interpreting the content of this legal document and instead ingest some of the secondary literature on the topic. This blog aims to pull together some of those supporting sources of information, and provide some additional insights of its own. Hopefully I am able to help your organization build a strategy around bringing your website into alignment with ADA Regulations. After all, the deadline was almost a year ago, and big eCommerce players are already starting to feel the wrath of non-compliance. Don’t be one of them.
Speaking The eCommerce Legal Language
For starters, it’s crucial to at least learn the major vocabulary around the subject:
Section 508
- Regulatory law passed to make all communications technology more accessible.
WCAG
- Set of technical guidelines to meet Section 508 Regulations (Managed by W3C- Provides requirements and testing criteria).
VPAT
- Voluntary Product Accessibility Template. Self-disclosing document declaring the current level of conformity with Section 508.
Now let’s break the approach to ADA into three parts
1. Self-Awareness
Before you do anything else, take stock of your current site to determine whether or not your site is in compliance. Depending on the size of your website, your aversion to risk, and, I suppose, the depth of your wallet, there are different tools available to measure your site’s adherence to current guidelines.
Small-Medium Sites: Website Accessibility Checks
WAVE – This one is my favorite as it provides in-context markups with a UI that makes it much simpler to understand. Offering the ability to filter error reporting by Standards (Section 508/WCAG) or by View (Styles/No Styles/Contrast), WAVE is the best tool for understanding the errors on your site and how they would impact users with a disability.
Level Access – Web Accessibility – Just like WAVE, you can run a quick scan based on URL and receive a report back on specific errors your site has when compared to compliance standards. One benefit of using this tool is the “Total Compliance” score provided after the report is run (ex. 87/100)
AChecker – This last tool is best for seeing the exact code and page elements associated with specific errors. Once you’ve decided to make the jump to addressing some of the compliance issues, this checker is good for knowing if an implemented “fix” has truly corrected the problem.
Medium-Large: Web Accessibility Audits
Deque – Of all the audit offerings available, this one appears to provide the most features and potential deliverables. They offer Accessibility Blueprint “If you don’t have specific accessibility compliance concerns but would like to understand more about your current state of accessibility and steps you can take to improve.” For larger businesses that would like to avoid any sort of risk, Deque has Conformance Statements and VPAT products that help to protect companies from legal pursuits.
Level Access – Audits – Level Access covers the spectrum of company sizes with its aforementioned self-service web accessibility checker, but it also offers professional services like Audits, Discovery, and Strategic Consulting for bigger businesses. While there does not appear to be a mention of Conformance Statements, there is enough support available to make this a perfectly suitable option for a medium to large company looking to avoid Accessibility litigation.
With Deque or Level Access, Accessibility is their entire game and their specialty, making either choice a safe one. Regardless of which path you take, if you’re a bigger company, you probably do not want to take the path of going it alone or ignoring accessibility altogether (Such is a potentially treacherous path, most likely involving pirates or a merry group of highway bandits).
2. Legal Context
One of the reasons that this is such an interesting issue is that there is very little legal precedent for how these new guidelines should be enforced. The first, and still most notable ruling on Title III guidelines was in the case of Gil v. Winn-Dixie. ADATitleIII.com notes that this was significant because “…it is the first decision to hold, after a full trial, that a public accommodation violated Title III of the ADA by having an inaccessible website.” You can find the full breakdown of the decision at the above link, but the key points are as follows:
- WCAG Adopted – The court formally adopted WCAG which, if you’ve been paying attention, is the set of development guidelines compiled and maintained by w3c. The checkers and audits mentioned in the Self-Awareness step all use WCAG as the benchmark to determine what needs to be changed to be more accessible.
- Cost Matters – The court considered how much Winn-Dixie spent on its website including the initial implementation ($2 Million) and subsequent updates ($7 Million) to determine if the cost of making the site accessible ($250K) would be too great a burden. In this case, they ruled that it was not an undue burden, but depending on a company’s budget, and the potential level-of-effort for making the site accessible, it could very much be decided differently. In this instance, the proposed changes would have accounted for less than 3% of the total development cost.
- Your Site. Your Responsibility – The decision also included language suggesting that elements managed by third party vendors are considered parts of the site for which the company is ultimately responsible.
The only other judgement in this area so far is Gomez v. GNC which also went in favor of the plaintiff Andres Gomez. The primary difference here was that the court did not rule on the suggested remediation of these issues, stating that “GNC argues correctly – that Gomez has provided no support that WCAG 2.0 is an appropriate remedy. Even if WCAG 2.0 is the appropriate standard, the record is silent on which success level is most appropriate.”
If you can’t tell from the copious amount of references to ADATitleIII.com I’m just going to come out and say that it’s one of the best sources of legal news concerning Web Accessibility. Stay tuned to their news page for updates on what is currently the biggest case in any court, Robles v. Domino’s Pizza. I won’t delve into the specifics of that case, but suffice it to say that it stands to impose a significant precedent in this otherwise open territory.
3. Continued Improvement
Now that the warning flares have been sent up and guidelines are in place, it’s imperative that any new development on your site considers the WCAG guidelines. There are a few strategies for this, including:
- Running a Check against Development Environments – Before deploying new updates to the production site, run one of the above checking tools against a development or QA environment to make sure that your new feature or “fix” has not introduced new conflicts with WCAG guidelines. If possible, it makes sense to address any existing violations while working on features that interact with the violating elements, since the developer will already be working in that space.
-
- Level Access
- Deque – WorldSpace AttestIntegrate Automated Testing – Probably the most seamless way to start developing to accepted standards is to implement an automated testing tool into your development workflow. There are two tools for this and they’re available through familiar sources:
Both of these tools integrate with most of the popular development platforms, making it easy for developers to catch potential issues while they code. Overall, tools like this will save significant budget by paying a little bit more for the testing and much less for fixes in the future.
The long and short of this novel is that it’s utterly crucial to have a strategy for web accessibility. When these regulations were initially released, there was limited documentation of guidelines and few tools available for remediation and testing. Now, with the resources enumerated above and others not even mentioned, there can be no legitimate defense that includes negligence or ignorance. And as time goes on, and more tools become available, the burden to businesses is reduced and another legal outlet removed. Very few sites comply with 100% of the guidelines, meaning that there are likely things to be done on your own site. What I’m saying is, don’t freak out, but get to work.
