Can you provide some type of tangible direction that they would like to go in order to bring the form up to whatever spec that is set by that department??
The forums might be able to better help if there are specifics.
Oh yes. I guess that would be helpful. I will update the post.
N M thank you for the suggestion. I'm not sure why I did not think to add the examples in the first place.
Are you using Responsive or Classic Forms?
While there might be *something* that can be done before the page is fully rendered (I am not entirely sure how things such as screen-readers wait for the page content, or if it's just utilizing something like the 'document.ready()' event), it's going to be more or less difficult depending on the form you're using.
That is, unless a Nintex Dev comes in here with an Out Of The Box Accessibility save.
---------
This is from a "Classic Form," and yes that would be great is a Nintex Dev would help us out. I'm sure I'm not the only one with this issue.
I'm in the same boat (although I'm primarily using responsive forms). We must meet WCAG 2.0 AA requirements and when we saw the initial demo for Nintex we were told it was fully accessible.
From what I can tell, the labels are separate from the input fields. When I test the form with JAWS it doesn't read the label and input form together so on most of the fields, if I tab between fields, it simply reads, "input field."
Seems it's not as accessible as we were initially sold on.
Patrick Abel do you have any suggestions on making classic forms accessible?
Euan Gamble - would you be able to comment pls?
So I grabbed WAVE and started looking at the forms...
I can see whatcha mean. Some of the problems looked like they can be solved by associated a Label Control to the Named Control via the options.
You can do this via the Control's own Settings page as shown:
Or via the top Properties Ribbon as shown:
However! For whatever reason, Nintex Forms doesn't seem to actually care about that association for *certain* controls. Attachments? No Association even if you use the Associated Control field!!!
Other finds
- Calculated Controls use a <label> element to display their values instead of something like a <span> (which can actually have any aria role on it making it far better (unless I'm missing something)). This creates a label that isn't associated with anything because it literally can't be...
- It should also be noted that if the Calculated Control returns 'nothing' like an empty string, it will cause problems because it looks like a label that is not only detached, but also contains no text.
- Some controls have hidden <input> / <select> fields that are visually hidden but do not contain the aria-hidden="true" attribute, and so they throw an error.
- Label Controls that are associated to a Named Control will still result in an error if they are located inside of a Repeating Section due to the nature of how New Rows of a Repeating Section are cloned but not cleaned up. Essentially, all of the labels will point back to the 'hidden' Row 0 version of their associated controls, and not the newly created controls on the first and subsequent rows.
- However for forms that are NOT new, and have had no New Rows added, they should be generated correctly.
I don't have time to go through all of the various things, but there might be a path to correcting a lot of this with some clever javascript fixes that run before the form is finished generating. But right now that's a bit of speculation as I'm not entirely certain how Aria standards / Accessibility Software works.
One place that I started to look is: HTML5 Accessibility Chops: hidden and aria-hidden | TPG – Digital Accessibility Solutions
seems that using a combo of the element tags "hidden aria-hidden="true"" and the css of {display:none}, should be enough to force an element to be ignored across a majority of browsers.
Using that knowledge in conjunction with the internal control id guids used across all forms (Form Control Property complex element), it seems like a solid series of css rules and js can be made to easily apply accessibility fixes.
I know it's not a complete answer, but it should at least get a few of gears moving in the right direction.
Hi Josh Henderson,
When Nintex Forms was built (Classic or Responsive), it was not built with accessibility in mind, therefor the forms does not adhere to accessibility standards. N M is correct, you could do some JavaScript manipulation to get some way there, but Nintex does not support the use of JavaScript.
We are rebuilding Responsive Forms (known as Universal Forms) and the conversation of accessibility has come up, but at the moment our focus is just ensuring customers can move from the existing Responsive Forms to Universal with the same functionality. Once we have shipped Universal Forms, we may take another look at accessibility.
Cheers,
Euan
N M this is fantastic information for me and others. I have found several of these same things, but it's very nice to hear/see someone else sees the same thing, and can spelled out more plainly than I could.
We were told that Nintex was completely accessible, but maybe they were strictly referring to the designers... However, I have not put the designers through JAWS or WAVE yet. So this maybe false too.
Either way I'm going to look into manipulating these forms with JS for now. But will need them to either step up their game in this area or we maybe forced to part ways. This is becoming a huge deal in higher education, and the business world. I love these tools, but to justify the price we have to be able to use them.
Euan Gamble, thank you for your response. Please keep us updated on this as I know I am not the only one in this pickle. I love your product (an advocate even), but accessibility has been huge for awhile and is getting more and more prevalent in our community. There are laws in place that require us to
I know I do not speak for myself when I ask to add accessibility to the priority list.
Agreed. Any governmental agency and most education organizations (k-12 and higher ed) will need their forms and online content to be fully accessible to maintain federal and state accessibility compliance.
In addition, I would think Nintex would want to make sure their content is accessible to those with disabilities of all kinds and not leave anyone in the dark.
Hi all,
Our UX team are doing some research into our style builder for Universal Forms. We would appreciate your feedback on your current experience in styling your forms in any platform.
If you would like to provide feedback, please fill out the survey at Applying styles in Nintex Forms.
Thanks,
Euan
The survey didn't have anything to do with making the forms accessible. Any news on that front?
Hi Jonathan Blundell,
Accessibility for Universal Forms is in the backlog but no movement or updates to share at this time.
Cheers,
Euan
@domyessay wrote:
Hi Jonathan Blundell,
Accessibility for Universal Forms is in the backlog but no movement or updates to share at this time.
Cheers,
Euan
We use this in Salesforce: building the templates and implementing updates has never been easier. My only concern is account security.
