search

cloud-gov / pages-core

cloud.gov Pages is a publishing platform for modern 21st Century IDEA websites.
https://cloud.gov/pages
Other
276 stars 68 forks source link

Add automated accessibility testing to builds #1062

Closed maya closed 5 years ago

maya commented 7 years ago

The Accessibility Guild is thinking about ways to automate automated accessibility testing: we think adding it to Federalist builds would be a great place to do this.

Would it be possible to integrate automated accessibility testing via CircleCI to federalist templates? We'd want to integrate a tool like this: https://github.com/accesslint/accesslint-ci I could imagine a checkbox in your site settings that adds this in if selected.

@jmhooper mentioned some ideas around adding it to the build container and creating a jekyll plugin that looks at the site after it is build, and raises an error if the linter fails.

Also, he mentioned that Shawn Allen did some work with Federalist / Circle integration before leaving. College scorecard has a system like that setup.

wslack commented 7 years ago

I think this would be great and I think Federalist can't prioritize it right now out of our very limited staff; right now our role does not include supporting content audits of our hosted sites. I am wondering if there are other venues (internal project, incubator funds) to pursue this. If the project takes less that 5 hours of work, might be different.

maya commented 7 years ago

@wslack glad you think it's a good idea! Could you clarify what you mean by "our role does not include supporting content audits of our hosted sites" and how it relates to this issue? The accessibility audit does not check content but HTML accessibility.

Agree that maybe a different venue may be better to do this if it is a bigger lift. @jmhooper do you have a rough estimate of how many hours you think it would take?

wslack commented 7 years ago

Right now, the Federalist product does not audit the content or code of sites it supports (basically, we don't care what's in a Github repo for a customer site). Doing this expands the scope of what we're looking at.

That's not bad (or a reason against); I am just pointing out that we don't do stuff like this at the moment. The reason I can't prioritize it is because of the other stuff on our plate.

wslack commented 7 years ago

We're interested on working on this in September, jointly with the Accessibility Guild.

maya commented 7 years ago

Great to hear it's being picked up. Of interest, AccessLint just deprecated the rubygem accesslint-ci and switched to a GitHub app. Might be harder for us to use the GitHub app re: IT Standards review.

http://mailchi.mp/143560247fa7/the-future-of-accesslint

carodew commented 7 years ago

@wslack – I believe @nickbristow is out this week (and not sure when he's back) but I'd recommend working with him, @maya and/or @toolness – they know more about this than I do, although I don't know what their availability is.

For myself, I'd like to step aside and get out of the way of people who know a lot more about automated tools than I do. :)

jseppi commented 6 years ago

This hasn't moved in a long time. Moving down to Icebox.

mgifford commented 3 years ago

I realize this is a closed issue, but it looks like it was closed out of lack of momentum more than anything. Someone in the Accessibility Guild might re-open it or spawn up a new issue. I figured I would reference how we have done this with GitHub Pages which also runs a similar architecture from what I understand:

https://accessibility.civicactions.com/posts/automated-accessibility-testing-leveraging-github-actions-and-pa11y-ci-with-axe