This repository maintains the WAI-ARIA Authoring Practices Guide (APG).
Please do not provide commit access to this repository without coordination.
Note: Please feel free to ask questions either through an issue or on the Authoring Practices Task Force mailing list.
This repository utilizes linting tools to do static code analysis and ensure consistent code quality across HTML, CSS, and JavaScript. Each linting tool and respective code standards are documented below and in the code guide.
Pull requests that contain linting errors will not be merged until the errors are resolved. To make this easier, you can install and run the tools locally before pushing code. Also note that the tools for CSS and JavaScript will automatically fix many issues if you have them installed locally. To install these tools:
aria-practices
repository in a terminalnpm install
The HTML validator also requires the installation of a JDK in order to run. If you don't already have a JDK installed, download the latest JDK from Oracle.
It is also highly recommended that you use a code editor that supports these tools and EditorConfig.
HTML is validated against the NU HTML Validator. Should a warning or error occur because a future ARIA feature is not yet implemented, it will be added to the .vnurc file, allowing the error to pass through.
Run locally:
npm run lint:html
CSS is validated by stylelint using the stylelint-config-standard ruleset.
NOTE: on commit, stylelint will be run on staged CSS files. If errors are found that can be automatically fixed with the --fix flag, they will be fixed and the changes committed.
Run locally:
npm run lint:css
JavaScript is validated by ESLint, using our own config.
NOTE: on commit, eslint will be run on staged CSS files. If errors are found that can be automatically fixed with the --fix flag, they will be fixed and the changes committed.
Run locally:
npm run lint:js
aria-practices
repositorynpm test
. Note: this may take a few minutes to run and will open several browser windows during the test that will gain focus.npm run fix
.When the linter encounters errors, it will report them in the console. The error report will contain the file name and line number, and it will indicate the character or place in the line that raised the style violation. To fix an error, satisfy the change that the violation indicates.
For example, here is an error for an invalid variable name style. Variables must follow a camelCase convention.
/Users/user1/Documents/github/aria-practices/examples/slider/js/text-slider.js
19:8 error Identifier 'value_nodes' is not in camel case camelcase
The error occurred in examples/slider/js/text-slider.js
, on line 19 and the
offending character is indicated by the number 8
after the colon. Change the
variable value_nodes
to valueNodes
in your source file to eliminate this
error.
To see the complete list of style rules that are applied by ESLint, review the .eslintrc.json file in the root of the project.
See the APG Editorial Style Guidelines for information about writing prose for the APG. The ReadMe for the ARIA specification contains additional useful editorial guidance.