Presentation: Auditing Your Website for Accessibility Compliance and Understanding How ADA Applies

This was presented as a webinar on August 16, 2018 for the Florida Libraries Webinars program.

Slides

Live deck on GitHub Pages

Brief Overview

• Policy & Legislation
• Web Accessibility
• Types of Disabilities
• Assistive Technology
• WCAG
• Auditing Your Website
• Accessibility Statement
• Take Away

Policy & Legislation

In the US, there are two Acts to consider.

The Rehabilitation Act of 1973, includes this clause in Section 504:

No otherwise qualified individual with a disability shall […] be excluded from […] any program or activity receiving Federal financial assistance. – Section 504¹

Most of you are probably not at a Federal department or agency, but if you work in a public organization of any sort, you are likely receiving federal funding in part.

Here I also mention Section 508 of the Rehabilitation Act because it governs the regulations that Federal departments must follow around technology, which states that

[E]ach Federal department or agency […] shall ensure […] that the electronic and information technology allows […] individuals with disabilities who are members of the public seeking information or services from a Federal department or agency to have access to and use of information and data that is comparable to the […] public who are not individuals with disabilities. – Section 508, paragraph a-1-A-ii²

The specific guidelines laid out by the Federal government in relation to Section 508 is what many other organizations follow to ensure compliance with Americans with Disabilities Act (1990).

The Americans with Disabilities Act provides civil rights to people with disabilities much like the Civil Rights Act would apply based on race or religion.

Aside from the federal level, there may also be state, district, municipal. Of course, you’re likely here today because of the letter from the Florida Association of Special Districts (FASD) on ADA Accessibility.

So, to summarize. We have various pieces and levels of legislation and policy that determine the guidelines we must follow, and additionally, there may be policies at your particular organization or ones specific to projects, such as due to conditions from a grant, which may also have their own policies that may be similar or extend the list of requirements.

What is Web Accessibility?

While we’ve covered the legislation we need to be concerned about. We’re here today to talk about accessibility, but what is web accessibility?

One definition, and what seems to be the most common one is that:

Web accessibility means that people with disabilities can use the Web. – W3C Web Accessibility Initiative (WAI)³

Normally, the next step might be to define a disability. Unfortunately, that’s actually a really hard task, but we can look at the different types of disabilities to get a better idea.

Types of Disabilities

• visual: other than blindness, this might also refer to people who have difficulty with judging distances and hand-eye coordination
• auditory: other than deafness, this might also refer to other hearing issues, such as having difficulty focusing on a single voice
• physical/motor: examples include not being able to grip something or problems with precise movements
• touch: namely this refers to a lack of sensation with touch
• learning: is a rather large umbrella term, but includes dyslexia and other reading disabilities, as well as dysphasia and related issues with writing

With all the different types of devices used to access websites, any one or a combination of these disabilities may apply to a user trying to access a website.

Assistive Technology

As you may have heard, there are many types of technology that can help users with disabilities with navigating the internet, which we call assistive technology. I’m sure you’ve heard of many of these before, but I’ll just very quickly mention some of them.

• screen readers
• text-to-speech, speech-to-text
• mouse alternatives (e.g. joysticks)
• screen magnifiers
• keyboard only
• touch screen
• and more

You’ll notice that keyboards and touch screens are commonly used by those without disabilities as well, so one of the main benefits of improving web accessibility is improving the usability of your website for all users.

Okay, so now that we’ve covered the general concept, the people, and the legislation, let’s look at the specifics on what guidelines to follow and how to apply them.

Web Content Accessibility Guidelines (WCAG) by World Wide Web Consortium (W3C)

As I mentioned before, many organizations follow the guidelines set out by Section 508 and the Federal government. In 2017, the Federal government updated Section 508 to essentially use the Web Content Accessibility Guidelines aka WCAG 2.0 as its standard. Version 2 was originally released in Dec 2008. Recently, the World Wide Web Consortium (W3C) released version 2.1. 2.1 included some additional guidelines and guidance from W3C, especially around conformance. It is highly recommended to have websites and applications meet the new 2.1 guidelines, since 2.1 is backwards compatible with version 2, meaning that by meeting the 2.1 guidelines, you automatically meet the 2.0 guidelines.

Sections of WCAG

Let’s first take a look at the general structure of WCAG. Aside from the Introduction and the appendices, WCAG is broken down into 5 general sections.

• Perceivable means that the information is presented in such a way that users can observe or perceive the content
• Operable means that users navigate to and interact with all components
• Understandable means that the content can be understood by the user
• Robust means that the content can be interpreted in various ways including assistive technology
• Conformance elaborates on when you can claim you have met the guidelines and some suggestions on making an accessibility statement

Some Notes on WCAG

Before we move on, I want to cover a few important points about WCAG.

The first is that each guideline is classified by level, with A being the basic and minimal level up to AAA with the strictest guidelines. Legislation and other policies will sometimes ask you to meet Level A, but most including Section 508 require you to meet Level AA. I’ve never seen anyone requiring Level AAA, and it is often considered impractical, though not impossible.

When trying to view which guidelines are required for a specific level and their related techniques for success, try using the quick ref version of the WCAG document since you can filter out what you need.

One of the complex parts of understanding WCAG and how it applies when auditing your website is that elements on your website will almost always overlap with multiple guidelines.

Understanding WCAG

Unfortunately, we have limited time for this session and web accessibility is a big topic. Since I will be focusing on how to audit a website for web accessibility, I will not actually be covering general techniques on creating accessible web content or websites. So I highly recommend taking a look at the webinars I’ve previously done, which cover online content including documents, and websites as a whole in the second one.

• Making Online Accessibility Easy and Part of Your Work (Florida Libraries, May 2016)
• Making Web Services Accessible for Everyone (Florida Libraries, September 2016)

If you prefer text based information (as opposed to videos), more recently, I published an article that covers accessible web content creation in a bit more detail in WeaveUX, and for more technical coverage of web accessibility, check out the Code4Lib article I co-authored.

• A Practical Guide to Improving Web Accessibility (WeaveUX, Issue 7, October 2017)
• A Practical Starter Guide on Developing Accessible Websites (Code4Lib Journal, Issue 37, July 2017)

Finally, while most of the posts are a bit older, my WCAG blog post series covers best practices around content and website creation for all Level A and AA guidelines by explicitly referring to them. It does include a more recent post regarding what’s new in 2.1.

• WCAG Blog Post Series

There are lots of general resources as well, so I encourage you to search and read on any particular aspect that may be unclear to you.

Auditing and Evaluating Your Website

There are many accessibility checkers out there and I will only mention a very few number so as to cover what is required, but keep in mind that there are alternatives to all of these tools, so by no means do you need to use the ones I mention here. These are simply the ones that I often use, but doesn’t even cover all the ones I might use when evaluating a website for accessibility.

There are two main types of tools.

Simulation

Simulation tools allow you to simulate certain conditions or environments.

For example, Colorblind Web Page Filter allows you to enter a web address and simulates colour blindness.

There are also some screen reader emulators, such as Fangs.

Evaluation

Evaluation tools allow you to check conformance to guidelines.

For example, W3C validator allows you to validate code, making sure the syntax is correct and conforms to the latest specification.

HTML Codesniffer is a bookmarklet which checks the code of your website against WCAG. The nice thing about a bookmarklet is that it should run in any browser, and also run on pages when you are logged into a system, which sites that want you to enter a web address cannot evaluate.

WCAG Contrast Checker will specifically check on the colour contrast of your text against the background colour. You can also enter values manually if you want to check the colour contrast while working on something.

The WAVE Toolbar will provide a report and also allow you to view a site as text-only, or with headers only as an outline.

Manual Tests with Devices

Some things must be tested manually. For example, you may need to test mouse usage, especially on hover, or how specific behaviour on a touch screen. Similarly, keyboard accessibility is often tested manually.

Websites should always be fully accessible by a keyboard. Interactive elements should be navigable and controllable by keyboard, keyboard shortcuts should not override default behaviour, and users should always know where they are. For example, visual cues for input focus help your users regardless of whether they only use a keyboard or not, but are necessary for keyboard only users. And if you have hidden links, such as skip links, they should show up when there is focus on it.

If you want to conform to the new guidelines introduced in WCAG 2.1, you may need to do them manually as well since many of the tools are still using version 2.0.

Automated Testing Frameworks

There are also automated testing frameworks for those who do a development work and are familiar with integrating these types of frameworks into their unit testing, but as most website content creators and even administrators may not have access to these resources, I will simply mention them here but not go into any detail.

• aXe core
• A11y Machine

Demo

HTML Codesniffer

When doing an analysis of a website, I recommend using at least two different accessibility code checkers and manual keyboard testing, but which ones you use will depend on what best meets your needs. Since we don’t have time to cover all the tools I mentioned, I want to focus on just a couple of them. So, let’s start with HTML Codesniffer.

After turning on the bookmarklet, you will see an overview of the number of errors and warnings. Ideally, you want no errors just like on the NNELS site. You want to check that nothing in the warnings section is in fact an error, but focus on the errors first.

After getting your initial results, you can select the guidelines you want your report based on. So for example, if you want WCAG Level A, you can choose that instead, but defaults to Level AA, which is what we want anyway. When looking at a report, especially for the first time, I typically turn off the warnings, so as to focus on the errors.

As you view individual errors, the bookmarklet will list the error, recommendation, WCAG criterion it fails, suggested technique, code exerpt, and attempt to mark the element on the page that it is referring to. Often times, colour contrast errors, such as this one, where the link colour supposedly does not have a high enough contrast with the background will repeat because it will mark every instance on the page as an error. Therefore, changing the link colour across the site to meet the minimum contrast guidelines could potentially fix numerous errors on every page.

While in some cases, errors are specific to content on one particular page, often errors are in the header, footer, or much like the previous example, something that needs to be changed site-wide. If you are not the site administrator, then you will want to work closely with them. If you are a site administrator, then remember that it is best to start with a single page, usually the home page, before looking at other parts of the site, because you’ll likely fix a lot of the errors just from looking at the one page.

WAVE Toolbar

The website gives you the option of entering a URL, but if your page is behind a login, it will not work with this method, and personally, I find the browser extension easier to use. They have add-ons for both Firefox and Chrome.

After installing the extension, you can simply click on the WAVE Toolbar icon in the top right to turn it on, and you will see the sidebar open with your report on the left. As you can see, WAVE provides a report as well but broken into sections. It also uses various icons to mark all the errors and other important elements on the page.

You can click on each icon to find out what the error is, or the information for the related marker. The really nice thing about WAVE is that it tries to make it as simple as possible. I particularly appreciate that it tries to put things into natural language. The downside is that the icons can be visual clutter, shift the visual look of the site so that it no longer reflects what it normally looks like, and the information is a little more buried.

I especially like WAVE because it’s great for looking at the header structure of a page, since it will mark all the headers with their respective levels, you can easily see if for some reason you possibly have the wrong header number since your headers should be in descending number. For example, if the title for your news items use header 3, then the header declaring this is the news section, should actually be header 2.

Keyboard Accessibility

One thing I want to quickly demo as well is keyboard accessibility testing. To test keyboard accessibility, what you want to do is to use the TAB key on your keyboard to move through the site. As I mentioned before, links, form fields, and other elements should have an outline to show users where their cursor focus is, but often, this is not the case. So, in a browser, you can temporarily add a CSS rule to highlight your focus.

The trick is to right click on a link within the page to “inspect” the element, opening the developer tools. You can then add the CSS rule to say that on focus, all links should have a red outline, so that when you close the inspector, as you tab through your links, you can clearly see where your cursor is. You can really use any colour you like, but I find red to be the easiest to see on most sites.

On the first passthrough, I recommend simply making sure that you don’t end up in a keyboard trap, and then on the subsequent passes, try to interact with various elements.

Ask Your Users

While tools and testing is a great way to make sure you’re meeting the guidelines, passing all of these tests does not mean that your website is actually accessible or usable. Nothing can replace actual user and usability testing.

Accessibility Statement

One of the things you will need to do is write an accessibility statement which should include the wording from the FSAD in the memo you received, and conformance claims following WCAG Conformance Claims. In some cases, if large or integral parts of your website include third-party software, you will only be able to make a partial conformance claim, but that’s fine. It’s better to make it clear to the reader that the parts provided by a third party are out of your control, but that you’re willing to assist in whatever way you can. Ideally, the third party has their own accessibility statement and if they state that they conform with WCAG, then you could make a full conformance claim.

Take Away

While it’s important to take best practices into consideration and put guidelines into practice, if I can give you one take away, it is this:

Make it easy to contact you.

If someone is having trouble accessing the information on your website, then you want them to be able to contact you and tell you. You can always provide an alternative way of providing information if the website is not something you can fix right away. Your due diligence is not to have a perfect website, but to work with others to make information accessible through your website. We often also cannot predict or test for every single way that people might access the website, so do the best you can, put up an accessibility statement, and simply make it easy for someone to contact you.

International Cat Day

I apparently missed cat day recently. So have a bonus cat: