Sometimes and for somebody we must start with the result. And here it is – my first contribution to open source accessibility software – aXeSiA – and it’s source code hosted on GitHub (opens in new window). Please note two things though:
- it may be forbidden to crawl some pages. You should check with site owner before crawling the page to be on the safe side.
- aXeSiA software is provided AS IS and without warranty of any kind. Please read the terms and conditions in the GitHub repository (opens in new window) before using it.
Deque’s axe-hackathon and motivation for my contribution
Deque, leading accessibility company that made axe accessibility testing service and browser extension (opens in new window), organized a virtual conference called axe-con (opens in new window) and there they also initiated it’s fifth hackathon, called axe-hackathon.
You have probably heard of hackathons, but to refresh what is the meaning of them – the word is a combination of hack- and thon- primarily based on hacking marathon. So – an event where people can gather and make a software or software related activities like proofs of concepts, minimum viable products or just design and user experience. Main points are innovation and also competition and cooperation.
So – Deque organized it’s fifth hackathon and called it axe-hackathon because of the name of their flag product axe.
I am using Deque’s amazing free browser extension axe on a daily basis and I noticed that they released the engine behind it – axe-core – as a open source (opens in new window). So I decided to try my best and come with a simple tool-set that can make my audits faster and maybe even discover some high-ranking and severe problems, so that I can decide to manually investigate those pages first.
I was thinking for quite some time now that I could automatize testing with axe and also other tools and save some time. Because opening hundreds of links manually and noting the results can really take some time. Manual tests still represent from 60 to 80 percent of all testing efforts, but it would be nice to make care automatic tests catches the problems before we go into manual tests.
I named this tool of tools aXeSiA and wrote a simple introduction that I sent to axe-hackathon.
aXeSiA – so what is it?
I like to play with words sometimes, so when thinking of naming the simple proof of concept I thought it should include axe and because I am also using Siteimprove’s browser extension (opens in new window), another amazing open source accessibility testing tool, I decided to also include it’s command line open source testing tool called Siteimprove Alfa (opens in new window).
So that’s behind the name: aXe stands for axe and SiA stands for Siteimprove Alfa.
aXe stands for axe and SiA stands for Siteimprove Alfa. At the same time I like to think that “axesia” can be pronounced like “accessia”, so really relevant for accessibility, right?
reasons for the strange name aXeSiA
So aXeSiA is an open source based accessibility testing tool that incorporates other open source tools, projects and accessibility testing tools and makes it easier to run multiple tools at the same time. It uses so called Puppeteer to control a (headless) browser (opens in new window), so that it can even run on server with no screen. Puppeteer is also a great framework to enable automatic site interaction, for example click on buttons and so on and it can also generate screenshots of the page with different screen resolutions. I made a simple cookie consent management script, so that we can for example accept all cookies and don’t have any cookie overlays in our screen-shots.
While at it – and because it makes sense – I also included the amazing Google Lighthouse. There I did not put the focus on accessibility alone but rather on SEO, best practices and performance.
As known – hackathons last for a limited time – and I do have a day job – so I limited the project to some minimal features that should be enough for a real world demo.
aXeSiA features – what I selected as a minimum viable product
Due to time limitations I’ve decided to start with a simple feature-set, or let’s say a minimum viable product (MVP):
- parse sitemap.xml file from a domain to get all their URLs (at least those that they want to be found),
- loop through this list of URLs
- possibility to manage cookie consent,
- for each URL – make a screenshot as different device,
- for each URL – generate a axe accessibility summary report,
- for each URL – generate a Siteimprove accessibility summary report,
- for each URL – generate a Lighthouse accessibility, SEO, best practices and performance summary report,
- for whole domain – overall summary on combined axe and Siteimprove results for accessibility (passed, failed, incomplete and inapplicable tests),
- for whole domain – overall summary on SEO, best practices, and performance,
- results saved in local database,
- results presented on a locally hosted webpage,
aXeSiA features – possibilities
Hackathons like to predict the future as well, so I’ve also mentioned additional possibilities that aXeSiA can offer if I have more time or, ideally, if we make a community effort together. Some of possibilities that crossed my mind are:
- add more SEO audits, for example WebVitals that are available as open source NPM package (opens in new window),
- accessibility regression testing – compare previous audits against latest, maybe even compare accessibility tree differences (also match against rendered HTML and discover some problems early),
- user interface regression testing – comparing screenshots and maybe even using machine learning to catch visible and accessibility problems and regressions,
- analyze DOM and events to find possible problematic elements that should use proper semantics. For example a span with “onClick” event that should be a button,
- incorporate machine learning and analyze the historic data to maybe even predict problems (limited to automatic tooling that is),
- combine manual testing results with automatic results and make the scoring and statistics more relevant, maybe even generate accessibility statements with it,
- project management integration – it could be used to follow up on the issues, generate issues automatically for severe problems, close them if we are sure they were fixed and so on.
- if expanding out of open source we could also integrate with closed source APIs and tools, and combine their results with open source and manual,
- usability and end to end testing additions – potentially we could use scripting to automate user interactions and for example audit for accessibility when interactive elements are visible (for example date picker) or maybe test beyond login walls (automate logins and crawl page after successful login),
So the possibilities with current Puppeteer and other open source tooling are huge.
aXeSiA was chosen between many
To my surprise aXeSiA was selected to be on the axe-hackathon but I was unfortunately delayed because of family emergency and was not able to present it personally in the session. I’ve checked the video afterwards and there was a bit confusion about what aXeSiA really is about. I’ve sent them the description with registration but they did not read it. So it is not a mystery why nobody else was involved.
There were some other, much more prominent projects, so I was really surprised aXeSiA was selected but it was never my intention to compete with Microsoft and veterans of accessibility. There was even one project that was very similar to aXeSiA and will try to do some automatic testing with Puppeteer, so I am exited to be there in finals.
Next steps with axe-hackathon and aXeSiA
First step is done – I made a minimum viable product – it works and although code is made quickly and dirty I can get results. Some veteran async NodeJS programmers would probably do it totally different but I am satisfied with it’s current – working – state. I can run it against my sitemap.xml and after some time I get all the results I need.
Next step is to document it and make a video for the finals of axe-hackathon. And after that, regardless of results, I will continue to expand and improve it – alone or in a group.
This is it for this post. I will make a follow-up posts when appropriate – after the axe-hackathon results and if I will add new and more exiting features to aXeSia after I will actually use it in my accessibility auditing and testing.
