web 3d图形渲染器
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

148 lines
7.3 KiB

  1. # axe-core
  2. [![License](https://img.shields.io/npm/l/axe-core.svg)](LICENSE)
  3. [![Version](https://img.shields.io/npm/v/axe-core.svg)](https://www.npmjs.com/package/axe-core)
  4. [![Total npm downloads](https://img.shields.io/npm/dt/axe-core.svg)](https://www.npmjs.com/package/axe-core)
  5. [![Commits](https://img.shields.io/github/commit-activity/y/dequelabs/axe-core.svg)](https://github.com/dequelabs/axe-core/commits/develop)
  6. [![GitHub contributors](https://img.shields.io/github/contributors/dequelabs/axe-core.svg)](https://github.com/dequelabs/axe-core/graphs/contributors)
  7. [![Join our Slack chat](https://img.shields.io/badge/slack-chat-purple.svg?logo=slack)](https://accessibility.deque.com/axe-community)[![Package Quality](http://npm.packagequality.com/shield/axe-core.svg)](http://packagequality.com/#?package=axe-core)
  8. Axe is an accessibility testing engine for websites and other HTML-based user interfaces. It's fast, secure, lightweight, and was built to seamlessly integrate with any existing test environment so you can automate accessibility testing alongside your regular functional testing.
  9. [Sign up for axe news](https://hubs.ly/H0fsN0b0) to get the latest on axe features, future releases, and events.
  10. ## Philosophy
  11. The web can only become an accessible, inclusive space if developers are empowered to take responsibility for accessibility testing and accessible coding practices.
  12. Automated accessibility testing is a huge timesaver, it doesn't require special expertise, and it allows teams to focus expert resources on the accessibility issues that really need them. Unfortunately, most accessibility tools are meant to be run on sites and applications that have reached the end of the development process and often don't give clear or consistent results, causing frustration and delays just when you thought your product was ready to ship.
  13. Axe was built to reflect how web development actually works. It works with all modern browsers, tools, and testing environments a dev team might use. With axe, accessibility testing can be performed as part of your unit testing, integration testing, browser testing, and any other functional testing your team already performs on a day-to-day basis. Building accessibility testing into the early development process saves time, resources, and all kinds of frustration.
  14. ## About axe - our Manifesto
  15. - Axe is open source.
  16. - It returns zero false positives (bugs notwithstanding).
  17. - It's designed to work on all modern browsers and with whatever tools, frameworks, libraries and environments you use today.
  18. - It's actively supported by [Deque Systems](https://www.deque.com), a major accessibility vendor.
  19. - It integrates with your existing functional/acceptance automated tests.
  20. - It automatically determines which rules to run based on the evaluation context.
  21. - Axe supports in-memory fixtures, static fixtures, integration tests and iframes of infinite depth.
  22. - Axe is highly configurable.
  23. ## Getting started
  24. First download the package:
  25. ```console
  26. npm install axe-core --save-dev
  27. ```
  28. Now include the javascript file in each of your iframes in your fixtures or test systems:
  29. ```html
  30. <script src="node_modules/axe-core/axe.min.js"></script>
  31. ```
  32. Now insert calls at each point in your tests where a new piece of UI becomes visible or exposed:
  33. ```js
  34. axe
  35. .run()
  36. .then(results => {
  37. if (results.violations.length) {
  38. throw new Error('Accessibility issues found');
  39. }
  40. })
  41. .catch(err => {
  42. console.error('Something bad happened:', err.message);
  43. });
  44. ```
  45. ## Supported Browsers
  46. The [axe-core API](doc/API.md) fully supports the following browsers:
  47. - Microsoft Edge v40 and above
  48. - Google Chrome v42 and above
  49. - Mozilla Firefox v38 and above
  50. - Apple Safari v7 and above
  51. - Internet Explorer v9, 10, 11
  52. Support means that we will fix bugs and attempt to test each browser regularly. Only Firefox, Chrome, and Internet Explorer 11 are currently tested on every pull request.
  53. There is limited support for JSDOM. We will attempt to make all rules compatible with JSDOM but where this is not possible, we recommend turning those rules off. Currently the `color-contrast` rule is known not to work with JSDOM.
  54. We can only support environments where features are either natively supported or polyfilled correctly. We do not support the deprecated v0 Shadow DOM implementation.
  55. ## The Accessibility Rules
  56. The complete list of rules run by axe-core can be found in [doc/rule-descriptions.md](./doc/rule-descriptions.md).
  57. ## Contents of the API Package
  58. The [axe-core API](doc/API.md) package consists of:
  59. - `axe.js` - the JavaScript file that should be included in your web site under test (API)
  60. - `axe.min.js` - a minified version of the above file
  61. ## Localization
  62. Axe can be built using your local language. To do so, a localization file must be added to the `./locales` directory. This file must have be named in the following manner: `<langcode>.json`. To build axe using this locale, instead of the default, run axe with the `--lang` flag, like so:
  63. `grunt build --lang=nl`
  64. This will create a new build for axe, called `axe.<lang>.js` and `axe.<lang>.min.js`. If you want to build localized versions, simply pass in `--all-lang` instead.
  65. To create a new translation for axe, start by running `grunt translate --lang=<langcode>`. This will create a json file fin the `./locales` directory, with the default English text in it for you to translate. We welcome any localization for axe-core. For details on how to contribute, see the Contributing section below. For details on the message syntax, see [Check Message Template](/docs/check-message-template.md).
  66. To update existing translation file, re-run `grunt translate --lang=<langcode>`. This will add new messages used in English and remove messages which were not used in English.
  67. Additionally, locale can be applied at runtime by passing a `locale` object to `axe.configure()`. The locale object must be of the same shape as existing locales in the `./locales` directory. For example:
  68. ```js
  69. axe.configure({
  70. locale: {
  71. lang: 'de',
  72. rules: {
  73. accesskeys: {
  74. help: 'Der Wert des accesskey-Attributes muss einzigartig sein.'
  75. }
  76. // ...
  77. },
  78. checks: {
  79. abstractrole: {
  80. fail: 'Abstrakte ARIA-Rollen dürfen nicht direkt verwendet werden.'
  81. },
  82. 'aria-errormessage': {
  83. // Note: doT (https://github.com/olado/dot) templates are supported here.
  84. fail:
  85. 'Der Wert der aria-errormessage ${data.values}` muss eine Technik verwenden, um die Message anzukündigen (z. B., aria-live, aria-describedby, role=alert, etc.).'
  86. }
  87. // ...
  88. }
  89. }
  90. });
  91. ```
  92. ## Supported ARIA Roles and Attributes.
  93. Refer [axe-core ARIA support](./doc/aria-supported.md) for a complete list of ARIA supported roles and attributes by axe.
  94. ## Contributing
  95. Read the [Proposing Axe-core Rules guide](./doc/rule-proposal.md)
  96. Read the [documentation on the architecture](./doc/developer-guide.md)
  97. Read the [documentation on contributing](CONTRIBUTING.md)
  98. ## Projects using axe-core
  99. [List of projects using axe-core](doc/projects.md)
  100. ## Acknowledgements
  101. Thanks to Dulin Marat for his [css-selector-parser](https://www.npmjs.com/package/css-selector-parser) implementation which is included for shadow DOM support.
  102. Thanks to the [Slick Parser](https://github.com/mootools/slick/blob/master/Source/Slick.Parser.js) implementers for their contribution, we have used some of their algorithms in our shadow DOM support code.