E-mail List Archives
Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
From: John Foliot
Date: Nov 2, 2018 12:30PM
- Next message: Patrick H. Lauke: "Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose""
- Previous message: John Foliot: "Re: ADA Website compliance"
- Next message in Thread: Patrick H. Lauke: "Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose""
- Previous message in Thread: Detlev Fischer: "Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose""
- View all messages in this Thread
Hi Detlev,
I'm fairly certain we had this discussion at TPAC, but here's my $0.02
worth.
> The Github login form (and other forms like it) https://github.com/login allows
users to supply either email or user name when logging in. This creates a
problem for using the autocomplete attribute to meet SC 1.3.5 "Identify
Input Purpose". Should the autocomplete attribute not be used here because
input is not restricted to either of these values, or are there still
advantages of specifying just email OR username via the autocomplete
attribute?
Having a dual-value input has some issues, however from the perspective of
SC 1.3.5, I think we discussed that the page author could chose either of
the values for the metadata attachment (i.e. you could use
autocomplete="email" or autocomplete="username" in this use-case), and I
would argue that the slightly better choice would be "username", simply
because the spec also notes the following for the token term:
*current-password* - The current password for the account identified by the
*username* field (e.g., when logging in)
(but either would suffice). Effectively, that page is offering you the
option of a "random-string text (your name)" for username, OR, you can
substitute your email address as the random text string for "username" - in
either case the system is simply recognizing a text string (using your
email address just makes it easier to remember your "username" - there is
nothing more magic about it than that)
The point of SC 1.3.5 is not that it autofills the input (that's a
benefit), but rather the input can be programmatically determined (which
using the attribute + a reserved token value accomplishes). I would also
argue that since the input on that page is collecting data about *the
user*, it would be in scope for this SC.
HTH
JF
On Fri, Nov 2, 2018 at 5:56 AM, Detlev Fischer < <EMAIL REMOVED> >
wrote:
> Hi,
>
> this recently came up in a discussion at W3C's TPAC meeting of the
> Accessibility Gudielines Working Group but John Foliot wasn't around then,
> so I take it here to look for reactions from the wider community.
>
> The Github login form (and other forms like it) https://github.com/login
> allows users to supply either email or user name when logging in. This
> creates a problem for using the autocomplete attribute to meet SC 1.3.5
> "Identify Input Purpose". Should the autocomplete attribute not be used
> here because input is not restricted to either of these values, or are
> there still advantages of specifying just email OR username via the
> autocomplete attribute? Would you pass or fail this login page (one could
> argue that 'password' is sufficiently identified programmatically by the
> type attribute)?
>
> I have also created a COMPARE case here: http://compare.accessiweb.org/
> index.php/Github_login,_username_or_email_(github.com)
>
> If you want to contribute there, let me know, and we set you up.
>
> Best,
>
> Detlev
>
> --
> Detlev Fischer
> Testkreis
> Werderstr. 34, 20144 Hamburg
> <https://maps.google.com/?q=Werderstr.+34,+20144+Hamburg&entry=gmail&source=g>
>
> Mobil +49 (0)157 57 57 57 45
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
>
> > > > >
--
*âJohn Foliot* | Principal Accessibility Strategist
Deque Systems - Accessibility for Good
deque.com
- Next message: Patrick H. Lauke: "Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose""
- Previous message: John Foliot: "Re: ADA Website compliance"
- Next message in Thread: Patrick H. Lauke: "Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose""
- Previous message in Thread: Detlev Fischer: "Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose""
- View all messages in this Thread