Ability to add custom design/styling to custom forms and request queues (i.e. font size, font weight, color, etc), also support WCAG 2.1 AA compliance

[#1]

Description:

I'd like the ability to have a little bit of control over the look and feel of custom forms, particularly how they are displayed when used as a request queue. Ideally we'd be able to adjust font size, font weight, color, bolding, etc.  Even if we could apply a default font-size for the form, and selectively bold some text, that would be a huge improvement. 

Additionally, a complaint I've received multiple times is that the font size for a question is smaller than the font size for an option within that question.  If we could change the font size we could fix this ourselves. Or, if it's easier, make the question font-size match that of the options below it.  Example:

Why is this feature important to you -
There are new rules that go into effect in April 2026 around accessibility of internal and external documents for Government agencies. All documents must be WCAG 2.1 AA complaint. Depending on your reading of the guidelines the current request queue forms may not be in compliance.  More information here:  https://www.ada.gov/resources/2024-03-08-web-rule/

How would you like the feature to work -
I can think of a few different ways to address this:

1.) Allow admins to set a default font size for request queue forms and be able to selectively bold descriptive text in forms.

2.) Give us complete control over the font size, color, etc, on a per-question basis.

3.) As a stopgap, increase the font-size of the question label to match that of the options below it, and ensure request queue forms meet all other WCAG 2.1 AA guidelines.  

Current Behaviour:
We have no control over the design of custom form/request queue design, and current request queue forms may not be WCAG 2.1 AA compliant.

[#2]

Having custom forms is a very powerful part of WF, and frankly one of the selling points the reps love to point out. MAKE THEM BETTER!! This is a fantastic idea and must move forward. This exact comment box shows that you have the technology to accomplish this request.

USE CASE:

We are using custom forms to collect marketing based information for our graphic design team. We want to use the custom forms to allow the requester to mock up more of what they want the marketing email or graphic will say or look like. Create bullet point lists to define paragraph points for copy writers, etc.

[#3]

Hi all,

It has been a while since our last communication on this, but wanted to provide you an update. We will be moving this to "planned" and will begin development soon! If you would like to discuss your use case further please feel free to respond again here and we will reach out to a few of you separately. Thanks!

Jeremy Flores,

Product Manager

[#4]

Agree with Greg Lindhout - it would be lovely if we could choose the text fields to only allow a certain amount of characters (or words).

Another part here I'd like to suggest is if helping text (light gray) could be entered into a text field, that would disappear once the form submitter clicks into the field.

[#5]

An easier way to create hierarchy and organize data within a form. Just like this comment box. I can format my comment if I needed to emphasize 1 point, or align things, making a list, etc.

[#6]

To build on this! Along with giving the rich text ability in custom forms we should have this on Project and Task descriptions. When creating a Project and Task there should be a more robust feature for creating the description. Wrike has this ability and it's amazing. A lot of times, a project's description reaches far beyond plain text and custom form fields. How most people at our company communicate is through email, and although email is a complete mess, what email is good at is allowing the person to format a message and description is multiple ways: through documents, screenshots, HTML text formatting (BOLD, underline, strikebreaking, bullet points, numbering, indenting, tables, charts, font colors, images, links, mockups etc). Most project and tasks have supporting information in the form of images and charts, and there isn't a way currently in WF to communicate this within the system. We now have to go outside the system and go back to emailing or using other project management tools. Workfront has a lot of amazing features, but I feel as though you have to think back to the basis of a project management tool - and this tool should focus on the easy communication of project and task creation.

This functionality could also be applied to requests (important for designers and copy writers to convey their messages and content) and documents as well, but not as important as projects and tasks.

And custom form fields should really be considered part of the projects description and be within that same area. Right now it's not very intuitive where to get necessary details about the project in order to do someone's job. The user needs to go to project details, look at the main overall timeline details then click custom form to get the actual full description of the project.

The creation of a task should be a bit simpler and less cluttered. Workfront has so many options and features, which is fantastic, but it can be completely overwhelming for users who are not necessarily tech savvy and just want to use the system for creating a task, description, dependencies, assignee, and due date. This information should be at the forefront of the design and the rest of the functionality can be shown differently.

[#7]

@Michelle, Andrea, and Natalie. Thank you for the additional detail.

[#8]

Glad to hear of this capability. I don't see a way to change current paragraph fields to the new text field with formatting. Is there a way to do that or do we need to recreate the forms we have (and delete fields/recreate them so we can use the same field names) in order to update to this new feature?

[#9]

Echoing Janelle's comment. This was the exact feedback I provided during my feedback session. Why is rich text formatting a new field? Why isn't it additional functionality applied to the pre-existing open text fields?

[#10]

Ditto. This is disappointing—like asking for a cheeseburger but getting a photo of a cheeseburger.

The request I voted for would allow admins to be able to format text on a custom form as a way to guide users — like the bolded required fields but more so.

[#11]

This is not what I needed. What I asked for is to be able to rich edit a "Descriptive text" field on a custom form... Information that *I* am putting on the form, not the end user.

And I agree with others that it's stupid to create this as a separate field type instead of updating the existing Paragraph Text field type. I am NOT going to go through every form I manage and recreate hundreds of fields as a new field type. #1 that is a waste of my time and #2 that would affect reports, views, etc that were pulling in other fields because the connection to the original field would break.

This is inadequate and disappointing.