Accessibility Issues and WCAG Compliance in Klai Forms

Support
1

dansmith65:
I’ve been creating an Accessibility Conformance Report via https://acreditor.section508.gov/ online editor and various accessibility reporting/testing tools. I’m finding that some common elements generated by Klai fail some high-priority accessibility items. To start with, I’m wondering if anyone else has worked on this before in relation to Klai or if accessibility improvements have been discussed internally or are on a roadmap?

Delfs:
We had a FL on Accessibility.
Let us know what specifically you had issues with

dansmith65:
The worst issue so far had to do with 3.3.1 Error Identification. The default validation and display of errors is invisible to NVDA screen reader.

The vueMultiSelect element is similarly unusable by screen readers.

dansmith65:
Do you happen to have a recording of that FL? I searched YouTube but couldn’t find it.

Delfs:
if you pass the feedback we can updat anything missing, may be as simple as adding attributes too.

Here are the best Friday Live matches I found for accessibility:
• Learn Figma for FileMaker Developers — Friday Live registration/recording link — includes Accessibility and Color Contrast in Figma.
• Friday Live registration/recording link — the Jake Johnson / Angel City Data session includes UX Corner: Device Diversity & Accessibility.
• Friday Live registration/recording link — the Tailwind 3 session includes Dark Mode, Accessibility, and Design Systems.
I only found that same official Friday Live link in the available results. If you want, I can next dig for the specific YouTube recording links/timestamps for those sessions.

notw wrong links but those shows I think

dansmith65:
These are the videos I found to match those descriptions:

https://youtu.be/fmAapoRo_G8?si=G53RHXJ0sILxYBK2
• There is some high-level talk about accessibility in general. This doesn’t go into the level of detail I’m looking for, though.

dansmith65:
I hadn’t meant to send that yet; I’m still finding the videos and searching the transcript for accessibility-related terms.

https://youtu.be/aSEFG2BT8g4?si=pp9IJaWBS5dquX9M
• This one only briefly mentioned accessibility, but also doesn’t go into detail.

dansmith65:
https://youtu.be/LA5sra2Fcv0?si=2JAAnh2Cc1ANLfdR&t=3250
In this video, you said:

I didn’t appreciate accessibility until i started going to a couple meetups and i was at this one in amsterdam where they had two present presenters and they showed a person who was blind using using a site and it’s like after that it’s like yeah we got to make things more accessible
This is the essence of what I’m referring to. In it’s current state, it would be impossible for a blind user relying on screen readers to use a form built in Klai that uses validation or the vueMultiSelect element.

While that video does mention accessibility and the importance of it; that’s about as far as it goes. My goal is to meet all of the Section 508 requirements, but it doesn’t sound like there have been any recorded videos of how to go about doing that.

I’m wondering if what I’ve said already about form validation, and these links to the Error Identification requirements is enough for you to understand the issues related to this item?

These sites offer a better understanding of how to comply with requirements:
• https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1&showtechniques=132%2C133%2C141%2C211%2C241%2C244%2C412%2C331&currentsidebar=%23col_overview#error-identification
◦ https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
• https://www.browserstack.com/docs/accessibility/references/accessibility-checklist

Delfs:
We definitely have more as Pearson has covered WCAG also
I also thing we have an example age that covers some things

2

I’ve finally gotten back to working on accessibility improvements. Here is some code I added to the DOM Header Insertions - Load later section to address a few issues:

document.documentElement.lang = "en";
document.querySelector('meta[name="viewport"]')?.setAttribute('content', 'width=device-width,initial-scale=1,user-scalable=yes');

I’m now trying to use some JS in onFailed_actions on the validate action to improve error identification. It’s looking like my options will be limited, though as some improvements would need to be done in Klai. For form input and textarea elements, here’s what I’ve been able to identify as needed improvements:

  1. on the error message container $('.errors.help-block') related to these elements:
    • add role="alert", so the error is announced when it’s added to the element
    • the error container must be present in the DOM before the error message is injected into it, rather than the container itself being dynamically inserted, otherwise the announcement may not fire reliably in all screen readers.
    • add an id that can be referenced by the aria-describedby attribute mentioned below
  2. on the input and textarea elements, when an error occurs:
    • add an aria-describedby attribute that references the error container
    • add an aria-invalid="true" attribute

This is the code I used when attempting to fix these issues myself:

document.querySelectorAll('.form-group.error.field-input, .form-group.error.field-textArea').forEach(group => {
    const input = group.querySelector('input, textarea');
    const errors = group.querySelector('.errors');

    errors.setAttribute('role', 'alert');
    errors.id = input.id + '-error';
    input.setAttribute('aria-describedby', errors.id);
    input.setAttribute('aria-invalid', 'true');
});

The problems this presents are:

  1. The aria-invalid attribute isn’t removed when the field is modified or when validation is run again, so screen readers keep saying the field is invalid when it’s not (and when the visible error message is gone).
  2. The error isn’t announced to screen readers.
3

Is there any chance you could update to the latest version of Vue-multiselect? The current implementation has many accessibility issues, many of which could be improved with an update. I’m still not sure if that would make this element WCAG Level A and AA compliant, though.

4

FYI: I’m still working through various issues and plan to keep adding to this thread as I clearly identify them and determine if I can implement a fix on my own or not.

On that note, I’ve identified an issue with showCardModal. When one is opened, you can still tab through content on the window behind the modal when this shouldn’t be possible; the modal should be a focus trap. I was able to solve this on my own, although it would be preferable if Klai did this same thing internally:

  1. Add a function to the showCardModal action that does:
    window.previousActiveElement = ( document.activeElement || document.body );
document.querySelector('#bfapp').inert = true;
  2. Add an options.onClosed_actions array to the showCardModal action, with a function action that does:
    document.querySelector('#bfapp').inert = false;
if (window.previousActiveElement) {
    previousActiveElement.focus();
    previousActiveElement = null;
}
  3. On any card modal that does hideCardModal and path, the onClosed_actions doesn’t seem to run, so you have to add this JS code in that workflow:
    document.querySelector('#bfapp').inert = false;

This same issue affects the showModal action as well and I’ll look into solving that one on my own as well, but I’m not sure if it’ll be as easy. showModal will end up having additional accessibility issues to solve as well.

5

@dansmith65 I’d like to create a task to fix any issues, if you can forward any detailed findings to the team we can implement quickly