illinois
Audit accessibility
We just had a talk at work about accessibility and the important of making sure websites are accessible. We should audit our website to make sure it's accessible and make any necessary improvements.
For continued support/easy pickup, automated can run as websites are generated or can be integrated into headless browser type tests (if you want to use node, phantomjs is cool, but I imagine you'd want to use firefox + chrome as they make up most of the marketshare). Things like aria, alt images, can be tested this way. This is super useful as people add features to keep up accessibility checks. Example npm library is https://axe-core.org/
The other tools is to have a dev mode where developers can flip on a panel to check for violations http://khan.github.io/tota11y/ . Some will naturally fall through to the cracks, like semantic links (i.e. click [here] for the queue versus [visit our queue]) unless you want to solve a huge nlp problem and get published 😄
(Also by law I think every website the Univ of Illinois operates has to be accessible for legal reasons )
@bhuvy2 thanks so much for the advice! Sounds like you know a fair bit about this, want to take a stab at adding accessibility checks to our CI pipeline?
@nwalters512 So after looking at this for a bit, I don't believe that just adding Accessibility tools that I mentioned will produce "meaningful" results. Meaning that we get the basics (i.e. we may get an Image isn't tagged with alt) but most of the output is too verbose or too strict to be useful.
Could I file a series of issues instead about Accessibility in lieu?
Of course! A series of narrowly-scoped and actionable issues about accessibility would be a huge help.
@nwalters512 I opened #244 #245 #246 #247 and #248 that detail some accessibility concerns.
The other addendum I'll make is that since this a new project, I advocate for using w3's guidelines on accessibility with section docs though there are older standards that work with screen readers.
Not every section needs to be labeled, but it does help. Browsers do a job of guessing what each part does based on the text, which is why Firefox's guide on accessibility isn't as constrained as w3's.
Ultimately the decision is up to how you want to tackle the issue as a design decision for the entire site.
Apart from that, it looks good on the usual checklist