Success Criterion 1.3.5 - Input Purpose - Level AA

[JJdeGroot]

Discussions:

1 May 2024

[Source](https://www.w3.org/2024/05/01-matf-minutes.html#t05) ## 1.3.5 Input Purpose there is no way to set a custom size in Apple's Accessibility inspector. Also I think the inspector rules are closed source JOE: In HTML if a first name is registered, but no autocomplete doesn't work then it's a fail JJ: Should we just add guidance on attributes and how to validate if they are available Joe: keyboard types might be easier Joe: Will try research how he can find out how to find autofill attributes Joe: Where can testers put this dummy data JJ: will look into MarkDown as a format for the success criteria Joe: Do we know anyone who has experience writing tests iOS can set autofill for Safari from any contact. Wondering if that setting propagates throughout apps. Quintin: has experience writing automated accessibility tests JJ: also has experience writing these; with source code access you can certainly extract input type related properties. Without source code access it's harder, believes it's possible on Android but probably not on iOS.

1. Accessibility Inspector and Custom Attributes:

• Joe_Humbert: Noted limitations in Apple's Accessibility Inspector for setting custom attributes and suggested that inspector rules might be closed source.
• Joe: Highlighted the importance of autocomplete functionality in HTML forms for successful validation.

2. Guidance on Attributes:

• JJ: Proposed adding guidance on utilizing attributes and validating their availability, particularly in HTML forms.
• Joe: Mentioned that researching keyboard types might be a more straightforward task.

3. Autofill Attributes:

• Joe: Shared intentions to research methods for identifying autofill attributes and their availability.
• JJ: Raised questions regarding where testers can input dummy data for testing purposes.

4. Experience with Writing Tests:

• Quintin: Offered experience in writing automated accessibility tests.
• JJ: Shared personal experience in writing tests, noting the challenges of accessing input type-related properties without source code access.

5. iOS Autofill Functionality:

• julianmka: Raised a question regarding the propagation of autofill settings from Safari to other apps on iOS devices.

[audreymaniez]

It seems difficult to test this criterion other than through user testing based.

For example, on iOS, it is possible to fill in a form with the owner's personal data in the native contact application. In applications that correctly identify the fields (name/phone/email etc.), automatic filling in is possible. So, when testing applications, if auto-filling is possible (and correct) on the basis of data recorded in the contact application, we should be able to deduce that the SC is compliant.

In the case of login screens, you must have already entered the information once and accepted the registration. And when you log in again, if the platform proposes the previously entered pair, then you can also deduce that the SC is compliant for this component.

A video about autofill on iOS (username/password): https://developer.apple.com/videos/play/wwdc2020/10115/

We should also consider the limitations of platforms: do they offer attributes for all types of personal data? if no, the SC cannot be applied to data that the platform cannot identify.

So I think it would be rather interesting/practical to write a criterion that integrates the use of autofill tools provided by the platform.

[jha11y]

I have done some limited testing on Android and the results so far have been interesting.

I added the android:autofillHints attribute to a text field on my test app and first turned on auto fill hints from my test google account that has account information (Fist name, Last name, phone number, email)

I noticed that some of the accepted values for android:autofillHints from the link above would come as suggestions when adding the code to the input field in the xml file and other valid options would not. Some valid options threw an error so I might need to update my app code.

When testing the auto fill using the google account information, my name was given as a suggestion when looking for first, last, and full name when using the accompanying attributes. Email worked as well offing multiple emails that were linked in my test account. I could not get auto fill for phone number to suggest a phone number.

I also tried switching to a different auto fill source. I added my 1 password account. This auto fill provider only seemed to work with my name. But I do know 1password auto fill does work for user names and password on some personal phone apps I use like my bank.

The one thing I noticed was that I added another "test" contact to my 1password account and test google account to see if a name field with appropriate autofill value would offer up multiple choices, but this did not work. So autofill could be limited for contact info (name, phone, address, email, etc.) to only the account owner's information. This also means that testing would be hard without user testing as mention by @audreymaniez in their comments about iOS.

All testing was done on my test Pixel 5a device running Android 14.

I plan to do more testing by seeing if changing the keyboardtype for a field in addition to auto fill provides better results. I might also try testing the same test app (possibly with more coded input fields on a Samsung device.