Re: Proposing a Technique for 1.3.5 Identify Input Purpose

David and I accidentally continued the discussion off-list (assuming everyone else could see it, but then realising not!).

The trickiest bit (not thinking about internationalisation) was from a user-agent point of view: How do you differentiate these labels?


  *   Tel – match (tel)
  *   Telephone – sub-string (tel)
  *   Telegram – sub-string (tel)
  *   Tel area code - match
  *   Telephone area code – sub-strong (tel)
  *   Telephone area number - sub-string (tel)

If you match sub-strings then you can get false-positives (where it matches when it should not), but if you don’t allow for sub-strings then the names are not great. Unless someone finds a magic bullet for that, it seems to be a dead-end.

Thanks to David for exploring that, and signing up for the autocomplete technique!

-Alastair


From: John Foliot

+ 1 Mark, and this was also why using @title here was also rejected as a Technique on. ACCNAME has no requirement to be in English, and in fact I believe it should be localized to the document's declared language (as per SC 3.1.1) to be useful to the end user.

But thanks for the exploration work David, it was an interesting idea.

JF

On Sun, Jun 24, 2018, 6:04 PM Hakkinen, Mark T <mhakkinen@ets.org<mailto:mhakkinen@ets.org>> wrote:
David,

Should we be recommending a technique that is only valid for English?

It could work globally if it implies that cognitive AT would be parsing the AccName to determine purpose, and to make it work the AT would know the content language, and look in its own lexicon for a localized equivalent for the 5.2 autocomplete tokens.  I think that could get messy.

Also might we see content authors in non-English languages adding an English text fragment in non-English labels in an effort to comply?

Mark



________________________________
From: David MacDonald <david@can-adapt.com<mailto:david@can-adapt.com>>
Sent: Sunday, June 24, 2018 4:51 PM
To: WCAG
Subject: Proposing a Technique for 1.3.5 Identify Input Purpose


I've created a proposed technique for 1.3.5 which would allow the ACCNAME to contain a (case insensitive) string identical to the HTML 5.2 corresponding autocomplete token (or a string which contains the entire token within its string).

https://www.w3.org/WAI/GL/wiki/Accname-matches-autocomplete<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FGL%2Fwiki%2FAccname-matches-autocomplete&data=02%7C01%7Cmhakkinen%40ets.org%7Ca109512c62b542e98b2a08d5da144acd%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636654703052372293&sdata=SWLuz7gnmt4VbyqhXOOdUijzaPGyY4XNBaeNHXIfWvI%3D&reserved=0>

I took the idea from our new SC Label in Name (2.5.3), where the ACCNAME contains the string of the label.

https://www.w3.org/TR/WCAG21/#label-in-name<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F%23label-in-name&data=02%7C01%7Cmhakkinen%40ets.org%7Ca109512c62b542e98b2a08d5da144acd%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636654703052372293&sdata=OwHGXb4a%2B3vqk8HrLOtbT%2B7uep6zN03DXKVN8rS5wVs%3D&reserved=0>

This will provide some flexibility for authors who are creating simple contact forms in English, without compromising programmatic determination for assistive technologies, it provides another means to meet the SC,  for those with security concerns associated with autocomplete.

Cheers,
David MacDonald



CanAdaptSolutions Inc.
Mobile:  613.806.9005

LinkedIn
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7Cmhakkinen%40ets.org%7Ca109512c62b542e98b2a08d5da144acd%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636654703052372293&sdata=x1j1NF24zTm2055jMD7QB6L%2FOHIU8rB3TukLSetMHvk%3D&reserved=0>

twitter.com/davidmacd<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7Cmhakkinen%40ets.org%7Ca109512c62b542e98b2a08d5da144acd%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636654703052372293&sdata=2NzqA6WVZu5aMZu7J%2B%2FByQxgtBpCZO9UIPUnKh65yNA%3D&reserved=0>

GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7Cmhakkinen%40ets.org%7Ca109512c62b542e98b2a08d5da144acd%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C1%7C636654703052372293&sdata=1It0KX%2B48jMkFioguZ6EA7c6KlhUV0YVVIRYJOy%2FH6Q%3D&reserved=0>

www.Can-Adapt.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7Cmhakkinen%40ets.org%7Ca109512c62b542e98b2a08d5da144acd%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C1%7C636654703052372293&sdata=hQNmSvCUuekHhyBKpMgPzoRd%2FkY2u5979J3hzaCACu4%3D&reserved=0>



  Adapting the web toall users
            Including those with disabilities

If you are not the intended recipient, please review ourprivacy policy<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7Cmhakkinen%40ets.org%7Ca109512c62b542e98b2a08d5da144acd%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C1%7C636654703052372293&sdata=i3Nlvz%2B6fVEq10oABX6qs3e4I2L91a62tuWlGuAQN%2FQ%3D&reserved=0>

________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________