Accessibility Testing Tools for Developers - Seattle Code Camp

Editor's Notes

• #2: Good morning, and thanking for joining me for Accessibility Testing Tools for Developers. You could have chosen any of the other great sessions at this time, or slept in on this Saturday morning, so thank you for being here with me. My name is Gerard K. Cohen, for the last 4 years I have worked on building an accessible UI framework to be used by over 80 commercial applications for one of the countries largest banks, well known for being the first to offer online banking. This morning I will be going over different testing tools that you can integrate to your daily development workflow to ensure that you are producing good accessible products, from absolute basic tools all the way to more advanced, an experiment in automated E2E testing.
• #3: Good morning, and thanking for joining me for Accessibility Testing Tools for Developers. You could have chosen any of the other great sessions at this time, or slept in on this Saturday morning, so thank you for being here with me. My name is Gerard K. Cohen, for the last 4 years I have worked on building an accessible UI framework to be used by over 80 commercial applications for one of the countries largest banks, well known for being the first to offer online banking. This morning I will be going over different testing tools that you can integrate to your daily development workflow to ensure that you are producing good accessible products, from absolute basic tools all the way to more advanced, an experiment in automated E2E testing.
• #4: So, I am going to assume we are all developers here but what I wont assume is what level of testing you do on your own. I don't know about you, but I absolutely HATE when a defect gets logged against my work. I'm not saying it never happens. It happens a lot, but I still hate it. So I am careful to test my work as much as possible in different browsers, on different platforms, and with different AT. Maybe you leave testing up to your QA teams. But let's talk about why, as a developer, it's important that you test early and often why you are developing. As FED's, I honestly feel we are the last line of defense, the last line of hope
• #5: to ensure that our work, our products, are inclusive to everybody. DESCRIBE PHOTO Definitely, we should not be the ONLY advocates for accessibility, but we are where the rubber meets the road. Testing during development is a great way to make sure everything you do is as accessible as possible in the end. There is enough evidence in the world to dictate that deferring accessibility is an expensive, time consuming task. So today I will go over different tools to help you during development. I will be testing against Ted Drake’s a11y control test which is small set of good and bad examples, demonstrating on a Mac with Chrome, but for the most part these tools will be platform/ browser agnostic, or at least have equivalents for different platforms. So, starting with some basic, yet essential tools.
• #6: At the bare minimum, you should always be using the first 2 tools. They shouldn't be the only 2, but you can choose any other combination of tools I will be demonstrating in addition to these 2 essentials. The first I think has fallen out of style it seems.
• #7: The first is HTML VALIDATION! So simple, yet so important for a basic reason. You need to make sure that you have well formed, standard markup so that AT can properly parse your content. Browsers and AT are usually pretty forgiving, which is necessary to ensure success of the internet, but don’t leave it up to interpretation. A couple different ways to validate your markup. The first is by going straight to the official validator in your browser: https://validator.w3.org/nu/ (visit and go over page). (READ OUT THE URL) The validator will not only make sure you have valid markup, but will also make some pretty good suggestions regarding various ARIA roles and such. Thanks to the Steve Faulkner for that.
• #8: Another option is to use the popular Web Developer tools plugin by Chris Pederick for your browser, available for Chrome, Firefox, and Opera. This tool basically automates the step of going to the validator by yourself. (READ OUT THE URL)
• #9: If you are behind a firewall, or have restrictions on using online/ 3rd party tools like we do at the bank, you can choose to install this service locally and test against that. The source for the validator is available on github at https://github.com/validator/validator. (READ OUT THE URL)
• #10: Now, the next tool is even more basic than validation but just as important.
• #11: What if I told you… that virtually all computers with a keyboard have a special key that will help you test accessibility, easily, and I highly recommend that you start using it if you are not already… DESCRIBE PHOTO
• #12: Take the time to tab through the page. Make sure that focus is flowing in a natural order, matching the visual order of the page. Make sure that there are no keyboard traps. Make sure that focus is not landing on any hidden elements. When you get to the bottom, do SHIFT + TAB and go back up, make sure nothing funny happens in reverse. If focus is lost, the best 1 line of CSS ever written can be very beneficial here:
• #13: :focus { border: 1px solid red; }. This will help you to see where focus is, and let you know if you need to check your focus styles. (if custom, make sure it passes color contrast rules, which I will be talking about in a few minutes). It also helps to expose whether or not you have any skip navigation. If tabbing is not as expected, e.g. the order is not predictable or erratic you can check DOM order, check for floated, absolutely positioned, off-canvas or "hidden" elements. Another thing to check for is any improper tabindex values.
• #14: Basically, you should never have a tabindex greater than 0. The only acceptable values are -1 and 0, with -1 being related to any scripting you may be doing. Also, you might have some interactions that require navigation with arrows, like menus or toolbars. Proper keyboard tabbing is imporant for users with motor disabilities. They may not be using a mouse or have touch capabilities,and they be using either the keyboard alone or alternate input device like switches. Switches are rudimentary devices…
• #15: So, those are the 2 most basic testing tools you can do. Proper, semantic HTML and good tab/ keyboard focus will get you a very long way. If you already knew these things, or are do some level of these basic tests, then please make sure that you sharing/ exposing these things to other developers because this is still a big problem, and so easy to fix. Moving on from there, we on to the next level of tools
• #16: There are some pretty sophisticated tests that can be done with just some fancy CSS selectors. A couple very nice people have contributed Bookmarklets containing CSS to check various markup and accessibility related items.
• #17: The first one to check out debugCSS, developed by our good friends at Yahoo but was recently removed. I was able to find this back up though. http://imbrianj.github.io/debugCSS/ (READ OUT URL)
• #18: Next, another one by our very own Karl Groves, is Diagnostic.css http://www.karlgroves.com/2013/09/07/diagnostic-css-super-quick-web-accessibility-testing/ (READ OUT URL)
• #19: Lastly, is revenge.css by Heydon Pickering https://github.com/Heydon/REVENGE.CSS (READ OUT URL) Certainly, there is overlap with these tools, but they are so quick and easy to use, it doesnt really hurt to run all, or a combination of them, against your code.
• #20: Custom rules are pretty easy. At Wells Fargo, some of our newer CSS-only components will include some defensive/ diagnostic css. Such as a our CSS Toolbar, which replaced a JS widget that essentially only provided a border and background to a containing element, for a collection of controls used to manipulate datatables for examples. One thing the JS widget did, like all our JS widgets, is enforce a11y. So, moving to a CSS-only component, we still wanted to make sure that implementers did not miss important a11y properties.
• #21: Mainly, the use of role=group and a unique aria-label. So this basic CSS helped with that
• #22: TYPO IN CSS
• #24: A step up from there, are some more serious bookmarklets using JS. These are really nice.
• #25: The first is tota11y, provided by Khan Academy: http://khan.github.io/tota11y/. (READ OUT URL) This places a nice little button on the page with various options to highlight.
• #26: A very recent entry is Visual ARIA by a guy named Bryan Garaventa
• #27: Another pretty amazing JS bookmarlet is HTML CodeSniffer http://squizlabs.github.io/HTML_CodeSniffer/ (READ OUT URL) This is really sophisticated for being a JS Bookmarklet, allowing you to specify guidelines/ conformance levels to test against, and also includes links to information for each violation. Be careful with bookmarklets, if you are using CSP. Your settings may only allow scripts from a specific domain or not allow inline code. In that case, these bookmarklets will not work
• #28: A step up from bookmarklets, are browser plugins.
• #29: We saw one earlier with the Web Developer Tools plugin, to validate our markup. The WDT plugin has some additional features that are helpful for accessibility. One feature is being able to turn off CSS so you can check your markup.You can outline formfields without labels, outline images without Alt attributes, or empty attributes. Display ARIA roles, tabindex, title attributes, etc. Let's take a look at a few browser plugins that are more specific to a11y testing.
• #30: The first, and one that I use often is Chrome's Accessibility Developer Tools, provided by Google and developled by Alice Boxhall. This integrates nicely into Chrome with a 2 different tools. The first is the ability to run an audit against your page. This is available from the inspector under Audits. Running an audit will give a nice list of violations, highlighting elements and providing links to more information. This is nice, but the one feature I use the most is the Accessibility Inspector Panel. You can highlight any element in the DOM and the Accessibility Inspector panel will give you some useful information like any ARIA roles, states, properties, color contrast (with a suggestion of colors that can be used to conform), and a sample of what would be announced by screenreader, either content or accessible names/labels. Extensions > Search > Accessibility So, you have heard me mention color contrast a few times already so let me explain what that is. Basically, there has to be significant difference between background and forground colors, mainly text over backgrounds. the difference has to be a ratio of 4.5:1. There are lots of tools that you can use to get the color contrast ratio of any two colors, I just showed you one as a feature of Chromes accessibility developer tools. Ensuring proper color contrast is important low vision users, low light situations, and color blind users. Color does not always mean that a person only sees in grey scale, in most cases it means they certain colors are washed out. 10% of men are color blind and a very large percentage, and red and/ or green deficient. Meaning that cant see colors in red or green spectrum so well. These 2 colors are pretty imporant to us, can you think of places where red and green are used? Form validation! Let me show you an example of what this looks like
• #31: Can everyone see the number? Ok, let me show what this might look like to a color blind user
• #32: So as you can see, this is almost all green here.
• #33: A really cool plugin to simulate various levels of low vision and color blindness is Chromelens, and its available in the chrome web store. Let me show you this now.
• #34: Another very popular browser plugin is the WAVE toolbar, by Jared Smith at Webaim. Along with running tests against WCAG and Section 508, it also includes some additional tools like being able to turn off CSS styles as well as a color contrast checker. It also includes links to standards and guidelines for each violation.
• #35: Next, is the aXe plugin by Deque. Similar to the Chrome Accessibility Developer Tools, this plugin is accessed via the inspector and activated by running an audit. Also tests against WCAG, checks color contrast, and provides more information about each violation.
• #36: Lastly, is Tenon by Karl Groves. This is similar to HTML Validation in that you supply either a URL or some source code to the service and results are returned. Again, if you have restrictions around submitting code across the internet, Tenon does offer a self-hosted solution. Talk about
• #37: Finally, we get to some really advanced testing. I wanted to experiment with automating some of these tests to see how far I could get. I wanted to see if I could build these accessibility tests into an E2E testing platform. I have a small project where I strung together some node modules for this experiment. Now, before I show you this code I need to let you know that I have very little Node experience, so I am not totally happy with the quality of my code. Second, this is just for experimenting, there is a lot more refinement needed, this is just an idea. nightwatch --env chrome --group aXe --tag bad
• #38: So, what’s next? Refactoring Grunt/ Gulp watch to test on save SVN/ Git hooks (to prevent crap code checkins) CI integration (Jenkins/ Travis CI)
• #39: So, we talked about different tests you can do build throughout your workflow, from super basic all the way up to pretty involved. I hope that, if you are not already, you will some of these tools to ensure that you are shipping accessible products. I have to say though, while I am extremely thankful for these tools, in the end NOTHING replaces actual knowledge, rather than relying on tools, and testing with various assistive technologies, like screen readers, preferably with proper users. Once you have done that, you can use the more advanced automated tools to ensure the quality of your application and not inadvertently introduce issues.
• #40: Thank you!