Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up

WAI-ARIA Authoring Practices Guide (APG)

License

NotificationsYou must be signed in to change notification settings

w3c/aria-practices

Repository files navigation

This repository maintains the WAI-ARIA Authoring Practices Guide (APG).

Please do not provide commit access to this repository without coordination.

How the work is organized

  • Work is planned and prioritized in ourmilestones. Each milestone corresponds to a working draft or release published to w3.org.
  • Work is organized by topic in ourprojects. Each project corresponds to a type of design pattern or section of guidance.
  • Thescope of work and roadmap are described in the project wiki.

Contributing

  1. Comment in an existing issue or raise a new issue, expressing your willingness to help and briefly summarizing the nature of your proposed resolution.
  2. An editor will confirm there are no conflicting plans and, if needed, provide guidance.
  3. Be sure you have linters installed and configured as described below.
  4. Read our wiki page aboutsubmitting pull requests.
  5. Do some fabulous work and submit a pull request.

Note: Please feel free to ask questions either through an issue or on theAuthoring Practices Task Force mailing list.

Code conformance

This repository utilizeslinting 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 thecode 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:

  1. Make sure that you haveNode.js installed, which comes withnode package manager (npm)
  2. Open the directory that contains youraria-practices repository in a terminal
  3. Runnpm 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 andEditorConfig.

HTML

HTML is validated against theNU 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

CSS is validated bystylelint using thestylelint-config-standard ruleset.

NOTE: on commit, stylelint will be run on staged CSS files. If errors are found that can beautomatically fixed with the --fix flag, they will be fixed and the changes committed.

Run locally:

npm run lint:css

JavaScript

JavaScript is validated byESLint, usingour own config.

NOTE: on commit, eslint will be run on staged CSS files. If errors are found that can beautomatically fixed with the --fix flag, they will be fixed and the changes committed.

Run locally:

npm run lint:js

Test and fix your code

  1. Open a terminal window to the directory that contains thearia-practices repository
  2. The repository has a script defined that will test all JavaScript in the examples directory. To run it, execute the commandnpm test. Note: this may take a few minutes to run and will open several browser windows during the test that will gain focus.
  3. Many errors can be fixed automatically with the commandnpm run fix.
  4. After running fix, test again to see what you need to fix manually.

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 willindicate the character or place in the line that raised the style violation. Tofix an error, satisfy the change that the violation indicates.

For example, here is an error for an invalid variable name style. Variables mustfollow a camelCase convention.

/Users/user1/Documents/github/aria-practices/examples/slider/js/text-slider.js  19:8  error  Identifier'value_nodes' is notin camelcase  camelcase

The error occurred inexamples/slider/js/text-slider.js, on line 19 and theoffending character is indicated by the number8 after the colon. Change thevariablevalue_nodes tovalueNodes in your source file to eliminate thiserror.

To see the complete list of style rules that are applied by ESLint, review the.eslintrc.json file in the root of the project.

Editorial documentation

See theAPG Editorial Style Guidelinesfor information about writing prose for the APG.TheReadMe for the ARIA specificationcontains additional useful editorial guidance.


[8]ページ先頭

©2009-2025 Movatter.jp