MaestroPreviously known as Transact Maestro. | Form BuilderPlatform Developer | 19.11 This feature was updated in 19.11.
Accessibility can be considered the degree to which electronic services and products can be accessed by the largest number of users possible. Although, often focused on disabled people using assistive technologies including screen-readers, this is relevant to all people, including those that are on slow broadband, using non-mainstream operating systems, using a mobile device or speaking non-native languages.
Since 1999, the primary international standard for website accessibility has been the Web Content Accessibility Guidelines (WCAG) developed by the W3C. This has formed the basis for accessibility legislation around the world, including:
Journey Maestro provides as much of the basic, component-level accessibility as possible automatically. For instance, linking a component’s label text with its input field. The additional tasks that a Maestro form developer must perform to achieve maximum accessibility are listed below:
Let's check each task in details.
Select Form Options > Policies > Wizard Validation Mode to configure it.
This policy property defines how validation and navigation operates for the form as a whole. Sequential page navigation is better for accessibility as it provides a simpler experience where users navigate through the form sequentially, one page at a time, and does not allow them to progress until the current page passes validation.
Unconstrained page navigation allows the user to navigate to any page, in any order which can be confusing (particularly on mobile devices) and does not perform full form validation until they attempt to submit from the final page. Having to then potentially correct issues across multiple pages can be a challenge.
Select Page > Properties > Display Text to configure it.
Select Section > Properties > Label to configure it.
Correctly marked-up headings are provided automatically by the page and section headers at levels 1, 2 and 3. Use page and section headers and do not manually create them with text display fields.
When creating lists, it is important to ensure that the correct HTML mark-up is used. When copying and pasting content from external sources (e.g. Word Documents) the mark-up is often lost and replaced by characters representing the numbers or bullets in the list. Whilst visually this may look OK, the lack of correct HTML mark-up will prevent screen readers from interpreting the list as a list.
Using the built in rich text editor you can add lists using the ordered or un-ordered list buttons shown below:
Select Text Display > Label to configure it.
Select Image > Properties > Image > Alternative Text to configure it.
Images can be informative or decorative. The form developer must use their judgement on whether an image should be treated as decorative or informative:
Decorative images do not convey information to the user and are typically used to make the form more visually attractive by adding visual components such as separators and textured backgrounds. An image is also considered decorative if it conveys information that is also fully provided by surrounding text. Decorative images should not have alternate text.
Informative images do convey information to the user that is not provided by surrounding text and should have alternate text that conveys the meaning or content of the image. The alternate text need not be a literal description of the image and should be as succinct as possible.
Select Component > Styles > Background to configure it.
Informative images should not be used as a background image as it is not possible to provide them with alternate text and some browsers remove background images when put in high contrast mode. It is fine to use decorative images as a background image.
See section . , for a definition of informative and decorative images.
Fields that are not stand-alone and only make sense in the context of a group of fields should be contained within a fieldset. For instance, when using:
A meaningful description of the group should be provided in the fieldset’s label (legend text) which is displayed on-screen as a heading:
Select Fieldset > Properties > Label to configure it.
The fieldset’s legend text will be used by assistive technologies to inform the user of the context for fields within the fieldset. For instance, tabbing to a checkbox button whilst a screen-reader is running might inform the user that they are currently focused on a checkbox button with caption “Email” for the fieldset “How would you like us to contact you?”:
Without the fieldset, the user would only be informed that they are focused on a checkbox button with caption “Email” which is clearly insufficient. To avoid repetition, the majority of assistive technology will only inform the user of the fieldset legend for the first field focused within the group, regardless of which field that is i.e. not necessarily the first field in the group by position.
It should be noted that when using the Radio Button Group component that there is no need to use a fieldset as this component includes one already.
Select Field > Properties > Layout > Label Placement Left to configure it.
Label placement above the field (Maestro default) is best for accessibility as it keeps the caption closest to its field. In particular, this makes it easier for users of magnifier software to locate the field associated with a label without having to move the cursor too far and reduces the chances of finding the wrong field by mistake.
Top placement also provides the best scan line between captions and inputs for fields. A scan line refers to eye movement along a straight line as a sighted user browses a form or searches for a specific field. Other label placement results in additional, unnecessary movement as the sighted user’s eye jumps around between labels and inputs that are less aligned.
Colours used in a form must meet accessibility requirements for contrast of foreground and background objects for partially sighted and colour-blind users.
You can check your form using a contrast tool such as the Colour Contrast Analyser from The Paciello Group: https://developer.paciellogroup.com/resources/contrastanalyser/
Select Field > Properties > Accessibility > Placeholder Text to configure it.
Placeholder text is the light grey text that is displayed in a field until data is entered at which point it is removed.
Placeholder text is not accessibility compliant due to the lack of consistent support in assistive technologies. Some assistive technologies ignore placeholder text entirely. Some always notify the user of the placeholder text regardless of whether there is data in the field or not and makes no differentiation between the placeholder text versus the entered data.
Only a small proportion of assistive technologies do the correct thing in only notifying the user of the placeholder text when it is visible on-screen.
Select Component > Properties > Label to configure it.
It can be tempting to hide the built-in field label and create a replacement with a separate text display component in order to achieve layouts such as a label that is wider than its field.
Although, this approach may look identical on-screen to sighted users, this does not provide the browser functionality where selecting a label sets focus to its field.
To resolve the specific case of long labels, it is better for accessibility to use a combination of shortening the label, widening the component and moving non-critical information from the label to a popover tooltip or a message box located close to the component.
Disabled form content is problematic for accessibility and should be avoided.
Typically, disabled content is visible on-screen for sighted users but not active and visually indicated as disabled with grey-out styling. Disabled content is not discoverable for users of assistive technology which results in a mismatch of information. For instance, in the case of disabling the continue button for a page until certain actions are performed a sighted user can see that the button is disabled and may be able to deduce that they need to perform an action before it will be enabled.
However, a user of assistive technologies will have no knowledge of the existence of the continue button at all which is likely to lead to confusion of what action is expected of them in order to progress.
In this case, it is better for all users to keep the continue button enabled and inform the user what is expected of them with error messaging if they attempt to progress without completing necessary actions.
The other common alternative approach to disabling components is to hide them.
Next, learn about rule templates and rule helpers in a form.