E-mail List Archives

Search E-mail List Archives for

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

From: wolfgang.berndorfer@zweiterblick.at
Date: Wed, Oct 25 2023 8:40AM
Subject: SC 1.3.5 and input type=date
No previous message | Next message →

In my tests, Chrome and Firefox save input data according to 1.3.5. But
e.g., they don't present the saved birthday (bday), when the input-field has
the attribute type=*date*.

Is it a failure of SC 1.3.5 to use typeÚte?



There were similar examples in a discussion on:

https://github.com/w3c/wcag/issues/1652

From: glen walker
Date: Thu, Oct 26 2023 11:53AM
Subject: Re: SC 1.3.5 and input type=date
← Previous message | Next message →

> Is it a failure of SC 1.3.5 to use typeÚte?

I don't think typeÚte is granular enough to understand the "purpose" of
the input field. There's no way to know what the date is for. If I'm on an
airline site, I might be specifying dates for flights, and when I book the
flight, then I might need to specify my birthdate. All those fields could
have typeÚte but the purpose of each field would not be known unless you
have autocomplete½ay.

Whether the browser saves or presents the saved value is outside the scope
of WCAG.

From: Dean.Vasile@outlook.com
Date: Thu, Oct 26 2023 12:37PM
Subject: Re: SC 1.3.5 and input type=date
← Previous message | Next message →

That sounds to me just like a button that is labeled, button or play or submit or next
It does not indicate what those buttons are indicating. what am i submitting
I definitely think the date field should indicate as to what the date is for.
Dean Vasile


617-799-1162

> On Oct 26, 2023, at 1:53 PM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
> 
>>
>> Is it a failure of SC 1.3.5 to use typeÚte?
>
> I don't think typeÚte is granular enough to understand the "purpose" of
> the input field. There's no way to know what the date is for. If I'm on an
> airline site, I might be specifying dates for flights, and when I book the
> flight, then I might need to specify my birthdate. All those fields could
> have typeÚte but the purpose of each field would not be known unless you
> have autocomplete½ay.
>
> Whether the browser saves or presents the saved value is outside the scope
> of WCAG.
> > > >

From: wolfgang.berndorfer@zweiterblick.at
Date: Mon, Oct 30 2023 11:51AM
Subject: Re: SC 1.3.5 and input type=date
← Previous message | Next message →

May be, I haven't yet understood the permissible bending of success criteria in the WCAG in view of inadequate browser support. Can anybody reference relevant passages?

> Whether the browser saves or presents the saved value is outside the scope of WCAG.

Does this mean that using typeÚte for birthday (bday) is no failure although the birthday is not presented effectively?

A value for *bday* is “programmatically determined” according to 1.3.5. Browsers could implement the data even in an input with typeÚte by sharing the yyyy-mm-dd to input sections for yyyy, mm and dd.

What if a common browser does not separate and support "identifying the expected meaning for form input data" with typeÚte for a birthday?

Have I missed information or is this a gray area?

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Thursday, October 26, 2023 7:53 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] SC 1.3.5 and input typeÚte

> Is it a failure of SC 1.3.5 to use typeÚte?

I don't think typeÚte is granular enough to understand the "purpose" of the input field. There's no way to know what the date is for. If I'm on an airline site, I might be specifying dates for flights, and when I book the flight, then I might need to specify my birthdate. All those fields could have typeÚte but the purpose of each field would not be known unless you have autocomplete½ay.

Whether the browser saves or presents the saved value is outside the scope of WCAG.

From: Patrick H. Lauke
Date: Tue, Oct 31 2023 4:55AM
Subject: Re: SC 1.3.5 and input type=date
← Previous message | No next message

Taking a step back...

<input type="date">

on its own just programmatically identifies this input as being *some
kind of date*. It doesn't say, programmatically, *what* date this may
be. It could be today's date, your birthdate, the date when you want a
contract to start or end, etc.

1.3.5 wants you to be more specific: if the input is indeed your
birthdate, then it needs to programmatically indicate this purpose
somehow. You need to add something extra there, based on a solid and
widely distributed ontology (and this aspect is where 1.3.5 handwaves
things a lot) that tools (such as screen readers) can then use to
understand the explicit purpose of the input. For all intents and
purposes, in HTML, the autocomplete attribute is the only (?) way to add
this extra information (unless there's some reasonably solid RDFa
attribute tuple? I've never looked into this...)

So, you want to have

<input type="date" autocomplete="bday">

Now, for 1.3.5, it's the autocomplete part that matters. The type="date"
bit is, in effect, irrelevant here. The following would be just as valid
for 1.3.5

<input type="text" autocomplete="bday">

Lastly, whether or not the browser autofills a field correctly, with or
without the autocomplete attribute, is also irrelevant. The point of
1.3.5 isn't "does the browser manage to autofill correctly", but "is
there an explicit indication of the purpose of the field".

Browsers do often use heuristics to autofill fields. Can't rely on
heuristics for a pass/fail determination in WCAG.

P
--
Patrick H. Lauke

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