Closed lewisdorigo closed 1 week ago
This is an interesting oversight that brings a larger issue to light. We can say that exceeding the character limit makes a field invalid, but reducing that back to an allowed number of characters won't necessarily mean that the field is valid -- there could be other validation rules to consider.
A short term fix could be that — if the field has aria-invalid
set when the character count is initialised — it won’t be removed.
That would help resolve our issue in the short term while more robust, long-term solution is considered.
We'll be putting that fix out in the next release.
@lewisdorigo this should now be fixed in the latest release v2.3.2
Description of the issue
When the Character Count component initialises, if the length of a field value's length is less than the max length, it will remove the
ds_input--error
class from the field, and setaria-invalid
tofalse
.This causes issues when the field should display with an initial error, e.g. when form page submission triggers a full-page refresh to display server-side form validation errors.
When the Character Count is initialised, the initial
ds_input--error
class is removed, andaria-invalid
is set tofalse
.Steps to reproduce the issue
On an HTML page using the design system, add the following:
Expected behaviour
When the Character Count component initialises, the
ds_input--error
class remains, and thearia-invalid
attribute remains set totrue
.When updating the the field, if container has an error message, the class name and
aria-invalid
attribute should not be changed.Actual results
The
ds_input--error
class is removed, and thearia-invalid
attribute is changed tofalse
.Environment