I have a form in which there are a few input fields. For one of the input field I have a length validation, for which I used maxlength="20".

The issue here is that the JAWS users don't come to know that the max length has been reached in the input field, as JAWS continues to keep on reading the key they press on their keyboard.

Is there a way to make this accessible?

  • 1
    Unless the makers of the software are actively participating on this website, I would imagine that it is a much better idea to contact them directly.
    – MonkeyZeus
    Commented Jun 4, 2014 at 12:20
  • Cross-post: stackoverflow.com/q/24036568/1591669
    – unor
    Commented Jun 4, 2014 at 16:14
  • 1
    There's really two questions here. One is "How do I make a feature accessible in markup/code" and the other is "how to I make JAWS work correctly because JAWS doesn't always support the accessibility standards". It's frustrating, for sure, that JAWS is popular, yet typically behind in fully supporting accessibility standards.
    – DA01
    Commented Jun 4, 2014 at 16:58

4 Answers 4


The easiest solution would be to indicate the limit in the label.

Your Field (20 character max)
[                                    ]

Not ideal in that JAWS may keep allowing input, but at least the user won't be surprised if it throws a validation error after the fact.


One way of helping the user would be adding the max-chars number in the aria-label.

Additionally, if you wanted to insert a 'You've reached the max number of chars' message you could use aria-live=polite to let the screen reader know that this field may be updated - in this case with an extra validation error.


Some options that come to mind for solving this problem would be:

  • Audio Signal: While it may not be ideal for sighted users (and I don't know right off hand if you can manage it to only work when the user is on a screenreader), you could add some audible signal when the user reaches the text limit. You would have to be very careful to not make this too obnoxious, but as screenreader-users get to know the system, they would have some idea that they had reached the end.
  • Appended Help Text: You could embed an element that would be triggered after the 20th character that would be a read only message along the lines of "Character limit has been reached."
  • Error Message: You could also trigger an error message that would get focus when you reach the limit. This is probably more disruptive than you would want, but is certainly an option.

One consideration for any of these solutions to keep in mind is whether you expect copy and paste to be used anywhere in your system. If you are going to introduce a standard way of handling character count, you may not want to just stop the user from inputting text without some indication of the fact that they are over (and, ideally, by how much). Instead, you could add messaging about how many characters the user is over to any errors or help text you provide.


Like the stackexchange comment input box!


[                           ]
556 characters left

Dark red:

[aaaaaaaaaaaaaaa            ]
116 characters left


too long by 60 characters

Too make it accessible in terms of accessibility standards, this, and the other similar solutions, have the drawback of adding too much noise, which could cause literally noise when used with a screen reader;
Take into account that a screen reader does not know your custom solution, so every change may be read aloud to the user at if there was a change in the page content.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.