Axe-linter: Test in Your Editor

[amazonv]

Axe-linter: Test in Your Editor

Type: Breakout

Track: Development

Linters are amazing tools to find basic problems in source code. With axe-linter, you can test JSX, Vue, Markdown and more all at once, without long build steps, or even having to open a browser.

 

>> Okay.  We're almost that time.  Welcome, everybody who has just joining us.  My name is Liz.  I'm from Deque.  Let me go over housekeeping and pass it off to our presenter Wilco and Michael.  We have a got of questions rolling in, guys.  This is early for questions.  Awesome.

Okay, we are at time.  Hi, everybody.  Welcome.  If you're an early bird you said me say welcome a hundred times.  Thank you for joining today's session.  If you're looking Axe-linter test in your editor brought to you by Wilco Fiers and mic Michael.  I'll turn it over to Wilco to get us  going.  Today's session is recorded.  And hosted on demand.

If you do require captions there should be captions right below this video stream.  And finally, as I said, questions are rolling in.  But we'll reserve about ten minutes for Q&A and get through as many questions as we can at the end of today's session.

So with that, I will turn it over to Wilco to get us going.

>> Thank you, Liz.  Awesome.  I'll see if I can try a little bit more time for questions.  It sounds like we might have a lot of them.  I'll give it a try.

All right.  So let's start Axe-linter testing your editor.   So firstly, my name is Wilco Fiers.  Had he him, my  pronouns.  I'm a developer and product owner of reasonable accommodations score in the new Axe-linter.  In case you're wondering where there's a -- in the first slide and not in the second slide.  I don't really know yet.  The marketing team has been super busy.

I'm the facilitator of the ACT task force which seeks to hom anize accessibility test to go resolve inconsistencies between tools, accessibility, auditors and that kind of stuff.  And I'm also the Co-Chair of the ACT rules community group which is focused on a-- I'm a member of the silver task force which is a group that works on WCAG 3.  And with me today is my colleague, Michael.

>> Thank you.  So my name is Michael, is eik.  My prowrnlingses are he him.  I developed Deller Axe-linter and axe define tools for testing.  And I maintain and develop axe core NPM integration.  If you stop by GitHub, you go see some of the work over there.

 

 

>> Awesome.  All right.  So linter.  What is it?  Firstly, I hear we have a listener from Belgium.  So you might know linter Belgium.  It's a lovely little place, somewhere in the middle north of it, Belgium in the province called  south-- which is strange because it's in the north of Belgium.  But not just strange when you think there's a north-- which is in the south of the Netherlands.

So that's linter.  That's what we're talking about today.  I would recommend you go there if you have a chance.

There's also cotton linter which I found out is fibers  peeled off of cotton seeds after ginning.  It's referred to as cotton wool.  Used a lot.  It's another kind of linter.   The kind we're talking about today is the software.

And software linters kind of got their start in the 70s or so.  And is they're used to do code analysis.  Static code analysis.  It's a tool for static code analysis.  What they do is add additional checks for bad design, bad codes, things that look wrong but may not necessarily cause a compiler to fail.  And they're especially useful in  languages like JavaScript which is a typed language, or let's you do anything.

Um, that on a function, hello world with a variable message, that has no body in it.  It will-- the values never read.   That's nice and useful to tell you you did a thing.  It doesn't look like you completed your work.  And by using linters, you get cleaner code.  You get stricter code.   There's less of why is this weird thing happening here?   Going on if you properly use a linter.  Another thing  linters are used commonly is dealing with white space.  Tabs versus spaces, discussion.  If you want that happening consistent, you can use linter.  There are linters that fix this for you.  The so common linters, um, in the JavaScript ecosystem, it's pretty much the go to at the moment.   There's also TS lint which is for type script.  It hasn't been deprecated.  If you are still using TS lint, switch back to ES limit.  It will work better for you.

PY lint is another one.  Check style is in Java.  And there is super linter which is an interesting one.  It's a linter developed by Microsoft.  And what it does it works in GitHub actions and it actually runs various linter.  It returns a bunch of different linters on a bunch of different source files.  All you have to do is set it up that's why it's called super linter because it limits lots of different things.  That's what a linter is.  There are a number of linters out there for testing accessibility issues as well.   There is precedence in here.

Last year, now, I believe a little bit over.  I think it was December 2019.  Deque released a GitHub app that we called  Axe-linter.  This is maybe the first thing people have some familiarity with.  This was essentially a proof of concept for us to show, hey, is this linting thing useful?  If we build a thing, will people use it?  Um, and how would it work?  So what we did there is we did the GitHub app that used some out of the box linters to do things for us.  What we are releasing soon is our very own linter.  No more this out of the box linting system.  Some of the accessibility this thing out there, the post popular is JSX A11Y, it's a mouthful.  JSX Ally which is a plug in for ES lint which helps you test, for common accessibility problems.  It the one of the most popular.  One of the most downloaded accessibility tools out there.  It systems standard with create act, if you're using axe create --

There's Vue Ally.  There's also web paint which is a product developed by Microsoft which I believe available in various ways.  You can use it as a plug in for VS code, for example, and it will heft HTML there.  Kind of interesting, web paint actually uses axe core in the background.  If you have web paint already, you are secretly using axe core as a Lynner it.

And maybe a linter, not quite a linter is Svelt.  It's a JavaScript framework.  It has, when you compile, it will tell you if there's accessibility problems.  It's unique in in that approach.  It the really cool.  I want to highlight this.  I think accessibility moves forward with projects like this where accessibility is built directly into the tool.  If you don't want it, you have to turn it of 0 rather than a thing you install.

But when dealing with linters, there is a lot of challenges.   Linting for accessibility is complicated than automated accessibility existing in a browser.  And before going into Alily I want to show the challenges you get one building a linter.

So I want to go through some of the the examples.

My first one is incleat DOM trees which you get when with development, you use templates.  You may use components.   And so you have a small file with some piece of HTML in it that has, will be embedded should where else in the page.   This is on my screen is a template element with a UL and LI element inside of them.  This is a few component, few users templates at the root.  And inside of that UL as aible ising to the LI, there's a slot-- with a name of list.  And this slot element can be used to place various things in it.  You can put other other elements in it, or tables in it if you want to or buttons or whatever.  When dealing are a linter, this code can about any where in the page.  That is something linter will account for.  And it has to account that slot can be empty or can have lots of different things.

So there's lots of unknowns in dealing with this.

Similar pro be happens with attributes.  I'm showing a code snippet of how it reacts using JSX.  And where there's a mine input component, and props which reacts for attribute and this my input component inputs elements with a dynamic type.  A type is-- if you're using my input you can declare it to be anything.  So, when you're writing a linter, it -- you're not going to know what is happening here.

So it's hard to tell based on this, what that type of can  be.  It could be on the define-- this code does not require that it be a type.  It could be a no attribute.  The other thing with linters is attribute spreading.  In react, in  JSX, you can see in the dot, dot, dot misc here, the way they use it, what it means anything on had misc as an attribute to my input element.  Linters would not even know if there's an ARIA label attribute in this thing if it's disabled in some way.  There is lots of unknowns about this.

There are also components to deal with.  On my screen is a Div that is a text field.  Sorry.  Let me start that again.   Theres a text field component as being declared with the outer element is a Div.  And inside of there is a cool label component with the name label attribute and next to it is afternoon input element of typed text.  This cool label could very well be a label of this input element.  Because it isn't using a native label element, it's hard to know for sure.  There are lots of unknowns in components, too.

And lastly there's no style that's happening.  If you have a button with the well known SR link which is shorthand for only screen reader, this information, because you're testing the source code and not inside of the actual browser, it is not known to a linter read or not.  This text is going to be rendered.

A little bonus, there are in templates lots of conditions.  On my screen is a few template, inside of it a button inside a span with a V-if directive.  The V-if directive is what it let's you is optionally hide.  If the V is true, it will show the element.  If false it will hide it.  This bought ton element may or may not contain a contents.  What do you do as a linter?  If you flag this as a problem, it will fail this button even though that condition may always be true.

There's a i are of false positives in lots of ways that don't exist when testing a normal.  Everything is rendered.   All of the information is available.  Note

Which brings me to Axe-linter.  Axe-linter this new iteration that we are doing is a tool that has, is fully consistent with axe core.  This is one of our first principles that we wanted to adopt when we write, when we want to write a linter.  We need to to be exactly the same as axe core so that, if you have a problem in axe core, you'll also see it in the linter and vice versa.

We do not want due to these minor discrepancies it's important to us the tool you have is reliable and  consistent.  Ax core does that with a heavily relying on the way axe core does thing.  We want falls positives in Axe-linter.  This is not something we can always guarantee.   False positives are bugs, and bunkings are in the software, but if you report it same as axe core, in Axe-linter, we will fix this.

One of the more exciting about Axe-linter to me is that it supports multiple languages.  The linters we've looked at before, Ally, web pains, they only target one specific language and they do it in their own unique way.  The so testing one versus the other is going to be causing consistencies if you're using, for example, if you're using lighthouse or X extension, there is going to be  consistencies between what your linter does and what you get from your extension by supporting multiple languages we ensure that whatever you're using is going to be the same.

So currently, what we'll be releasing with is support for HTML, JSX, TSX, mark down, and vue.  T.  Is X is touch variant-- react essentially.  *

And then what we are also building for -- these are still fairly early is a better understanding of the logic.  It's a conditional logic of your code.  So that, the statement I mentioned before, we want Axe-linter to know what's going out there and give you smart feedback about that.

And another somewhat experimental feature, a feature that my be unique to Axe-linter is the ability to suggest fixes.   This again is still in its early phases.  We have some evident its with JSX to get this working.  And we will be working to expand this to other languages as well.  Really we want to be able to have Axe-linter work in essentially the same way as spelling checker works.  For me that's been a dream that I've been working towards for the last three years.  Accessibility really should work in a lot of ways the same way that a spell checker, woulds.  A little underlying as you write your code, * click on it, it gives you a little pop-up.  It suckings a couple of options, you click the one that's right, done.

As for where you will be able to get Axe-linter, we are releasing Axe-linter in two variants.  There will be Axe-linter in code editors.  We are planning to release an extension for visual studio code this month.  And we are working on Intel J IDEA and web storm as well.  Um, then once you have your code and all done and you're ready to system your code what we have is to have Axe-linter available in request as well.  I mentioned of before we had a proof of concept for GitHub apps and we are releasing Axe-linter in the GitHub app soon.  And we are working at other, on other systems as well, what those might be will be a little bit more later.

For our rules, it probably won't surprise you that we don't have the entire rule set ready to go.  This will be an evolving and moving target.  But what we're releasing with this month are the accessible name rules.  The image ALT, button name, frame title, those kinds of common rules.  And then in addition to that event handler rules, rules like click events has key events, if you want all of the things you do to have a corresponding keyboard accessibility.  Know interactive static role.  If you have an event handler on the static elements that can create a lot of problems.

You want things that can take focus that take events on most events to be focused and to have a role.  Those are going to be available right away.  And currently in had development are what I call attribute rules.  Those are rules that look at specific attributesment there's things like ARIA allowed ATTR which is a rule that checks that the ARIA you're using is allowed on the role or element.  A valid Lange.  Auto complete valid.  Checks auto complete valid.

And can then a little bit further down the line is the parent/child rules, things like checking label.  The contempt of a label and the accessible name mismatch if you have a button and an ARIA attribute, you want those to be consistent.

Rules checking that ARIA required children are present.  If you have a box as an example, that requires a text field and I believe one of a number of components like list, those kinds of rules are coming later on.

So I talked about Axe-linter.  Understanding your language.   My screen are four code snippets the first one is JSX attribute spread where I'm showing how Axe-linter, when there is an image with a source attribute, nothing  happening.  Will flag that element.  But if there's a source attribute and there's attribute spread in JSX, notice element-- that's a attribute sprealdz might include an ALT attribute.

Who this is a few components.  A template element and two buttons inside of it.  Both buttons are empty.  One is the first as an issue and ignores the second because it uses the V text.Ed V text let's you put text inside of an element.

So you'll see here, V text is a view specific thing.  And because Axe-linter understands.  Have ue, it knows what to do here:  Because Axe-linter knows JSX, it knows what this attribute spread means and it knows to ignore it.  This is different from how some more generic-- work, where they have a loose kind of parsing that's happening.  And they make lots of assumptions about the content.  But because Axe-linter understands the language that you're working in, they'll only flag things that are actual accessibility problems.

The next two examples on the screen are two HTML documents one there are there's an HTML element and an input element inside of that and another with a Div and an input element inside of this.  Because Axe-linter understands if you have an HTML element at the top, this is a complete page.  Are input element must have accessibility.  So we are underlining that.  For the Div if you have a HTML file that starts with a Div, it does not require this input element to have an accessibility name because this template may very well be placed inside of a label.

If this template is nested inside of a label element, there may not be a problem.  So understanding the context of the language is very important in why in a lot of cases Axe-linter may not always get quite the thing you want from it.  But it will be very careful to invoke false positives.

So by this point you probably want to see Axe-linter happening.  And that is why Michael is here.  So Michael, tell us what you're going to be doing.

>> Will I'll show you guys what I'll be demoing.

So I am going to be demoing our VS code Axe-linter and GitHub plug in and GitHub app as well.  In front of me is a tight script react project.  Just a basic react project in  VS code.  So in this instance we would install it from the -- when it's out it will be in the marketplace just like any other extension.  So I'll install it on the bottom right you will see it is setting up and fetching the local server.   What will happen is a two step install.  The first installed Accenture and the next install the -- utilize the linter aspect of it.

In the extension it eleven is, you can see that it's a page just like any other extension page with fairly good information since it will show you an overviewpt of what accenture does and also ability to make any additional changes that you may want if you are trying to add specific rules or utilize specific rules disable specific rules this page will help you out with that.  You can also disable specific tags to specific level.  If there are support you need, you can open up the issues in our axe core issue page or different page or feel free to join us on our axe  channel.  We will get into the demo of the Axe-linter.

In demo we will be adding an image to this component.  The image will be of this corgy that is sad when your web page is unaccessible.  I'm going to add an image tag now with a source of corgy image.  And I'm going to close the tag without adding a ALT attribute.  And immediately you can see that the one code is under lined in red.  If you highlight it, you can see that Axe-linter is telling you that you should ensure that the image has an alternative text.  But also a help link to actually see more information on the left-hand side you can see that the file actually changed to red to denote that there is an issue on that page.

 

 

And on the bottom, where your terminal problems and outputs are on VS code, it will show that same information.  And a help URL to actually open up and go to our university page to get more information and why this is an actual issue.

So back to VS code.  The way to fix this is to ad an ALT text.  And ones you add an ALT text, you can see the issue halls been resolved and the code is no longer underlined.  Since we try to stay consistent with our products in Axe-linter, you can see the image is displayed here.  And on the right-hand side if you haven't used it he will feel FreeThink to download on the axe extension, axe Dev tools.   And I'll see if there are accessibility on this page.

It's because it's a scrollable.  Okay.  Live demos is great.   The but this as a spellable content due to the image size.   But once the image has been fixed, it should make it so there are no disability issues.  So once we go back to our code editor we also have testing.  We have unit testing in our package file if you are used to writing a node, you know you can add scripts.  In here we have a test script to run a mocha test and this goes to our index file in our tester.

And in there is actually a brand new package that isn't out yet.  And it is our axe playwright integration.  And it's very similar to our other integrations.  And all you have to do is run that test script which would open up a playwright page to scan the image to see if there are any accessibility issues and we check if the link is zero, and it is.  So there are no accessibility issues at this point with playwright and what we're going to do is now add everything to GitHub.  And now we're just going to push everything to GitHub and I can now show you a full request.  And on  GitHub, I'm going to open the request, create a request, and then you can see our GitHub app.  And it looks like I missed the issue.  So if we go back to our VS code, IDE, you can see that there was an actual disability issue here I had in order so we shouldn't skip headings we can't go from an H1 to an H3.  If I remove that, add everything-- fix.  And you can see that it is no longer an issue.  We no longer have any accessibility issues here.  If you want more  information, you can go to the checks page and look at how many files you scanned if there were any accessibility issues and linting errors.  And for context if there were accessibility issues it would tell you that there are accessibility issue here and that it's failing.  And in the details page or checks tab, you can actually see that and get the same information as if it was just like VS code.

So, you can see that this was the issue.  It is a help URL that you can click.  And you can see that there are one file with an error and in that file there is a single lint error there.  And it also adds a note here that there is an accessibility issue in the files itself.

So that was everything for my demo.  And I'm passing it back onto Wilco.

 

 

>> Fantastic.  All right.  Let me take the screen share.   And as I promised to keep time for questions I'm going to skip over a few slides, I think.  Um, so as Michaelling mentioned, Axe-linter really fills some gaps and let's you code all of the things.  So not only do you write, do tests whether you're editing.  You test with the axe extension in the browser with axe-- or puppeteer or playwright you can automatically test your unit tests.  And in your Axe-linter brings it up again, really gives you full coverage of your development process to test all the things.

I'm going to skip over this part but I'll just briefly mention that Axe-linter has a configuration file which you can change things like rules and what files are being  linted, for example, if you want to exclude testing files.   You may want to configure Axe-linter for those.  Axe core has lots of failing testing files, for example.

I'm going to skip over this question but it is an interesting one.  How much does it test?  The brief answer is we don't know yet.  The way I like to think about Axe-linter is a quality gate.  It prevented various types of accessibility problems from making it into your code base.   If you're using Axe-linter properly, you have it in your editor, sometimes certain issues are not going to make it  in.  It really stops problems from getting to, ever making it to your development.  I think that's the greatest strength of Axe-linter.

As for when we're going live, we are hoping to have, the GitHub app and the VS codex tension available before the end of the month.  We were encountering issue I was hoping we wouldn't have before today.  I think the end of the month is realistic.  So we will try to get this to you as soon as possible.  And Intel J and is web storm we have a go  already, we just need to get to the release process.  I think we can expect that in April.  And there are more iterations coming later.

I'm going to expand on this slide for future possibilities.   Once my slide deck is available, have a look.  I want to emphasize that there's lots of ways and directions we can go with Axe-linter still.  None of this has been decided.  But it's working on more languages, adding more suggestion, features, there's lots of directions to go.  I think this is early days for Axe-linter.  But I'm very excited to see where it's going to go.

 

 

We are looking for customers.  If you happen to work for an organization that has an Axe-linter customer and you're using GitHub in your organization and using react or vue, shall in contact.  We are looking for organizations to do a GitHub trial with.  Those are organizations that we will give access to in March.  Others will come a little later.

And just to summarize, Axe-linter is an entirely new tool that is a source code instead of WebPages.  It runs in your code editors and IDs and runs in CI and integration environments.

Kicking off with VS code with Intel J and GitHub apps support for multi-at this languages and fully consistent with ax axe core.  And with that I'd like to open for questions.

 

 

>> All right.  Thank you Wilco and Michael.  I'm going to pull these up and thank you everybody for all of your questions.  I believe we have about nine minutes.  And if you haven't already, please upload the questions that you think still need to be answered.  Wilco did a great job answering a lot of the questions but go ahead and keep those questions coming.  We may need to have follow-up webinars to get to all of these.

>> I doubt this is the last time we're doing this.

>> We'll see you all again soon, I think.  Okay, let me get started.  This one has 40 uploads.

What is the difference between Axe-linter and a tool like ES lint plug in JSX Ally.  Will they work will parallel?  How are they different?  I know you had slides on this.  A little bit more of a high level.

>> In short, Axe-linter does multiple languages.  So it's not just limited to react.  It's will test HTML-- the and other benefit is that Axe-linter is consistent with axe  core.  If you're using axe core, if you like axe core, Axe-linter is definitely a good thing to look at.  By all means use them in parallel.  JSX is a fantastic tool.  I think Axe-linter can add to that in a meaningful way.

>> Got it.  Next question from jewel, does Axe-linter integrate with ES lint?  I'd love using the Vue Ally linter but it's limited.

>> It does not, no.  Axe-linter is not an open source project.  It will be available for free in various IDs.  We are till still looking at what the pressing model will be for the requirements.  That information should come fairly soon.

>> Awesome.  Thank you.

>> No, it does not integrate with ES link.

>> And Teresa asks for clarification on the difference between Axe-linter and axe core.

>> The most important one is that Axe-linter tests your source code.  And axe corporate tests WebPages.  So Axe-linter can run on your entire code base * all in one go.   And you just have to kick it off to get started.  Whereas if you're using axe core you have to open every single possible page in a browser either automatically or with the browser extension and click the analyze tool over and over again.   So the biggest benefit is the broad spectrum impact that you get from Axe-linter.

>> Okay.  All right.  Next question here, will Axe-linter be available to organizations repos?

>> Um, Axe-linter is going to be available for a GitHub app which you can install on GitHub to run on your request.  We are looking at other testing environments, code resources, Git lab's been mentioned.  We might do Azure as well.  There are so many possibilities.  The options are enormous, and can we are, yeah-- it's still early days.  We will have to pick and choose, I'm hoping we will at some point be able to cover all of those.  Definitely there's a need there.

>> Thank you so much.  Next question, is there some plug in for angular apps?  On the slide, I saw only react JS and  vue.

>> Correct.  Angular is not yet supported.  But we are

 

 interested to support angular as well.  That is up there in my list of languages to add.

>> And then there's a clarification here on the organization repos.  This person says, to clarify the question about organization repos was about GitHub organizations versus, I think, maybe personal.

>> Um, so the benefit of using a GitHub app over something like GitHub actions is you can install it on an entire organization at once.  So you install it once andling it be available throughout the entire organization.  You can even enforce it so that, once you have the app installed it will no longer be possible to merge poor requests that don't pass Axe-linter.  Regardless of what repository it's in.

>> Great.  Thank you, Wilco.  How do you suggest integrating Axe-linter with precommit hook?

  

  

>> At the moment, you do not.  Again Axe-linter is not an open source project.  So you would use it in your editor, and you would use it in on your-- or CI environments.  You could not, I don't think you can get it to run with  Git being hoos.  I am look at that and think of it some more.    *

 

>> Can Axe-linter filter levels of errors from crucial to low?

>> Not at the moment.  What you can do is enable specific rules or disable rules you don't want to run.  So that -- sort and filter in your own.  We are also thinking about adding capabilities to provide warnings instead of errors.   There might be ways to do that.  We are looking at various solutions to that.  So by impact not securely on the list.   I'll add it-- it's a good idea.

>> Awesome.  Thank you, Wilco.  Looks like we've got a couple more Americans here.  So I'll squeeze in as many as I can.

>> Michael, you want to take any?

>> I'm good.

>> Is Axe-linter available to nonprofit organizations?  Is

>> Axe-linter and the editors will be available for free.   It is available to anybody-- um, for GitHub, I don't know yet.  That is yet to be decided how we are going to make that available.  The GitHub app runs a server that does not run for free.  Servers don't run for free.  So we will have to figure out how to pay for that and the development of Axe-linter.

>> Okay.  Question here from Jim.  Will Axe-linter be able to detect keyboard functionality like if the element in question is can be triggered by enter, space keys anything like that in the future?

>> Yes.  This is currently available for JSX and Vue.  And it is functionality I'm hoping to expand on.

>> Okay.  We have time for one more question here.  We'll go with will there be support for Twig blade templates PHP?

>> Um, it's not as high on my list but we definitely consider PHP as well.  I'm hoping to expand support for lots of different languages.

>> Okay.  And maybe just one more here.  This one just came in.  How can we be a part of the alpha or beta releases for Axe-linter?

>> Um, if you are an axe customer get in touch with your Deque representative.

>> Okay.  Awesome.  I think we are about at time.  I apologize if we weren't able to get to your questions.  Thank you, guys.  Thank you, Michael and Wilco for a great session.  Thank you, everybody, for attending and all the engagement in CHAT and wonderful questions that are still coming in.  But we are at time.

>> I am on select-- if you have any questions.  Feel free to reach out to me.

>> Absolutely.  Thank you all.  Enjoy the rest of AxeCon, everyone.