Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Accessibility Testing Tools for Developers - Gerard K. Cohen - CSUN 2016
Similar to Accessibility Testing Tools for Developers - Gerard K. Cohen - CSUN 2016 (20)
Recently uploaded
Recently uploaded (20)
Accessibility Testing Tools for Developers - Gerard K. Cohen - CSUN 2016
- 1. Accessibility Testing Tools for Developers
- 2. CONTACT Accessibility Testing Tools for Developers Gerard K. Cohen Front-End Ux Architect/ Senior Accessibility Lead Wells Fargo, Wholesale Technology Services email://gerardkcohen@gmail.com twitter:// @gerardkcohen
- 6. BASIC TESTING Accessibility Testing Tools for Developers HTML Validator https://validator.w3.org/nu/
- 7. BASIC TESTING Accessibility Testing Tools for Developers HTML Validator Web Developer Tools http://chrispederick.com/work/web-developer/
- 8. BASIC TESTING Accessibility Testing Tools for Developers HTML Validator Local Validator https://github.com/validator/validator
- 11. BASIC TESTING Accessibility Testing Tools for Developers TAB KEY
- 13. BASIC TESTING Accessibility Testing Tools for Developers tabindex=“-1” tabindex=“0” tabindex=“1”
- 14. Basic Tests HTML Validation Keyboard focus with TAB
- 15. CSS Bookmarklets
- 16. CSS BOOKMARKLETS Accessibility Testing Tools for Developers debugCSS Developed by Yahoo! http://yahoo.github.io/debugCSS/
- 17. CSS BOOKMARKLETS Accessibility Testing Tools for Developers Diagnostic.css Developed by Karl Groves http://www.karlgroves.com/2013/09/07/diagnostic-css-super-quick-web-accessibility-testing/
- 18. CSS BOOKMARKLETS Accessibility Testing Tools for Developers Revenge.CSS Developed by Heydon Pickering https://github.com/Heydon/REVENGE.CSS
- 19. CSS BOOKMARKLETS Accessibility Testing Tools for Developers Custom Rules
- 20. CSS BOOKMARKLETS Accessibility Testing Tools for Developers Custom Rules Ex: CSS Toolbar “Widget” role=“group” aria-label=“some label”
- 23. JS Bookmarklets
- 24. JS BOOKMARKLETS Accessibility Testing Tools for Developers tota11y Developed by Khan Academy http://khan.github.io/tota11y/
- 25. JS BOOKMARKLETS Accessibility Testing Tools for Developers HTML CodeSniffer Developed by Squiz http://squizlabs.github.io/HTML_CodeSniffer
- 26. Browser Plugins
- 27. Browser Plugins Accessibility Testing Tools for Developers Web Developer Tools Developed by Chris Pederik http://chrispederick.com/work/web-developer/
- 28. Browser Plugins Accessibility Testing Tools for Developers Accessibility Developer Tools Developed by Chrome
- 29. Browser Plugins Accessibility Testing Tools for Developers WAVE Developed by WebAim http://wave.webaim.org/extension/
- 30. Browser Plugins Accessibility Testing Tools for Developers aXe Developed by Deque http://www.deque.com/products/axe/
- 31. Browser Plugins Accessibility Testing Tools for Developers Tenon Developed by Karl Groves http://tenon.io/
- 32. Advanced Testing
- 33. What’s Next?
- 34. Conclusion
- 35. CONTACT Accessibility Testing Tools for Developers Gerard K. Cohen Front-End Ux Architect/ Senior Accessibility Lead Wells Fargo, Wholesale Technology Services email://gerardkcohen@gmail.com twitter:// @gerardkcohen
Editor's Notes
- Good afternoon, 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 decided to get the weekend started a little early, so thank you for being here with me. My name is Gerard K. Cohen, and I work in the Wholesale Technology Services division of Wells Fargo as the Front-end UX architect and Senior Accessibility Lead on our framework team. The WTS division provides about 80+ applications to serve companies with their commercial banking needs from payroll to wire transfers. I work on a team that develops the framework used by application's to provide these services and one of most important things we do, besides provide a reliable, performant, and secure set of widgets, is to ensure that all of the widgets in our library, around 50, are accessible. It's a tough task. Last year at CSUN I spoke on my experience in choosing an accessible ui framework, where I compared a few different frameworks and libraries to demonstrate the various accessibility efforts of each, or lack of. Was anyone here for that? Thank you for returning! This year, continuing with my experience, 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.
- 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
- 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.
- 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.
- 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.
- 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)
- 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)
- Now, the next tool is even more basic than validation but just as important.
- 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
- 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:
- :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). 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.
- 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.
- 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, 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
- 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.
- The first one to check out debugCSS, developed by our good friends at Yahoo. http://yahoo.github.io/debugCSS/ (READ OUT URL)
- 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)
- 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.
- 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.
- Mainly, the use of role=group and a unique aria-label. So this basic CSS helped with that
- TYPO IN CSS
- A step up from there, are some more serious bookmarklets using JS. These are really nice.
- 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.
- 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
- A step up from bookmarklets, are browser plugins.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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)
- 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.
- Thank you!