Why Web Accessibility?
At BrandExtract when we build websites, we test on every browser version that is used by more than 1% of our customer's audience. It makes sense for a website to be usable in as many browsers as possible so we don't exclude potential customers, partners or employees. Even though it impacts the total cost of their website, we've never had to convince anyone that this is a worthwhile effort.
Human beings deserve at least the same consideration as web browsers. Roughly one-in-eight people in the United States has a disability. If the definition is expanded to include those who are only moderately impaired, that number jumps to nearly one-in-five. Failure to accommodate such a large audience limits the positive impact a website can have on your business.
The first thing we tend to think of when discussing web accessibility is making a site usable for visually impaired visitors, but visual impairments are just one category of disabilities. Auditory, physical and cognitive impairments are just as important and must be addressed in different ways. Individuals with these impairments can use a variety of assistive devices to help to navigate the web more easily. Accessible websites are simply those that work well with these assistive devices and strive to present a user experience that minimizes the need for assistive devices in the first place.
Other Benefits of Accessibility
Good planning is a fundamental component of building high quality, usable websites. It requires thoughtfulness and good processes. Planning your UX and design work around accessibility raises the bar for detail in your work. The result of this increased diligence is a website that performs well for humans and robots alike. (Yes, we care about robots, too.)
The same details that can inform a screen reader or other assistive technologies are also helpful for the search engine robots that crawl and index your site. According to Google Webmaster Central Blog, sites that are accessible are more easily indexed by the Google search engines which can lead to better matches and higher rankings. Google has been saying this exact thing for over ten years now.
Further, many of the things we do to make a website more accessible for users with impairments also help other users. Larger fonts, better contrast, and many other fundamental accessibility principles serve to make a site more usable for everyone.
It's important to note before we start talking about legal regulations is that I am not a lawyer. Any decisions you make to implement anything less than full compliance with all of the regulations described below (and those that aren't described below) come with risk and should be run by your legal team. They are infinitely more qualified to assess the risk and consequences of failure to comply with these regulations. "You could be sued" is not just a scary sales tactic.
Accessibility regulations vary by country. In the United States, it is important to be aware of the Americans with Disabilities Act of 1990, Amended (ADA), Section 255 of the Telecommunications Act of 1996, the Air Carrier Access Act of 1986 and the 21st Century Communications and Video Accessibility Act of 2010 (CVAA). If you are creating a website for a U.S. government agency or an entity that receives funding from the government, you also need to be aware of Section 504 of the U.S. Rehabilitation Act of 1973, and also Section 508 of the same U.S. Rehabilitiation Act of 1973 .
If you are based in or doing significant business in the European Union you need be aware of the proposed European Accessibility Act and possibly the Web and Mobile Accessibility Directive. Some EU member countries will have additional regulations on top of that. The United Kingdom, for example, has The Equality Act of 2010.
Doing business in Canada? Make sure you are up to speed on the Canadian Human Rights Act and the Policy on Communications and Federal Identity. Many other countries have their own individual regulations as well.
It's completely natural to feel overwhelmed. Keeping up with all the regulations is simply more than one person or small company could possibly contend with, unless that is their single, core focus. Fortunately, there are standards bodies, guidelines and experts to help us get it right.
Most regulations look to the WCAG 1.0 and WCAG 2.0 standards as guidelines for building accessible websites. Both of these standards are built and maintained by the Web Content Accessibility Guidelines Working Group, a consortium of web developers and invited experts from a variety of companies and organizations. The WCAG working group is one of the many working groups under the W3C (World Wide Web Consortium). The W3C is the international standards community responsible for HTML, CSS and many other technologies that the web depends on.
WCAG 1.0 and 2.0 will largely guide you to the same place, but WCAG 2.0 has more easily measured heuristics. A website that conforms with WCAG 1.0 will likely conform with WCAG 2.0. All sites that conform with WCAG 2.0 will conform with WCAG 1.0. Where the two differ is in how they organize the guidelines. Quoting the W3C website:
WCAG 1.0 is organized around guidelines that have checkpoints, which are priority 1, 2, or 3. The basis for determining conformance to the WCAG 1.0 are the checkpoints.
WCAG 2.0 is organized around four design principles of Web accessibility. Each principle has guidelines, and each guideline has testable success criteria at level A, AA, or AAA . The basis for determining conformance to the WCAG 2.0 are the success criteria.
It's important to note that WCAG is an evolving standard. WCAG 2.1 has reached candidate recommendation status and may see adoption in any new legislation as early as the summer of 2018. WCAG 2.1 is additive upon WCAG 2.0. In other words, a 2.1 conformant site will be 2.0 and 1.0 conformant so it makes sense to target WCAG 2.1 in any new initiatives.
Let's do a break down of the WCAG 2.1 hierarchy. The four fundamental design principles put forth are:
- Information and user interface components must be presented in a way that they can perceive.
- User interface components and navigation must be operable.
- Information and the operation of user interface must be understandable.
- Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Within each of those principles are a series of guidelines. For example, subordinate to the first principle we will find the following guideline:
- Create content that can be presented in different ways (for example simple layout) without losing information or structure.
Subordinate to that guideline we find these success criteria:
- Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
- When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
- Instructions provided for understanding and operation content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.
- The meaning of each input field collecting information about the user can be programmatically determined when:
- The input field has a meaning that maps to the HTML 5.2 Autofill field names; and
- The content is implemented using technologies with support for identifying the expected meaning of form input data.
- In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined.
Each principle has one or many guidelines and each of those guidelines has one or many success criteria. The current draft of WCAG 2.1 has four principles, fourteen guidelines, and seventy-eight success criteria. A website must be audited against all of these criteria to ensure conformance with the standard and most of these criteria involve multiple tests.
But wait, there's more. Each of the success criteria has three levels of conformance: A, AA and AAA. The levels as explained by the Section508.gov website are:
- Level A (minimum) – Addresses the most basic web accessibility features, but does not generally achieve broad accessibility
- Level AA (mid-range) – Addresses most common barriers for disabled users and aligns to the Revised 508 Standards
- Level AAA (highest) – Addresses the highest level of web accessibility, but is not recommended as a general policy, because it is not possible to satisfy all criteria for some content.
Choose carefully what level of conformance you want to achieve with a website because it will have a significant impact on schedule and budget.
Automated Testing vs. Human Testing
There are a number of free tools and online services that will perform an automated test of a single web page or even entire sites. The tools can be browser plugins, standalone desktop applications, self-hosted services, free online services, and commercial (paid) automated testing.
Our favorite automated tools are:
- tenon.io - Tenon is SaaS that can perform on demand searches through the browser or an API. Pricing is dependent on the number of API requests (scans) that you need to perform. It is extremely well documented and can easily be incorporated into SAM, BrandExtract's CMS.
- AATT (Automated Accessibility Testing Tool) by Paypal - AATT is a node.js application that runs as a service. It can scan single pages or entire sites, and can be configured so that it can access non-public (password protected) web pages. Scan requests can be submitted via an API with responses returned in an easily parsed JSON format. AATT is also easily integrated with SAM.
- aXe Developer Tools by Dequeue Systems - aXe is available in a browser plugin for both Chrome and Firefox. It extends the browsers' built-in developer tools and creates a nice, easily parsed report with clear recommendations.
These tools are quick and easy to use but are not a panacea. Many of the guidelines put forth in the WCAG documents are worded in ways that require careful parsing and evaluation, and how those guidelines apply to unique designs can be subjective. Why are they worded vaguely? These guidelines have to be future proof. Since the web and related technologies are an evolving medium, the guidelines needed to be applicable to technologies, devices and interfaces that have yet to be invented.
Further, the automated testing tools simply cannot perceive the user experience in the same way as a human. There are measurables that can do a really good job, (i.e. Do fonts meet a minimum size and contrast criteria?) but there are many other things that are much more difficult to measure. (Is the meaning of a diagram adequately conveyed in the text?) That's where human beings come in.
Human testing of a website is a deliberate and rigorous process that can take hundreds of hours. In a perfect scenario, testing should be done with users who have the same impairments you are addressing, and the expertise to know what's right and what's wrong with a website. The only practical way to find a team of these experts is to outsource to a reputable third party that specializes in accessibility testing. Hiring humans to test a website for accessibility can be very expensive. You may find that having humans test just the more complex, interactive pages is a cost-effective compromise.
Risks of Non-Compliance
We all want to believe that we will build inclusive websites simply because it is the right thing to do, but the truth is sometimes our good intentions will outstrip our pocketbooks. Why should a company spend thousands of dollars making their website accessible? One reason is to minimize risk.
Even if you do not provide direct services to consumers, you may still be at risk of being found in violation of one or more regulations. Consider users who are looking for employment within your organization but are excluded because your online job database is not accessible. What about investors who don't have access to your company's financials? When these things happen you can be found in violation of government regulations.
There are no government entities that spends its time surfing the web, auditing sites and looking for websites that don't meet web accessibility guidelines. There are no inspectors who "sign-off" when your website is ready to go live. It is entirely up to your organization to make sure the job is done well. You are responsible for choosing a partner that takes web accessibility seriously and has the resources, either internal or external, to make sure the job is done right.
It's hard to quantify what the likelihood of being sued and what the costs could be, but even unfounded lawsuits that are readily dismissed can cost a company many thousands of dollars in legal fees, and if it is demonstrable that you have made insufficient efforts to make your website accessible you will probably lose (or be forced to settle). Over 260 web accessibility lawsuits were filed in 2016 and the numbers were significantly higher in 2017. This does not include those cases that were settled without going to litigation. Talk to your lawyers to get a real sense of the possibilities, but know that the risk is real.
If you are interested in learning more about the risks of non-compliance I highly recommend this blog post by Karl Groves. It is a balanced view, backed by real numbers. Just keep in mind that it was written a couple of years ago, and the landscape has changed with regards the number of lawsuits being filed.
- Assess your risk: Consult with your legal team and calculate (as best you can) your risks. Have them search public records for ongoing and recent litigation in this area. Are the trends going up? What percentage are successful? Does it seem that your industry is seeing more activity? What could a lawsuit cost your organization, both in dollars and the negative impact on your brand? What about lost revenue?
- Research the costs: If you are building a new site, have your development partners create a line item for the cost of ensuring that their work meets WCAG 2.1 standards using automated accessibility testing tools. Also, consider meeting with a third party accessibility consultant who has the resources to perform human testing. Get pricing from them directly so that they can work independently from your developer.
- Do the math: It sounds callous, but the truth is you have to make a determination on whether the risks outweigh the costs. At BrandExtract we believe that for most business-to-business websites, thorough automated testing for WCAG 2.0 Level A conformance upon launch and any major updates is a cost-effective solution that demonstrates a clear effort to make a website accessible. For consumer-facing websites, or websites with rich, complex interactivity, more thorough testing may be required. Once again, you should consult a legal professional to get a clear and accurate understanding of the risks of non-compliance.
- Set a plan for launch: If your website is consumer-facing, it would be reasonable to perform testing with humans at the launch of a new site or anytime it undergoes major changes. For a business-to-business site without a lot of complexity or rich interactions, automated testing of the site may be sufficient.
- Set a maintenance plan: Any plan you put forth must include ongoing testing that happens on demand or automatically on a regular schedule. Human testing is something that is only needed when a website undergoes significant revisions and/or redesign.
When researching how to achieve conformance you will find that the solution is not always clear. Fortunately, we have The A11Y Project. The A11Y Project is a community organization that focuses on making web accessibility guidelines easier to understand and implement. It offers specific suggestions for common design patterns, articles on accessibility, a curated list of events, and checklists for making sure you've hit all the important steps.
“A11Y” is a numeronym that is frequently used in social media and other space-restricted media to refer to Accessibility. You can simply read it as "Accessibility" and use it to help uncover other resources (or shorten your tweets).
How Can SAM Help?
SAM offers three possible integrations to assist with automated accessibility checking:
- The TinyMCE A11yChecker plug-in is a free add-on to SAM's embedded HTML editor and can be turned on by request for SAM versions 3.2 and later.
- Integration with BrandExtract's hosted instance of AATT can be used on SAM 3.2 or later.
- Integration with tenon.io can be implemented on SAM 3.2 or later.
References and Resources
- The A11Y Project
- The W3C Web Accessibility Initiative
- WCAG 1.0
- WCAG 2.0
- WCAG 2.1 (Candidate Recommendation)
- Selecting Web Accessibility Evaluation Tools
- aXe Developer Tools
- Automated Accessibility Testing Tool
- Tenon.io Online testing tool
- TinyMCE A11yChecker
- Accessibility Lawsuits, Trolls, and Scare Tactics
- Also a special thanks to Kim Testa at The Bureau of Internet Accessibility. Her group offers both automated and human testing and I feel smarter for having talked to her (though any mistakes in this article are my own).