npm npmCamp Presentations (2016), 30 Aug 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: npmCamp 2016 - Testing for Accessibility with aXe by Marcy Sutton

Description

Testing for Accessibility with aXe by Marcy Sutton

A

I'm Marcy I'm here to talk about accessibility, testing with ax, which is well you'll, find out what it is. I did live in Seattle until very recently, I just moved to Bellingham Washington, which is about 85 miles north right by the Canadian border. I went to go, live near the edge of a forest, I mountain-bike a lot, which was why I have bruises sometimes, but that's a big part of my lifestyle. So if you do go to Seattle, sadly I'm, not there anymore, but it's still in my heart grew up there.

A

You can find me on Twitter at Marcy, Sutton I, often answer accessibility, questions just because I'm curious to know the answer. If I, if I, don't I'll connect you with someone who does I'm a senior front-end engineer at DQ systems, which is an accessibility only company, that's all that we do, which is really cool to have a company whose mission is for digital equality, then they're, headquartered back east, but I work remotely from Bellingham, oh and I wanted to mention.

A

If you want an axe, sticker I have some so come, say hello, so test automation at some point. In my career, I did not know how to write software test, so it was a front-end developer and I saw a lot of broken stuff, go out. The door and I really felt like Toni Braxton, and this gif going, who once I learned about test automation.

A

I, could feel more confident that I could prevent broken code from going out to production, and then accessibility was something I learned about in my career, as well as a way to help more people with the web. There's a really great trailer for the Rio 2016 Paralympics called where the super humans and I have a screen capture from that with a little boy, with the prosthetic raising his hand in class and depending on how that prosthetic works or, if he's not wearing the prosthetic.

A

That would impact how he, how he navigates the web you'd probably have to use a keyboard or use speech-to-text. You know different ways of navigating the web and there's all different kinds of people that navigate the web. That might not be able to use or might not be able to see the screen.

A

People with disabilities in some fashion make up about one-fifth of the world's population, so it's it's often swept under the rug or forgotten about or said, that's not our audience, but I challenge you to take another look and really consider people who have different abilities, and maybe that'll be you future. You never know, but this includes people with visual disabilities, including people who are blind from birth or have degenerative vision, loss, people who are low vision.

A

Maybe they can see some, but they have blotchy spots or you know different varying degrees of vision, people who are color blind, really really common, especially in the male population, people with hearing disabilities, including people who are deaf people who are losing their hearing over time, people with motor disabilities. You know spinal cord injury, multiple sclerosis, cerebral palsy, many different disabilities go into this motor category and it it really means that people can't use a mouse.

A

You know they interface with the computer in other ways and then there's cognitive disabilities, including autism, learning disabilities, traumatic brain injury memory and attention, and so we need to give people a little more time and simplify things to make sure that they can navigate.

A

So how do these two come together, because this is always where you know my style of approaching accessibility and messaging it to you at a mainstream conference? It's how does accessibility, you know where does that fit into whatever topic? And today I want to focus on automated testing, because in my career, that's how I've managed to really prioritize accessibility in the development workflow is by making it modern and finding ways to automate it.

A

That means testing for low-hanging fruit, finding things that you might miss just because you're human and you can use a little help from automated automated testing.

A

You can document accessibility, intent if you're working on a website or web application or a UI framework I used to work on the angular material framework and by having accessibility in your automated test, you can document how they're supposed to work for accessible. You know how is this thing supposed to work with the keyboard? If you have it documented in your test coverage, it makes it a lot clearer to other people who jump in to say this is supposed to work like this with the keyboard you can prevent regressions.

A

You know, as I mentioned, why I got into test. Automation was to prevent broken code from going out the door. I was the one to break it sometimes, but sometimes other people break it. Maybe they don't fully understand how something works for accessibility, and if you don't have test coverage, you might inadvertently break something. So by having test coverage for this, you can have a lot. You know cleaner code preserved over time and then by including things like accessibility. Api is like the one I'm going to tell you about today.

A

You can get help from experts by having all of their knowledge bottled into that that product or that API you're, really extending your own test coverage to include things that you didn't have to write at one point, I thought a cool side project would be to write an accessibility, checker and I got as far as labeling and then I realized, there's so many different ways to label things in what we call accessible named calculation.

A

That I really didn't know that much about it and I've I've learned a lot more and now I work with a team of people who know every niche about it. They know every browser bug and every assistive technology bug that might not ever get fixed. So in api's for accessibility, you can kind of work around those limitations and have it built into the API and by pulling that into your tests, your automatic ly. Getting that help.

A

I don't focus on this too much in my talks, but I wanted to bring up some guidelines that really drive some accessibility work out in the field that includes the web content. Accessibility guidelines we're currently on version 2.0 and section 508, so these are guidelines that really outline how to make something accessible and section. 508 is the version that adheres to government-funded applications and websites. So if you're writing something for the government, you are legally bound to make it accessible, as as they say in Section 508. What CAG is the more general version of that?

A

It's not tied to the government per se, but they're guidelines that really help you get there. You know help you have a roadmap for making something accessible and I. Don't focus on this too much because it's not as exciting but I wanted to at least make you familiar with these two things, because they will come up again later.

A

The accessibility testing situation, so we can automate testing in browsers, but we can't really automate screen readers yet I'm, hoping that this changes. But what this means is that, if you're building something for a blind person who's using a screen reader, you can't exactly automate the screen reader to check that it's working correctly, but we can get pretty close by following best practices.

A

You know by by knowing what some of the common problems are if we can develop and design for those problems and use development tools that can help us get there and we can sort of there might be quirks, but we can get a really long way just by following best practices and using development tools to help us get more insight in how to make something accessible, so testing some low-hanging fruit.

A

There's a lot of easy wins that you can do for accessibility, and the first thing you could do is use your keyboard. I know this is the talk about automated testing, but that's my number one testing tool is the keyboard and you can automate that and I'll show you how to do that a little bit, but some other easy wins. That tools could help. You find include missing labels, invalid Aria attributes or other markup problems in your HTML. If maybe you spelled it roll wrong or you just wrote an attribute incorrectly.

A

An automated tool could help point that out to you, so it doesn't ship out to production and end up being a big old mess. You could test for color contrast across your whole application, so that people with low vision would be able to see things better. That would help pretty poor contrast on a monitor, for example, so a lot of these things they might be rooted in you know a really stark need for somebody who has a disability, but it ends up benefiting everybody. When you can do all of these things.

A

You know for one example: a missing label in a form if you correctly bind a label element and an put element. When you click on that label, it will send your focus to the input, and so when those are correctly bound that will help a screenreader identify what that input was for, but it really expands the hit area for everybody and there's so many comparisons like that and accessibility that this really ends up benefiting so many people that, like that's, why I like it I think it's pretty awesome. So how does this factor in NPM?

A

We have a package on NPM called axe core and it's a XE core and you can go into NPM, pull down this module and have an API available to you to audit your webpages and tell you.

A

You know some easy ones that you may have forgotten some rules for X, core or chip for us, the rules as maintainer czar that we want it to have a zero false positive rate, so make sure that the things that it reports to you are actual problems, because otherwise you'll kind of filter it out and go and not put that much faith in the results that it's reporting to you.

A

We want it to be lightweight and fast, so not make you have to go hit the network to let your code grow legs to go out and you know get a response from some accessibility. Api. You can run everything locally. You could run it sitting it on an airplane with no service. As long as you have this module installed, you can run these accessibility checks, be it on localhost or some remote URL. We want them to work in all modern browsers, including touch devices and the rules themselves are tested.

A

So we really dog food, this concept of accessibility testing, so that all of our rules and things are automatically tested. So we have a lot of fixtures in our library that set up these common problems and we make sure that we're catching those errors correctly.

A

So ax score is a JavaScript library for accessibility, testing, it powers, browser extensions and other test integrations. We have one for visual studio. It reminded me earlier with that great Microsoft Talk that there is a community, contributed web accessibility checker for visual studio. It's actually integrated into Vorlon js2, which is another Microsoft remote debugging tool.

A

But if the axe core is the list of rules and the underlying engine for running all these audits and that's very extensible, since it's an NPM module, it's a handy unit, testing tool as I'm going to show you, because once you have this pulled in, you can use the API to run these tests. And then you aren't having to write those label tests like I, tried to write I learned how hard that was. It's open source on github, so we take feature requests.

A

You know if you have an issue if you're finding like hey this is actually accessible and it shouldn't be a failure. We will work with you to get that addressed in the next version. I have an asterisk because there is an enterprise counterpart to X core. That is how we fund it. I've worked on angular before and seen other projects how they work and I like this model. A test is the enterprise counterpart to ax that lets us fund development. So we can offer this really valuable API as a free, open source module. It's just.

A

Those updates to the open source version take a little bit longer than the enterprise one.

A

So the list of rules for X core can be found on github under our Docs there's a rule descriptions list, and this is handy because every rule has an ID, and so you can turn these rules on and off, using your configuration and then each one of these rules. Maps back to mechag or section 508 that I mentioned earlier so and there's also best practices rules in there that don't quite fit into either one.

A

But this is useful because it's actually rooted in the legal requirements that you would have to hit to make something accessible, there's all different kinds of api's for accessibility and some different checkers and I like this one, because it it has those low false positive rates, so it'll you can guarantee that it will find actual problems. But then, if you're legally, you know if you've been sued or you're trying to avoid that. You know by following these things.

A

You can rest assured that you are actually meeting the legal standard for accessibility and there's things like Aria attributes checking whether tabindex has been used correctly and all different kinds of rules.

A

So a quick demo just to show you later on when we run unit tests, what we're actually getting the browser, extensions, there's, a chrome one and a Firefox one, I'm gonna go pick on a website, see I need my toolbar now. So, let's see how NPM camps website looks for accessibility, everyone's creating in their boots, so once you've got it installed. This is the Chrome extension. I can go to the axe. Tab and I've got this big button. That's like click me and actually NPM camp site is, is pretty good.

A

There's only one failure and it's about color contrast. So when I run this checker there's it says, there's 44 violations, so that tells you that overall, the styles for this site could be boosted.

A

The colors could be boosted a bit and there's an actual ratio that you can hit to make sure that there's enough range in the colors between foreground and background that they become more visible but axe will tell you what element it was it'll tell you which, which tag it's under either a KAG two double-a or like which actual mechag rule it's supposed to follow and if I inspect I can go and look at each element that it caused a failure.

A

Failure is such a drastic word. Isn't it? It's really should be noted that accessibility is it's a continuum. It's not a checkbox. So really what we're hoping from people is just recognize that you might need a little more accessibility support and you can add it as you go. You know iterate on it. It might not be perfect overnight, but as long as you're willing to work on it and and really accept that your users have disabilities, it's like that's what we want.

A

We just want you to work with us to make things more accessible, so NPM camp site is it's doing really great. I want to show you one that isn't. It has way more failures amazon.com if we run a checker, it takes a second depending on the size of the the Dom, but they have a lot of different rules that come up. Rule failures like area elements missing alternative text.

A

They have the dreaded color contrast, multiple IDs, the HTML element needs a Lang attribute form elements must have labels it'll, give you suggestions of ways that you could fix this. So those results are specific to this website. They give you things, you can go and inspect and act on, and so for me as a developer, like I, went to work on this tool because I thought it was really useful, and so that's why I'm working on on ax.

A

But those are the browser, extensions, toolbar, so moving past rouser extensions, because that is a pretty manual process. That's something you could run at any stage and I encourage you to do that, but where the real power happens is if you could prevent a build from going out the door because things regress or because it had failures.

A

So that's really the you know the game that I'm after is trying to prevent accessibility, regressions and really catching these in the modern development workflow, because if you're like manually doing it once in a while, that's good, but it would be better if it was throughout your stack, you you have different people in the organization who take responsibility for it. If you put it in part of your development workflow, it becomes more people's responsibility and you can really see changes over time. So you could document the accessibility intent as I mentioned.

A

You know making sure that's clear that something is supposed to work a certain way in your tests and you can prevent regressions by having tests written and then, if they break, you know some tools for the job that would help you do this. Our axe core, as I mentioned, and then axe, webdriverjs and so I'm, going to do.

A

Demos of both of these tools show you what they are, how you can use them the XCore api in the latest version we just launched version 2.0, 0.5 and there's a few really handy API methods, including Ali check, an ally or a11y. If you're not familiar it's, maybe you see it a lot. You're like what is that I tweeted a lot? It's a new marin in for accessibility, so there's 11 letters between a and Y gives you a little shorter hashtag.

A

But Ali check is the method you can call to actually run the audit so and we'll dive into that in a second there's. Also, ax, don't get rules so you can go and get all the rules. Have it returned to you all of the rules that enabled it for some reason you need a list, you can run ax, dot, configure and pass it an options, object and then turn rules on and off.

A

So I showed you that rule descriptions page on github that had the tag name for each rule, you can turn them on and off using those those rule IDs. And then, if you have configured some custom configuration you can reset it back to the default with X star reset, there's also a plug-in system. You can register plugins and then you can clean up if you, if you have register to plug-in and you need to turn it off or reset it, you can run ax cleanup and the entire API you can find on github.

A

So let's take a look at ax dot le check the context that you can pass in it defaults to the document, but say I want to run a unit test on a certain part of the document. I, don't want to run all of the tests like, for example, we had some tests in Ex core the actual core tests, because we weren't limiting the context in our mocha test Runner, which has a handy web page.

A

It was actually running the rules against the mocha, the chrome, in their tool, which wasn't what we wanted for our own tests. So I used this configuration to exclude that part of the document. So maybe you want to scope your unit test to be a true unit test and be a smaller part of your application. You can set up this context to either take an element reference that you've already queried in the Dom. You could pass it an element selector or you can set up this.

A

What we call an include, exclude object where you pass in an array of things you want to exclude and or things you want to include, and these parameters are listed on our API on github, so you can go and read about it all. The options there's also a config that you can pass in as the second parameter, where you can go and turn rules on and off, or you can change how they work completely and you can actually configure it with your own rules using the axe, configure method, so you've got the context.

A

You've got the configuration object which you could pass in an empty object. If the defaults are fine and then you have a callback function to actually do stuff with the results and the results that you pass back have a bunch of good stuff that we saw in action in the browser extensions. So things like what node was it? What rule was it? What all different kinds of things?

A

There's there's way more, that comes with that results, object and we'll see it in a second so to write some unit tests in your project, you could run npm, install axe core and then save dev, as we heard in steve's talk, which was super helpful. There's, it's amazing how many things you just missed somehow that he brought up in his talk. So if we do save dev, you can add this to your testing, testing, workflow and then to run the tests and it doesn't really matter what test framework are using.

A

You could use mocha, you can use jasmine, so you include or require axe core as a module and then once you have that that variable for X, you can run ax out le check and so I have a test setup where I'm describing a custom component. I have a test for it should have no accessibility problems because we're running the the axe rules. You can scope it right to be the document or a single element, but it's going to run all of the tests by default. So in theory the set of tests will help.

A

You find the majority of accessibility problems. So it's sort of a like. This is a really powerful test to write because you're pulling in this API you're, not writing every individual test yourself, and so, while tests are usually more granular for unit tests, this one's pretty pretty bulky because it's running all of those rules against your one component.

A

So, once that in the callback function, once we have a hold of the results, we can expect that the results dot violations array that it passes back to you has no violations, there's a passes array and a violations array, and if it has, if it passes everything awesome. But if it has some issues there the results at violations, there will be content there, and so we expect there to be none and you could write I've written some custom checkers for this.

A

I'm blanking on the name right now, but there's ways that you could modernize the expectations to be a little more user-friendly as well.

A

So let's go do a demo Jazmin mattress, that's the word. I was looking for so on. Github I have an axe, Jasmine unit demo, that you can go and check out to just have some unit tests using Jasmine and let's go check it out: ax @ Jasmine. So in my package.json- and this is where I found Steve talk to be very useful because you can set up some build scripts to this particular demo uses grunt, but you could use plain node scripts as you'll see in the next demo.

A

So I've got grunt doing it's got a the grunt contribs asmin module that I'm pulling in and then I can pass it. The axe tell it to go. Look for the axe. Edge is file which comes with axe core when you download the module and then I'm telling it to go and look at my tests in the spec directory. So if we go and look at the the test, spec directory in this unit test, I am sort of setting up a little document fragment. So I've got some HTML.

A

That should be good and some HTML that should be bad, and so what I can do is go and pass that element into my unit test and you can go get it from wherever it could come from an API. It could come from a fixture, although that starts to get into more and n tests, which we'll look at next, but really what we want to check is that there's no accessibility, failures on this thing and that it stays that way. So we can prevent regressions right, so I've got this element.

A

I can pass it in and I'm scoping it to the taco button, which is a button with the element of or an ID of taco button, and so when I pass. The taco button in I want to make sure there's no accessibility failures, and this is a pretty small component. It's just a single button, and so it should be fine and it is, and then the next test says that it should report that there's some bad HTML in there now I've got a field set in here with an input and it has no label.

A

It has no legend, it's it's sort of missing all of the pieces that would make it a usable input. So if we go over the command line- and I run npm test because I'd hooked grunt into my npm scripts- it will go and run grunt jasmine and it will pass both of these tests because that HTML was fine. I have a little optional console.log statement with the entire object that ax returns.

A

So you could turn that on and off depending on if it's useful, but it will actually report back the same failures as the browser extensions. So if you're, comparing one of the other, it's sort of just a useful thing to know that it is the same set of tests in the browser extension as the unit tests.

A

Okay, so that's a quick unit test demo with Jasmine the next tool I want to show you is ax, webdriver Jas and that's an open source library that injects ax core into selenium webdriver instances. So, in the Jasmine unit test demo, we were using phantom, which is a headless browser. It will just run the tests and then you know be done.

A

Selenium webdriver in comparison will actually open up a browser instance which is really useful if you are trying to catch things like focus, there's some issues with phantom and actual focus of elements, if they're not attached to the dom, you might run into issues and so end-to-end or integration tests with selenium webdriver for accessibility are super helpful because you can programmatically go and check the accessibility of things in an actual browser, so X webdriver jeaious just does that like hook up for you and it's also available on NPM and on github, so some integration testing, we can just pull in these modules.

A

We've got selenium webdriver we set up a builder and then we go and get a URL and analyze. So it's it's similar, but it's promise based and you have to do a little more work so quickly. I'm gonna go and look at this other demo and we're actually testing a pattern. Library from ebay called mine patterns, and it has a bunch of accessible patterns and they started off really they're actually really accessible.

A

But I had written this demo awhile ago and I had test coverage to say that it should change state with the keyboard and I'll show you this so I've got these patterns, we're looking at the radio button demo and these things work pretty well. I can use the keyboard or you know, navigate and everything and all the stuff, but I'd written this test a while ago, and actually there was a regression in the library that I found because it all of a sudden these were failing yesterday and I'm like whoa.

A

What happened, because there was a regression in the successful component library. So this is really valuable, but the part I want to direct you to is the actual axe call, and so it's really similar to the unit test. Except we need the axe builder, which is X webdriverjs and it does the job of injecting axe into the browser that selenium opens once it's done and it comes back. We have a hold of that same results, object and I can expect that there are no violations. So let's go run that really quick see.

A

So I can run NPM test because I have that set up in my MPM or package a JSON file so I have it consoling out the entire results object, which gives me a lot of useful things that the browser extension would tell me as well, and there there's a failure. So it expects there to be looks like there's a missing Aria attribute, so those custom radio buttons when they before you've interacted with them.

A

It should say Aria check false so that a screen reader user knows that this radio button isn't checked so to fix this, which I'm out of time so I'm not gonna, go fix it. But what you would have to do is go into that radio button component.

A

Add an aria check false so that it has a default value and then that test will pass, and so by having test coverage for the sort of stuff, you can totally prevent accessibility failures from making it out to production, which is awesome because that's that's why I got into this business so I'm seeing it actually happening, and it's really really cool so quickly getting some help from experts because, like we don't know everything like sometimes we need to reach out for help and there's lots of places.

A

You can do that, but Forex specifically I want to get you familiar with who you might be asking for help besides myself so Dylan barrel is the CTO of DQ and he's just a JavaScript ninja and knows everything about both accessibility and JavaScript super cool wilco fires is from the netherlands. He used to work on the quail Jay s automated testing framework, so he knows his stuff too, and then Ian Kelly is very knowledgeable as well about all of this kind of stuff.

A

So if you come and find us in our git er room, any one of us might be there to answer a question. It's hooked up to the XCore github repository, so you can come in and ask a question about. You know: hey I'm, stuck on this. How do I get this set up or hey I'm, seeing this issue like failing, but it's really not an issue.

A

It seems like a false, positive, come and tell us, and we can help you figure it out and on the similar vein, our github issues are always there, for you know filing issues, Gators probably better, for asking questions, but it is open source. So we're always there to take your questions to accessibility and beyond Thanks.

A