This web application automatically crawls websites and checks for accessibility violations. It can crawl within subdomains of the initial domain it starts with. It reports statistics of violations for the whole audit, domains and pages.
- Install Docker and docker-compose if needed.
- Edit a
.envfile at the root of this folder (next to the README), with the following line ending with your admin password:(this password is needed to create and remove audits)ADMIN_PASSWORD= docker-compose up -d- Direct a browser to
http://localhost/.
- A running audit can be stopped with the Stop button in the form to start a new audit.
docker-compose stopwill stop the containers.docker-compose downwill stop and remove the containers. They are recreated automatically withdocker-compose up -d.
- Get a list of container ids:
docker ps. - Look at the logs for a container:
docker logs <container_id>. - Keep looking in real time:
docker logs -f <container_id>.
(another way to do that is to usedocker-compose upwithout the-doption)
Warning: this will remove all the data !!!
docker-compose down -v --rmi all --remove-orphans- Remove the files.
- Accessibility testing based on axe, which does not return false positives.
- Choice of accessibility standard to use: WCAG 2.0 Level A or AA, WCAG 2.1 Level AA or Section 508.
- Choice of web browser for testing: Firefox or Chromium.
- Option to check subdomains automatically.
- Options to use site maps and/or crawling to discover pages to test.
- Option to limit the number of pages checked per domain.
- Option to include only pages matching a regular expression.
- Results can be browsed on a dynamic website. Access to create new audits or remove them is protected by password.
- Results include violation statistics with links to Deque documentation given for the whole audit (including subdomains), for each domain and for each page.
- Easy way to see which domains or pages are most affected by specific violations.
Besides the required ADMIN_PASSWORD variable, other variables can be used in .env:
MODE: running environment,developmentorproduction(productionby default)RESTRICTED_IP: an IP address which will be the only one able to access the app (127.0.0.1by default for development,0.0.0.0by default for production, set to0.0.0.0to allow connections from everywhere even in development)DEVELOPMENT_PORT: the port used for development (3142 by default)DEVELOPMENT_API_PORT: the port used for API calls in development (3143 by default)PRODUCTION_PORT: the port used for production, except with SSL (80 by default)
- How to set up SSL ?
This could be done with a proxy, but if you want to set up SSL directly in node, this is possible in production mode on port 443:- Add
server.keyandserver.crtinside thecertsdirectory. - Restart with docker-compose:
docker-compose up -d
- Add
- Why would I ever want to not use site maps when they're available ?
Site maps are great to check entire sites. A crawling depth of 0 can even be used when they are complete. However one might want to focus on the most visible pages (based on the number of clicks used to reach them). Ignoring site maps and crawling the sites with a maximum depth is a better option in this case. - How could I check only a part of a site ?
With the "Include only paths matching the regular expression" option, for instance^/section1would only match paths starting with/section1(the paths the expression is checked against start with a slash, but do not include the protocol or domain parts of the URL). - How can I precisely control which ports are exposed by the application ?
Edit theportssection indocker-compose.yml. Development mode needs 2 ports (one for the static web files and one for the API), but production mode only needs 1. - Do I need to add a "delay to let dynamic pages load" ?
The application is always waiting for the initial page load. However some web pages (such as the ones generated by this application!) do a server request after the initial load before they display anything. If the accessibility checks start before content is loaded, they might fail one way or another.
Issues can also occur when a page has a meta refresh tag (see below).
In both cases, adding a delay before the checks after the initial load can resolve problems.
A long delay (such as 1000 ms) is more likely to resolve problems, but it can slow down the audit. A short one (100 ms) might be sufficient for very fast websites, but might not be enough for slow ones. Experimenting might be the best way to choose a value.
- Browsers and drivers might crash sometimes, resulting in scan errors, but the audit will recover and continue.
- Some redirects like meta refresh can also cause scan errors, as the page changes while axe tries to check the page.
- Possibility to access non-public websites.
- Taking
robots.txtinto account. - Option to only start subdomain audits at the root.
- Reporting more than accessibility violations.
- Ability to pause an audit.
- User management beyond a simple admin password.
- Option to ignore pages returning a 404 status code.
- Regular expression to ignore some URLs.
- Easy way to export data.
- Easy way to add branding to the UI.
GPL 3.0.
This project is using the MERN stack. Docker is used for both development and production.
Tests should be run in Docker:
docker-compose run --rm accessibility_audit npm run test:serverdocker-compose run --rm accessibility_audit npm run test:client
ESLint should be integrated in the editor, which might require an npm install on the host machine.
It can also be used to check the whole project, using Docker:
docker-compose run --rm accessibility_audit npm run lint