Envoke differentiates between practical and certified accessibility when it comes to displaying forms, emails and other contact-facing content.
Certified accessibility means documented and certified WCAG 2.1 compliance by a third party certification authority, software or agency. Envoke doesn't have this.
Instead, Envoke's approach is to achieve "practical accessibility", which means that content intended for website visitors (forms) and email recipients (email messages) are accessible using screen readers.
This documentation includes technical specification about how accessibility is achieved for forms.
ARIA standards
Envoke adopts the ARIA standards as defined by the World Wide Web Consortium (W3C). As such priority is placed on using standard, semantic HTML for form fields, labels, and functionality. In all cases where semantic HTML is not possible, ARIA attributes are used to describe the purpose and function of form elements.
ARIA roles
Envoke embedded forms do not use the HTML <form> element in order to be compatible with websites and CMS software that use <form> tags at the top of the page hierarchy. (This is because a <form> element cannot be placed inside another <form> element).
For further reading see:
Semantic HTML form fields
Developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists. For instance, native elements have built-in keyboard accessibility, roles and states.
For further reading see:
Labels
Labels are encouraged but not required for Envoke forms. In order to optimize accessibility labels should be used for all fields.
Envoke form fields use standard HTML labels, either by the <label> for=”” attribute or nesting the related <input> inside the <label> element.
Required fields
In order to support embedding on pages with higher level <form> tags, we do not use the HTML required attribute on form fields. For this reason we specify aria-required="true" on all required input fields. On form submission, if a required field does not have a value the additional attributes for aria-invalid and aria-errormessage will be applied.
Checkbox groups
No semantic HTML method exists to specify that a value must be selected in a checkbox group, only for individual checkboxes. We add aria-required="true" (and later aria-invalid="true" if the form is in a validation state) to the parent <div> containing the checkboxes.
For further reading see:
Non-semantic HTML components
Envoke forms may use a multiselect dropdown component as a replacement for a checkbox group. This component is based on the React Select JS library and supports ARIA attributes. Field labels use the aria-labelledby attribute to associate with it.
The multiselect component is a convenience / style feature only and replicates the functionality of checkbox groups. It’s use is not required for Envoke forms.
Invalid fields
Envoke forms set the attribute aria-invalid="true" after the form is submitted, but required fields are missing or a provided value is invalid.
Following ARIA guidelines, when aria-invalid is used in conjunction with the aria-required attribute, aria-invalid is not set to true before the form submission (only in response to validation).
For further reading see:
Validation messages
Validation messages indicate if required fields are missing or if an entered value is invalid (most commonly an invalid email address). The validation message has the attribute id=”nvkValidationMessage” which is labelled by each invalid field using the aria-errormessage attribute.
For further reading see:
Custom text
Custom text components may be used to provide additional, longer-form information about adjacent form fields that would not be appropriate for form input labels.
These components use semantic HTML (for example <p> tags for paragraph content, <h> tags for headlines, <ul> for bulleted lists, etc.).
Dynamic form behaviour
Appropriate semantic HTML and ARIA attributes are supported by built-in dynamic behaviour in forms.
Form custom plugins
Javascript form plugins are custom code, and as such may produce behaviour that is not expected by accessibility devices or ARIA standards. The use of form plugins is completely optional and the impacts on accessibility should be evaluated case by case.
For further reading see:
Disabled elements
Envoke forms use the semantic HTML “disabled” attribute on all fields.
Hidden elements
Hidden form elements (for example used with dynamic behaviour) do not render. ARIA attributes such as aria-hidden=”” do not apply.
Buttons
Envoke forms use standard HTML <button> elements. The accessible label is the button’s text. For this reason it is encouraged to use clear text indicating the button’s purpose to submit the form (as opposed to an emoji or arrow icon, for example).
Further notes
First Rule of ARIA Use
If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
For further reading see:
ARIA labels vs semantic labels
By default, a button's accessible name is the content between the opening and closing <button> tags, an image's accessible name is the content of its alt attribute, and a form input's accessible name is the content of the associated <label> element.
For further reading see:
Title attributes
Envoke does not support title attributes on form fields for both accessibility concerns and responsive support for mobile devices. If additional information or context is required to help users with a form field, that text should be added to the label, or with a custom text component adjacent to the field.
Use of the title attribute is highly problematic for:
People using touch-only devices
People navigating with keyboards
People navigating with assistive technology such as screen readers or magnifiers
People experiencing fine motor control impairment
People with cognitive concerns
This is due to inconsistent browser support, compounded by the additional assistive technology parsing of the browser-rendered page.
For further reading see: