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:
(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.
(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.