docbrown/docs/tests/accessibility-tests.md
Jacob Herrington 7d0aeeefe5 Improve the clarity of the docs and fix Prettier config (#4899)
* Improve format and clarity of the docs [ci skip]

While this change produces a lot of git noise by enacting what seems
like an arbitrary linewrap on most of the files in the documentation it
will result in better version control and tracking of the changes in the
documentation.

For example, as it currently stands, if one was to make a
PR to move a comma in a sentence because each paragraph in most of the
files is on a single line, that small change would look in the git
history like the author had modified the entire paragraph. In reality,
this author just moved a comma.

This change also includes a significant number of modifications to the
more article-esque docs. Many of these docs were written in a sort of
stream-of-conciousness and aren't as easy to read as they could be.
Hopefully this is the first of several readability changes. If we could
get these docs to a more accessible reading level, we would probably see
an increase in contributions. :)

* Delegate markdown wrapping to Prettier

* Add linewrapping explanation in the docs [ci skip]
2019-11-26 08:40:53 -05:00

1.4 KiB

title
Accessibility Tests

Accessibility Tests

Accessibility testing is a form of automated and manual testing that helps us identify some of the potential accessibility concerns on DEV.

Many a11y issues are not obvious to everyone who contributes to the DEV project, therefore leaning on tools to help us identify these issues is a good practice.

It's a good idea to use browser plugins while you're developing to keep an eye out for these issues, as well as including automated tests to catch regressions in future changes.

The aXe devtools extension is a great place to get started. It works in both Firefox and Chrome. Use an extension like this one to find potential a11y issues in your workflow.

Automated testing in Preact

An overarching a11y testing strategy isn't currently in place for the DEV application, but there are some automated tools you can take advantage of in this project.

It is important to note that automated accessibility testing is only effective at finding ~30% of accessibility issues. It's important to do manual a11y testing as well.

When you're writing Preact components, you can include some basic a11y testing in your unit tests with jest-axe.

If you're still curious there are some great talks on accessibility for developers.