docs: reorganise the readme #2743
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
One of the most common questions people have is what rules axe-core has, and how they map to WCAG. I hope that by being more explicit in the readme, and putting this section higher up we can limit how often this question is asked.
straker
previously requested changes
Jan 8, 2021
README.md
Outdated
|
|
||
| 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. | ||
| The complete list of rules, grouped WCAG level and best practice, can found in [doc/rule-descriptions.md](./doc/rule-descriptions.md). |
There was a problem hiding this comment.
Another common question we get is about coverage of the rules and if axe can be used to be compliant or ADA maturity. I think it'd be worthwhile to say that the rules don't map exactly to each WCAG success criterion completely as no WCAG criterion can be fully automated.
There was a problem hiding this comment.
Perhaps we could point to the axe extension to give people an option for helping with the stuff that is not 100% automatable.
dylanb
reviewed
Jan 11, 2021
README.md
Outdated
|
|
||
| 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. | ||
| Axe-core has different types of rules, for WCAG 2.0 and 2.1 on level A and AA, as well as a number of best practices that help you identify common accessibility practices like ensuring every page has an `h1` heading, and to help you avoid "gotchas" in ARIA like where an ARIA attribute you used will get ignored. With axe-core, you can find **up to 50% of WCAG issues automatically**. |
There was a problem hiding this comment.
Add a mention of the needs review items?
straker
approved these changes
Jan 13, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
One of the most common questions people have is what rules axe-core has, and how they map to WCAG. I hope that by being more explicit in the readme, and putting this section higher up we can limit how often this question is asked.