There is growing interest in web accessibility around the world, with more companies seeking to make their web properties inclusive and user friendly for all people.
Perhaps it’s to increase conversions, or create an ethical brand, but whatever the driving force behind the increase in accessibility testing and need for specialists, in the United States, there remains resistance. With the pending vote by the US Senate on H.R. 620, the amendment to the ADA passed by the House to change the laws, I’ve been asked repeatedly whether a website should be accessible.
Nearly every website usability audit or web design client I speak with places accessibility at the bottom of the pile of things to plan for. Educating them is part of every discussion. Like SEO, there is no shortage of myths. For example, many people believe that accessibility means making a websites and applications work for blind people. Accessibility is design for inclusion, so that all people, regardless of any physical, emotional, or mental limitation, can use a web-based app or website.
Accessibility may be legally required for some types of websites such as for the government, but that does not mean government websites meet Section 508 standards. In fact, many aren’t user friendly because they’re not maintained to keep up with the latest standards. Accessibility compliance is handled differently by country, computer device and operating system.
If you own a website that targets a global market, you need to know what types of devices your users depend on the most, and you need to know what laws and guidelines are specific to countries and cultures. Not knowing can mean lost conversions or reflect negatively on your brand.
In the United States, an amendment to the Americans with Disabilities act is under debate in the Senate. More and more people are learning about H.R. 620, which passed the House in February, and are speaking out against it. Spurred by the increase in civil complaints from people who couldn’t use a website or application, the amendment essentially provides a business time to implement changes to enable access for handicapped people after they receive a letter describing the issue. This means that no business must provide access to disabled people – they can claim they didn’t know they had to or didn’t know there was a problem.
H.R. 620 allows time for businesses to act within a confusing time-frame formula that can even allow for unlimited time if they make a small effort. Meanwhile, the disabled person is not helped and has no legal recourse but to wait or take their business elsewhere. The amendment also plans on spending millions in accessibility training, although the specifics of this are not detailed and it ignores the fact that on a state level, local code enforcement already has accessibility laws for businesses. The amendment ignores websites completely.
What does this mean for websites? Do they follow the same rules as physical businesses? They aren’t legally required to. Website and software accessibility has always been provided because it is part of usability and user experience; not to mention meeting conversions expectations. Even .gov and .edu web properties that follow Section 508 standards do so because they are public facing and desire to accommodate everyone.
WCAG Guidelines Are Not New
Web Content Accessibility Guidelines were introduced in 1999 as WCAG 1.0. Since the early days of the web, inclusiveness has been recommended. Back then, there were 14 guidelines. WCAG2.0 was released in 2008. This is when the 4 principles were created, and along with them, 12 guidelines and 61 success criteria. There were 3 levels of implementation, A, AA and AAA. Most companies try to meet AA success criteria.
This coming June of 2018, WGAG2.1, now in draft mode, will be released. It contains new criteria for mobile accessibility, touch screens, and text to voice. It also addresses cognition and low vision. As the technology changes, with new computer devices and changes to operating systems evolve, guidelines adapt.
If you develop an app for mobile devices that you wish everyone to be able to use, you will need to know how to make it accessible. Apple and Android operating systems treat accessibility differently. If you have a website with buttons, how those buttons function, appear and respond is included in WCAG2.1. You are likely already familiar with tap points. The criteria for them appears to be changing too.
Keeping up with accessibility is a specialty. It is no different than keeping up with all the changes Google makes. This could be why accessibility is pushed to the back of the room. You not only must know what to do, but how to do it. With accessibility, while there are tools for testing, not all of it can be automated or emulated. This is the same situation as mobile design testing, where emulation helps to provide the overview but manual testing with screen shots and recordings are the proper testing method. Accessibility testing companies test with disabled persons, blind users, and other manual testing methodologies to truly understand the user experience.
Do You Need Accessibility for Your Website?
I can throw out statistics to impress you, but the reality is that you know someone who fits the criteria for accessibility. We all know people with low vision, who wear reading glasses or eye glasses or are sensitive to light or are color blind. We all know someone who is older, and their memory is starting to fail. Perhaps you know someone who suffered a broken hand, arm or wrist or has another temporary injury to their hands, making using a mouse or keyboard difficult.
If you know someone who is dyslexic, autistic, has Parkinson’s or MS or arthritis, would you purposely want to prevent them from using your website or app? Do you know anyone who is easily distracted? How about emotionally upset, or had a few too many drinks or is trying to fill out a form under stress or place a call in an urgent situation with some form of physical limitation?
All these people and more may be your target users. Regardless of whether any country makes it a legal requirement to meet accessibility standards, it is a socially responsible, ethical practice.
Here are some resources:
Funkify Simulator – http://www.funkify.org/
Developer Tools in Chrome – has audits, axe, other, mobile emulator
Color Contrast Tool – https://www.joedolson.com/tools/color-contrast.php
Readability – https://readable.io/
Accessibility, Usability Sites and People
Google Accessibility https://www.google.com/accessibility/index.html
Derek Featherstone http://simplyaccessible.com/article/author/feather/
Joe Dolson https://www.joedolson.com/
Glenda Sims – http://www.deque.com/blog/author/gsims/
Karl Groves – http://www.karlgroves.com/
Ability Net – https://www.abilitynet.org.uk/
Shaun Anderson – https://www.hobo-web.co.uk/design-website-for-blind/
Mobile Accessibility – https://www.w3.org/TR/mobile-accessibility-mapping/
Mobile Color Contrast – https://www.deque.com/blog/accessibility-mobile-web-improving-color-contrast/
Introduction to Understanding WCAG 2.0 – https://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html