Happy Monday to you all! This post is an update on some fixes and enhancements we've made but it also serves as an explanation of how we approach accessibility (and bugs in general) at Kuali.

Noteworthy Fixes

Here are just a few of the recent noteworthy fixes and enhancements that we've recently rolled out in Build:

• Keyboard focus added/fixed on multiple navigational elements
• Error messages are now screen-reader compatible
• Some screen reader messaging (including some button labels) was unclear

We have new stuff we're fixing all the time and a couple of larger enhancements coming soon. 

Our Approach to Accessibility

If you weren't already aware, one of our software development policies is called Zero Bug. This means we try to keep our bug list to zero (or near zero) every week. We aren't always perfect at this but we do a pretty good job.

In terms of accessibility, we actually treat accessibility issues as bugs. Naturally, we try to address them before they become bugs—as part of our typical development process—but occasionally some sneak past us. When they do, we add them to our bug list and apply our Zero Bug policy liberally and with glee.

Report Them Bugs 🐜

So that's a little "inside baseball" for you today. Hopefully that gives you a clearer idea of how we Do Our Thing™ here at Kuali. 

As usual, we encourage you to report any accessibility (or other) bugs. We appreciate the feedback we get from our customers and thank you for helping us make our software better. Cheers! ✌️

We've recently updated the platform to limit access to users and groups for system administrators only. This update is being made to further our commitment to providing a secure and scalable platform.  In the future, system administrators will have full access to the users and groups module and can convert system users to system administrators in order to provide them access on a case-by-case basis.

If you have any questions about this release, feel free to comment here or email us at build@kuali.co.  Happy building!

Form and workflow designers now have increased flexibility in developing conditional visibility logic and custom workflow branching. 

Previously, designers could only manage advanced form and workflow logic of *Boolean data if the field type either was empty or was not empty. 

Now designers will be able to build advanced conditional logic and workflow branching conditions based upon whether Boolean data tokens added into a document via a Smart Gadget integration are either true or false.  

This new functionality will now enable designers to not just confirm if integrated Boolean fields have the presence of data (i.e. 'not empty') but will also confirm the true/false status of that data.

If you have any questions on this new improvement, don't hesitate to email us at build@kuali.co or comment here!

*Boolean field types are only available through Smart Gadget integrations and do not exist as independent gadgets in the form designer.

• Rich Text Fields
• Signature
• Image Fields (removed from subject lines)

We have recently made some changes to the Submitted By gadget due to issues being reported in Kuali Build and feedback submitted by customers. 

Some of these issues and feedback include the following. There were some instances where data contained in the gadget did not populate despite the document's metadata holding the correct value. Additionally, customers reported being confused when seeing submittedBy versus meta.submittedBy in notification variable lists and in other areas in the system.

Our hope is that these changes will reduce confusion and streamline the way metadata is used in Kuali Build applications.

We have changed the Submitted By gadget to use the value contained in the metadata. This change prevents issues with the gadget not being populated when data exists. A side effect of this change is that the gadget itself no longer has a data value, which impacts the following scenarios:    

• Conditional Visibility using the Submitted By gadget data will no longer have data to read. Customers will need to update any Conditional Visibility rules to use meta.submittedBy when referencing the submitter moving forward.
• Notifications using the Submitted By gadget data will no longer have data to read. Customers should update variables used in notifications to read off the meta.SubmittedBy data rather than the Submitted By gadget.
• PDFs generated shortly after the fix will have blank Submitted By fields. Moving forward PDFs will generate correctly. Any PDFs that have blank Submitted By fields should be regenerated.
• Anywhere where "Submitter" or "Creator" were listed to refer to the submitter will now read "Submitter - Display Name" in some areas of the system.

We have pushed out fixes for these problems, and with those fixes we have also migrated impacted data to ensure that the correct value shows up throughout customer forms. 

You can read more about these changes here. Please let us know if you have any questions regarding these recent updates.