Bring the site closer to WCAG 2.0 compliance

[eddierubeiz]

How I might tackle this:

• Solicit advice and comments from the accessibility committee and from the librarians at https://libwww.freelibrary.org/lbph/ .
• Pick an automated tool that flags WCAG violations (one I've worked with in the past is https://squizlabs.github.io/HTML_CodeSniffer/. Also worth looking at: https://github.com/IBMa/equal-access)
• Decide on things we can and can't change (for instance, we can't fix violations that would bring us in conflict with our sitewide branding.)
• Focus on the 80% percent of problems can typically be fixed in 20% of the time.
• Focus on pages that are heavily used by the public.
• Document what we changed, and show the numbers: blog post, report to the accessibility committee.
• Keep a list of items that were not fixed and why, so they can be tackled in a future iteration, should we choose to.

[jrochkind]

I am going to start by focusing on three pages:

1. Home page
2. Search results page
3. Item detail page

I am also going to start with the "HTML_CodeSniffer" tool listed above, and start with the things at level "AA" and notated as "Errors" (rather than "warnings" or "notices").

I am for now going to exclude admin pages/admin-only functionality.

[jrochkind]

OK, I've gone through all of the HTML_CodeSniffer => level AA => "error" (as opposed to warning/notice)

There are some outstanding things related to img alt text that I need to thinik/reserach/discuss with y'all more. We'll talk today.

In the meantime, I'm also moving on to: The IBM tool; level AAA; warnings and notices.

this is a much larger more confusing noisier list, including lots of things that are just like "this might be an issue you should check" and then I check and it's not (but no good way to eliminate it from the report), and lots of things that I don't totally understand what they mean.

But for things that I do understand what they mean and see a good way to address/improve them, I'll start doing a few of those too.

[jrochkind]

BTW, a lot of our text still doesn't meet contrast rules at AAA (rather than AA) level -- hyperlinks, but also some of our dark-grey muted text, and other text too. For now, I am ignoring those, it would require a major site redesign/brand color redesign.

As far as I know so far, all text does meet contrast rules at AA level.

[jrochkind]

For future reference:

Digital Library Accessibility and Usability Guidelines (DLAUG) to Support Blind and Visually Impaired Users https://sites.uwm.edu/guidelines/

[jrochkind]

The IBM checker is asking me to:

Inform the user when their input action will open a new window or otherwise change their context

Changes in context can confuse or disorient users who cannot easily perceive the change. If activating a link opens a new popup or a window, informing the user in advance helps people who use assistive technologies be aware of the change in context.

Referencing:

• https://www.ibm.com/able/requirements/requirements/#3_2_2
• Giving users advanced warning when opening a new window: https://www.w3.org/WAI/WCAG21/Techniques/general/G201

By Communciations policy, ALL external links use target="_blank". Adding "opens in new window" next to all of them is probably not a great option. Am definitely not doing at present.

But I wonder if this accessibility guideline really means the Institute should consider adjusting that practice, and no longer using target=_blank everywhere, if it's known to create an accessibility problem

[jrochkind]

Another good tool (FYI @eddierubeiz ) is Google Lighthouse: https://developers.google.com/web/tools/lighthouse

It runs as a Chrome plugin. While it does more than accessibility, you can run it with only the "accesibility" checkbox checked to only focus on that.

It's flagging things I think are legit that the HTML_CodeSniffer tool didn't find; and is for me somewhat easier to use than the IBM tool.

[jrochkind]

Also an interesting page that tries to show which features are supported by which assistive technology.

https://www.powermapper.com/tests/screen-readers/aria/

Sometimes there's an ARIA or other feature which seems like it should provide accessibiilty, but isn't actually supported by actually existing assistive technology.