Statewide accessibility requirements

[cschweda]

Another issue to consider:

DoIT/CMS is mandating that all public-facing statewide websites meet current federal accessibility guidelines. I don't have a definitive word yet on the details of the mandate (i.e., if it's a legislative thing or a DoIT thing) -- but the a11y target appears to be current WCAG 2.1 guidelines.

The state is using an app called Siteimprove to check agency websites.

SiteImprove has a chrome extension that does a scan similar to their paid app. I'm using it as I develop and update the public sites.

It seems to identify quite a few (easily fixable) issues that Chrome's Lighthouse misses.

[kgruschow]

One of the best ways to test is have a person who uses some of the related assistive tech to test. We have one (possibly two?) people who use visual assistive technology at ICJIA who could be approached to assist in testing.

[cschweda]

Moved to medium priority -- this is definitely something that we need to zero on (eventually).

It's not high priority -- but DoIT is actively scanning agency public-facing projects for accessibility issues, and we (ICJIA) want to make sure DoIt's audit scores as high as possible. Moreover, web accessibility is a key part of ICJIA's recent Diversity, Equity, and Inclusion (DEI) initiative.

See the siteimprove checker I referenced earlier.

Vuetify the UI framework is (thankfully) pretty well kitted-out for most a11y issues -- but there are some lingering issues that are flagged with siteimprove that are (for the most part, in my experience) pretty straightforward fixes -- and not yet fixed in Vuetify.

Google Lighthouse is a good first check -- but doesn't catch everything (unfortunately).

If we need to talk more, please let me know.

[miserman]

28b003c addresses some of this, but it will be an ongoing process.

[cschweda]

Thanks!

Agreed -- it's ongoing.

I appreciate it. The main a11y issues that I've noticed with Vuetify is that it (a) misses aria-labels on some components and (b) includes blank labels in v-tables.

My approach -- FWIW -- is to let Vuetify render the page and then -- after the mounted hook -- I usually snag the incorrect or mislabeled DOM-elements and add (or delete) whatever needs fixing. These kinds of post-mount fixes (appear to) pass the accessibility checkers without issue.

I've been compiling a basic a11y "fix library" that I've been applying to various sites.

Examples:

• https://github.com/ICJIA/icjia-heals-2021/blob/master/a11y/index.js
• https://github.com/ICJIA/r3-next/blob/master/src/a11y/index.js

These aren't by any means comprehensive -- and they don't (yet, at least) fix 100% of the errors -- but based on the current status of Vuetify/Vue -- these seem to fix several of the critical issues raised by the siteimprove checker.

[cschweda]

BTW --

Here's the required accessibility script that DoIT recently asked agencies to add to public facing sites.

I'm just appending to this to every head section (via jsdelivr's CDN):

https://cdn.jsdelivr.net/gh/icjia/doit-accessibility/dist/index.js

I'm still in the dark about when (or even if) they'll be scanning sites -- but I wanted to get everything ready (and easy to adjust if DoIT changes the script).

[miserman]

57c5f2b adds this.

[miserman]

Siteimprove indicates a labeling issue with v-combobox elements and the listboxes in v-select elements, but I wasn't able to immediately see how to fix them -- their input parts are labeled, and adding labels to other parts doesn't seem to fix it.

[cschweda]

I'll take a look on Monday. Which component has an example of the issue?

EDIT: Here's Vuetify's page about a11y:

https://vuetifyjs.com/en/features/accessibility/

In the 'item slots' section they indicate an issue (with what sounds like a workaround by utilizing the props) for the combobox and v-select. Does this sound viable in your case?

[miserman]

src/components/Sheets/Export.vue has both, with the select one only showing up after it has been opened. But I'll play around with the template version.

[cschweda]

Thanks. I haven't checked out the error yet -- but is it possible to manually insert after the component has mounted?

I've been doing that with several Vuetify-specific issues. Grab the offending element(s) post-render and either insert the aria label or (in the case of Vuetify's datatable) replace empty <span> elements with text for the screen reader.

If it's something that can't be fixed or seems like it requires too much time -- please keep a list of the outstanding issues, and I'll cycle back at some point and submit a PR.

The other a11y thing to check -- and you might already be doing this -- is the 'tabability' of the page -- i.e., hitting tab to go from element to element on the page. That's one thing Siteimprove (or Lighthouse) doesn't (or can't) check.

[miserman]

I played around with manually inserting labels for the select one, though it has to be inserted on click since the listbox isn't attached until then. The issue was that none of the label strategies I tried (those suggested by Siteimprove; parent <label>, <label for>, and aria-labelledby) actually fixed the check, even though I could see what seemed to be an appropriate label in place.

Tabbing is currently a little weird since it goes into the data menu without opening it, and the ordering could probably be adjusted. I'm also planning on adjusting some of the structure labeling (like with aria landmarks) toward some of the best practices brought up by Siteimprove.

[cschweda]

I'm using this a checklist for manual checking:

https://webaim.org/techniques/keyboard/

I've had the tab/menu issues as well -- and my focus (for now, at least) has been on the automated checkers -- Siteimprove, Lighthouse, and WebAim's 'Wave' checker. Wave seems to identify issues that Siteimprove misses and vice-versa.

One approach -- especially with a dynamic interface like yours in the arrest-explorer -- might be to focus short-term on the critical errors in automatic checking -- and then, if and when necessary, cycle back for manual testing and fixes at a later date. I know the WCAG specs are in flux, as well -- so it's obviously an ongoing process.

I've talked with several folks here -- as well as a few folks from DoIT -- and this seems to be a viable, mostly agreeable approach. And since your time is limited -- this probably makes the most sense for now.

DoIT (AFAIK) still hasn't clarified -- or, at least, made public -- their own manual testing procedure. I'm assuming it's similar to the WebAim list above -- but it's hard to know for sure.

[miserman]

de9985f should fix all of the issues brought up by Siteimprove, as well as Lighthouse and WAVE so far.

The main labeling issue with the v-select and v-combobox elements was specific to their component with the listbox/combobox role, which didn't seem to be accessible using a template -- the things in a template go inside of this component.

src/plugins/select_labeler.js adds labels to those elements. It is initially called in an updated hook to add focus listeners to inputs with menus. Then the part triggered by a focus opens the menu and adds the label. It also sets their style.display to inherit, since Siteimprove flags them as missing labels when the menu is closed (the parent element has a style.display of none).

I've also been playing with a screen reader (NVDA) a bit, and tried to better accommodate it, but that brought up some other issues I wasn't able to immediately fix:

1. The selected option in v-select elements is not read, which is particularly confusing when using arrow keys to switch between options (when their menus are closed).
2. In Firefox, v-switches are not always accurately read as checked or not after being changed, and nothing is read on change, unlike in Chrome.
3. Elements with deletable chips are pretty annoying since you have to tab through all of the chips before getting to the input.

I think at least everything can be tabbed to, and everything can be figured out verbally (other than the v-switches issue initially).

[miserman]

From a little testing on an older Mac, Safari's audit (at least in version 13.1.2) flags some buttons as missing labels when they are in closed menus, similar to the Siteimprove issue with closed listboxes. It doesn't seem like a real issue, but might be something a checker flags.

That browser also does not appropriately read the state of v-switches, similar to Firefox.

d503516 removes the chips from the sort & filter menu's level select element, so that at least should be less annoying.