This is a short overview of the background and decisions that need to be made to map the maxlength HTML attribute and create an aria-maxlength ARIA attribute.
Although the HTML maxlength prop can be used to limit characters in native inputs, it has no accessibility mappings and is not communicated to screen reader users (either up front or when the character limit is reached).
This becomes a pain point when authoring text inputs that have character limits in several ways:
- It necessitates a custom live region announcement when the character limit is approaching and exceeded, despite there often being no visual text equivalent.
- Visual information about the limit is often present, but is not associated with the text input and not communicated in any way aside from cryptic text adjacent to the input.
- If authors attempt to associate character count & limit text (e.g. "35/100") with the input through something like a description, that can result in screen reader announcements for every character typed.
An accessibility API mapping would help remove the need for some or all of these authored solutions, and make the experience more consistent. The current PRs to introduce HTML AAM mappings for maxlength are here:
The current PRs introduce a mapping that would aid in announcing the character limit upfront as metadata associated with the text input. However, discussions about the desired behavior raised the question of whether there should also be API events related to the maxlength vs. current count. In order of least change to most change, those possibilities are:
- Only map object information/metadata about the maxlength
- fire an event when the current char count reaches the maxlength
- fire an event whenever there is input that would cause the char count to exceed the maxlength
- fire an event whenever the char count changes
While it's relatively simple to calculate the current character count in native inputs and textareas, contenteditable regions do not have a simple string value. We would need more input from browser vendors to determine whether calculating a character count for contenteditable regions is even possible, and if so how difficult it would be.
This would only affect aria-maxlength mappings, but assuming we want the mappings to be consistent with HTML maxlength, this could effectively make anything but the metadata approach impossible unless we find an alternative. One such alternative might be providing authors a way to define the current character count, either through an ARIA attribute or some other means.
When a screen reader user enters such a field they would want to know the current count (data may already be entered) and the max. They also want to know if they exceed the count as they type. However, there are time when they just want to know what the current count is without having to change focus out of the edit and back.
My current guidance on this (of course this would be up to the individual screen reader and their possible verbosity settings, etc.) is if the user pauses for more than 3 seconds of typing/cursor movement (while keeping focus in the edit), a screen reader can announce the current x/y. This would only happen once. If the user changes the count in any way and again pauses for 3 seconds the announcement would again come. In order for this to happen, the screen reader would need to be able to either query the current count or have an event fire on each change.
Another option is the screen reader can provide the user a command to read the x/y on demand. Either way, the screen reader needs to get access to the current count at any point. I don't believe it matters if this is done by querying some metadata or getting an event fired on each count change.
Certainly not proposing how the screen reader should expose the data, just want to make sure they have all the data they need at all times to provide the most flexibility.