Investigate what tools are available that can help us flag accessibility issues that may be present in a component that is being implemented for PatternFly 4. Provide any information that would be helpful in deciding between tools, if there is more than one tool that would work.
After researching several a11y testing/auditing frameworks we've settled on aXe: The Accessibility Engine
There is a wide range of tooling available that runs on top of axe-core, which contains a common set of rules and standards that we at Patternfly would like to abide by. With aXe, we can move forward independently on design and development fronts with confidence that we're testing and validating against a same set of rules, and because of this alignment we'll gain momentum in our efforts as a team.
So, we know "aXe" but we haven't yet decided the end to end solution in terms of implementation for pf-react. Progress is first being made in patternfly-next (core) with https://github.com/patternfly/patternfly-next/issues/466 and then following up with the last major piece of the puzzle, which is turning audit results into formal reporting format so they are available to a wider audience than just UI developers. This work is captured in https://github.com/patternfly/patternfly-next/issues/522
There are various methods with which we can implement aXe in patternfly-react. We may prefer an approach where we don鈥檛 use axe-react at all (even though it works well) and instead utilize custom node scripts to access the axe-core api directly, or use axe-webdriver like we鈥檝e done for the POC in pf-next. Either way, it would be good to hold off on jumping to implementation here, and wait to see what the end to end solution looks like in patternfly-next so we can ensure the solution here is in alignment with that. This will also make the job much quicker, as we'll have a full solution template to draw from.
Here are some links that better illustrate our array of options that we're wading through:
Thanks @seanforyou23! I'll close this issue and we'll continue to follow along in the issues that you have identified.
Most helpful comment
After researching several a11y testing/auditing frameworks we've settled on aXe: The Accessibility Engine
About aXe Core
There is a wide range of tooling available that runs on top of axe-core, which contains a common set of rules and standards that we at Patternfly would like to abide by. With aXe, we can move forward independently on design and development fronts with confidence that we're testing and validating against a same set of rules, and because of this alignment we'll gain momentum in our efforts as a team.
So, we know "aXe" but we haven't yet decided the end to end solution in terms of implementation for pf-react. Progress is first being made in patternfly-next (core) with https://github.com/patternfly/patternfly-next/issues/466 and then following up with the last major piece of the puzzle, which is turning audit results into formal reporting format so they are available to a wider audience than just UI developers. This work is captured in https://github.com/patternfly/patternfly-next/issues/522
There are various methods with which we can implement aXe in patternfly-react. We may prefer an approach where we don鈥檛 use
axe-reactat all (even though it works well) and instead utilize custom node scripts to access the axe-core api directly, or use axe-webdriver like we鈥檝e done for the POC in pf-next. Either way, it would be good to hold off on jumping to implementation here, and wait to see what the end to end solution looks like in patternfly-next so we can ensure the solution here is in alignment with that. This will also make the job much quicker, as we'll have a full solution template to draw from.Here are some links that better illustrate our array of options that we're wading through:
https://www.deque.com/axe/integrations/