1

QA flagged an issue for phone number inputs, and I would like a second opinion on their interpretation of WCAG requirements, because I believe they are raising a false negative.

Below are the variations on the input phone number inputs:

enter image description here

(Alt: three rows of phone number input fields)

Our clients are international travellers, so we require the country code, but for the other fields, we are very lenient; we do not force them to format the phone number in any way.

We use inline validation for length and required field, meaning that if the user focuses on the field, types nothing and then focuses elsewhere, an error message would be presented, the field would be using aria-describedby for the error message, and we'd show the text and identify the erroneous fields.

enter image description here

(Alt: phone number input fields with an error for the country code and the phone number input)

Additionally, the error messages are contextual to what is actually wrong, not simply a generic error for all causes. (Note that those shown in the screenshot above are mine, for illustration purposes, they are not the final copy.)

The QA analysis requires that we inform ahead of user interaction, for every field, the details of the accepted format.

My argument is that this is superfluous, the fields have a label, we are not strict in the accepted input (e.g. we do not force spaces, dashes, parentheses), and we are not even forcing a the phone number entered to match the structure of the country code chosen.

The QA people are quoting this: https://www.w3.org/WAI/WCAG21/Techniques/failures/F82.html

The "Example 1" given on that page is seemingly forcing the users to enter phone numbers in a structured format, which we are not. My argument is that helper texts given before a user enters values is useful when a system forces the user to enter data in a specific format, which is actually a sign of bad user experience.

The QA people declare our input fields are failing #2, "For each set of phone number fields in the Web page that represent a single phone number, instructions are provided about how to fill in the fields."

Each field is labeled, doesn't that count as "instructions"? Are we correct in declaring that our field is accessible?

If not, I believe that even examples given by WebAIM would be perceived as not accessible, as I have not seen fields describing every possible acceptable combination before users interact with it.

Improve this question

2 Answers 2

Reset to default
2

You mention that 'we are not strict in the accepted input', yet you do perform some validation. I believe the guidelines encourage that users form a clear upfront expectation of what the system will accept. Your interface currently does not indicate where the input may go wrong, before interaction occurs.

Looking at the WCAG criterion quoted by the QA team, the design doesn't pass the second step in the procedure listed. However, the criterion specifically mentions that both checks must fail for the success criterion to fail. This doesn't seem to be the case for you.

Still, I believe your design could be improved in a few ways:

  • Add an input hint that communicates the input restrictions.
  • Don't wait for a blur event to provide input feedback where you can. If a letter is disallowed, you can inform about this inline (during typing).
  • Update the feedback copy, as it currently tells your users that only digits are allowed, yet your own examples include formatting characters as well.

Lastly, have you considered using a drop down for the country code? This may reduce the overall input and validation complexity a bit. If you can pair it with an ip-to-geo lookup you may be able to provide a default in most cases, bypassing input altogether. Hope this helps.

Improve this answer
6
  • Thanks for your input, here are a few comments regarding your suggestions: Commented Oct 3, 2022 at 14:53
  • - Input hint: in other places in the app, we have tooltips, however they are placed after the inputs. Graphic designers have chosen to have the labels inside the input fields, and adding the tooltip icon inside caused interaction issues. While sighted users would indeed associate the tooltip with the input, I feel this would not resolve the accessibility issue. Unless aria-describedby is used? Genuinely asking. Commented Oct 3, 2022 at 14:54
  • - Feedback as user types: this has been ruled out quite early in the design, as error messages that appear before users completed their interaction is a bad user experience. However, if the field was once set in error, then yes errors are presented/removed as users update the field. Commented Oct 3, 2022 at 14:54
  • - Update error messages: what I showed was placeholder text. If users enter 1 character, and the accepted minimum is 2, then the error message would be "Ensure to enter a minimum of 2 numbers", for example. Commented Oct 3, 2022 at 14:54
  • - Country code list: this feature was shot down by executives. Developers and designers were both in favour of it, however it was believed to take more time to develop than it actually would. Commented Oct 3, 2022 at 14:55
0

I think there is very little validation one can actually correctly do with a phone number, which sort of solves your problem. I am basing the following points on this article, which is not an official standard but stands correct nonetheless as far as I am aware.

Phone numbers are basically unvalidatable:

  • Telephone numbers can indeed have non-digits in them, the reason being two-fold:
    • some countries use native letters for phone numbers
    • it is indeed entirely ok in most countries to have arbitrary, normal letters and whole words in your phone number
  • Maximum length (15 digits is often cited) holds true for most but not all phone numbers
  • I think that point is not contested, but phone numbers obviously follow no predictable pattern of spaces, blocks of numbers or dashes or anything really.

Solution:

So I would do away with any kind of validation for your phone number field, which is a double whammy: You don't accidentally exclude people with weird numbers and you can just put a label there saying enter your phone number in the way you usually write it (or something like that, depending on the appropriate tone).

If you nonetheless have some validation for the number, it is only fair to the user to inform them beforehand of what input requirement you do have, like @ro-achterberg is saying.

Good luck with your QA team and as someone with a non-US number, thank you for caring about this!

Improve this answer
2
  • Re: the input being 'unvalidatable', since the country code is known, the national numbering plan is also. If you're willing to do the work to implement each country's specific syntaxes, in my opinion validation is pretty easily done. As for vanity numbers, I don't see these being used by the general public (intl travelers) very much, and in edge cases these can be easily decoded by the user themselves. Commented Oct 2, 2022 at 7:28
  • When designing the inputs, we tried to balance the suggestions the article you shared mentioned, and the actual business case (80%+ were North American travelers). I like the suggestion label you mentioned, it might be useful. As for removing validation, tech architects refused this a while back, it's a no go. Commented Oct 3, 2022 at 14:57

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.