Squiz DXP

It's common for Components to require "shared" fields such as margin settings or a custom button field. $ref ( https://json-schema.org/understanding-json-schema/structuring#dollarref ) is a feature of json-schema, so it's not unreasonable for a Component developer to try using external schema references, but it's also not obvious that Component Service does not support them. It would be really helpful if it did.

collapsedByDefault does not work on child input groups, it only works if the input group is at the top level. This creates additional clutter for publishers and a less intuitive interface in components with many fields. There are also complications as conditional redering fields must sit with their parent.

You say that this is not the support channel, so I'm trying to log in where I can. Report an issue/suggestion/request?

Add a real-time character counter on DC.Description to help editors keep to character limit.

Allow adding code to the content pages in line with the functionality previously available via the standard pages. This could be in form of a dedicated code component or an assets picker - allowing to add code to the page

When a page changes status whether going from Under Construction to Live or Safe Edit to Live. Is it possible to have a “Notes” box to add on the Details tab to add notes like what was changed and have those notes visible on Version History? I know that this can be done when a workflow is added but not every page has a workflow and doesn’t require one and Version History doesn’t highlight what has change. This Notes feature would help us remember what was done to the page.

We have implemented multiple segments, and we want components to show if users are in multiple segments at once. Currently, the editor interface only allows selecting a single segment at a time, which means we can't preview components that require multiple segments.

The questions in decision tree assets are not programmatically connected to their set of radio button options. This means screen readers may only hear, "Yes" or "No" without knowing which question these are for. Would be great if the default html structure could be updated to ensure each question is programmatically connected to the set of options by wrapping the question and radio buttons inside a <fieldset> and changing the question <label> to a <legend>. https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/

By default, input fields in custom forms don't appear to have the autocomplete attribute included. While this can be manually added into the Extras field, this takes quite a bit of effort. Considering the necessary criteria: https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html It would be beneficial for input fields to have have the autocomplete attribute added by default https://www.w3.org/TR/WCAG21/#input-purposes

We are facing difficulties as we get more editors copying and pasting content from Word documents which include unclean, excess code. Other CMSes and even Dreamweaver had this fence at the top of the cliff, but Squiz Matrix is forcing us to use an ambulance at the bottom. Surely not best UX. Can we please get this feature added to the WYSIWYG?