WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"

for

From: Mallory
Date: Nov 5, 2018 10:21AM

I suppose one thing to push it more towards email is if, for separate coga reasons (TBI/memory issues) the client also wants the autocomplete's autofilling feature, I believe there was no support for "username" in browsers tested while pretty decent support for "email" according to that test/research page John made (which I'm aware is getting old and not definitive but it's nice). If the client wants the autofilling stuff as add'l coga-help then I would maybe recommend the "email" value, OR see if they know whether there are vastly more usernames than email addresses in their DBs (in which case, if almost nobody uses their email address then "username" makes the most sense).

cheers,
_mallory

On Fri, Nov 2, 2018, at 7:30 PM, John Foliot wrote:
> 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
> > > >