E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Detlev Fischer
Date: Fri, Nov 02 2018 4:56AM
Subject: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
No previous message | Next message →

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

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

From: John Foliot
Date: Fri, Nov 02 2018 12:30PM
Subject: Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
← Previous message | Next message →

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 ADDRESS 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

From: Patrick H. Lauke
Date: Fri, Nov 02 2018 1:44PM
Subject: Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
← Previous message | Next message →

On 02/11/2018 18:30, John Foliot wrote:

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

What if the author decides that that's not the correct /
all-encompassing semantic meaning of that field, and decides not to add
any autocomplete? Do we fail? Seems a tad harsh, based on "you didn't
boil down this multi-purpose field to only one of the autocomplete values".

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: John Foliot
Date: Fri, Nov 02 2018 1:55PM
Subject: Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
← Previous message | Next message →

> What if the author decides that that's not the correct /
all-encompassing semantic meaning of that field, and decides not to add any
autocomplete? Do we fail?

Hey Patrick,

do as you would do <grin>. Obviously at this early stage, we have some
basic education required, so think of this as a teachable moment - fail or
not is your call, not mine.

Personally, I would fail it, and I would likely instruct our evaluators at
Deque to fail it as well. I think the input semantic is pretty
straightforward - it's looking for a username (and simply suggests/offers
you the opportunity to use an email address for that purpose - it doesn't
have to be *YOUR* email address, I think any formatted email address would
suffice) as one possible string of text that would = "username".

HTH

JF

On Fri, Nov 2, 2018 at 2:44 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 02/11/2018 18:30, John Foliot wrote:
>
> 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:
>>
>
> What if the author decides that that's not the correct / all-encompassing
> semantic meaning of that field, and decides not to add any autocomplete? Do
> we fail? Seems a tad harsh, based on "you didn't boil down this
> multi-purpose field to only one of the autocomplete values".
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
> > > > >



--
*​John Foliot* | Principal Accessibility Strategist
Deque Systems - Accessibility for Good
deque.com

From: Patrick H. Lauke
Date: Fri, Nov 02 2018 2:32PM
Subject: Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
← Previous message | Next message →

On 02/11/2018 19:55, John Foliot wrote:
>> What if the author decides that that's not the correct /
> all-encompassing semantic meaning of that field, and decides not to add any
> autocomplete? Do we fail?
>
> Hey Patrick,
>
> do as you would do <grin>. Obviously at this early stage, we have some
> basic education required, so think of this as a teachable moment - fail or
> not is your call, not mine.

Doesn't sound like something that is unambiguously testable though, does
it? ;)

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: John Foliot
Date: Fri, Nov 02 2018 4:41PM
Subject: Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
← Previous message | Next message →

Hmmm... neither is SC 1.1.1 in terms of 'value' of the alt text.

We can certainly test to see if the input has @autocomplete, while still
debating which token value is most appropriate, ya?

JF


On Fri, Nov 2, 2018, 3:33 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 02/11/2018 19:55, John Foliot wrote:
> >> What if the author decides that that's not the correct /
> > all-encompassing semantic meaning of that field, and decides not to add
> any
> > autocomplete? Do we fail?
> >
> > Hey Patrick,
> >
> > do as you would do <grin>. Obviously at this early stage, we have some
> > basic education required, so think of this as a teachable moment - fail
> or
> > not is your call, not mine.
>
> Doesn't sound like something that is unambiguously testable though, does
> it? ;)
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Mallory
Date: Mon, Nov 05 2018 10:21AM
Subject: Re: Dealing with ambiguous form fields when applying the new SC 1.3.5 Identify Input Purpose"
← Previous message | No next message

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 ADDRESS 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
> > > >