E-mail List Archives

Search E-mail List Archives for

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

From: Steve Green
Date: Thu, May 23 2024 6:45AM
Subject: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
No previous message | Next message →

The size of the native HTML date picker <input type="date"> does not change when the zoom level is changed in Firefox, and I cannot find any way to change it.

The Understanding page for SC 1.4.4 refers to "text-based controls" without defining what this means. Failure technique F80 refers to text-based controls as including "input boxes (text and textarea) as well as buttons" but does not mention comboboxes and date pickers, so it's possible that 1.4.4 doesn't apply to the native HTML date picker even though it presumably would apply to an author-created one.

Unlike some other success criteria, there is no mention of an exemption for content whose appearance is controlled by the user agent.

Until now, we have regarded the native HTML date picker as the least worst option, but does its behaviour in Firefox mean we shouldn't use it? FWIW, I generally prefer text inputs, but let's assume a date picker is essential for some reason and that it's just a matter of which one to use.

Steve Green
Managing Director
Test Partners Ltd

From: Dean.Vasile
Date: Thu, May 23 2024 7:23AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

The behavior of the native HTML date picker in Firefox, where the size doesn't adjust with zoom level, is indeed problematic from an accessibility perspective. While the WCAG 2.1 success criterion 1.4.4 Resize Text doesn't explicitly mention date pickers, it is generally understood that all user interface components, including form controls, should resize proportionally with the text.

The fact that the date picker's appearance is controlled by the user agent doesn't necessarily exempt it from this requirement. User agents are still expected to follow accessibility guidelines to the best of their ability.

From: Patrick H. Lauke
Date: Thu, May 23 2024 10:01AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

I think it's hard to put content authors on the hook for the failings of
UA controlled widgets. Similarly, we wouldn't blame content authors if
the browser's File dialog (for <input type="file">) had issues, for
instance. To me it feels like a nominal pass, but with a note to devs
about current shortcomings in UAs that they *may* want to consider
working around (unfortunately, the alternative is "build your own date
picker" which is a big ask, or "just have a text input or a series of
selects or whatever" which is a slightly worse experience for everybody,
potentially...lowest common denominator design).

P
--
Patrick H. Lauke

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

From: Graham Armfield
Date: Thu, May 23 2024 11:42AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

Hi All,

There is an oustanding bug on Firefox about this that I raised a couple of
years ago: https://bugzilla.mozilla.org/show_bug.cgi?id97526

Sadly nothing seems to have happened to resolve this situation.

Regards
Graham Armfield
coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613

From: Jonathan C. Cohn
Date: Thu, May 23 2024 1:46PM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

I seem to remember they're being issues with focus order and date pickers in chromium browsers.

From: Andrews, David B (DEED)
Date: Thu, May 23 2024 1:59PM
Subject: Re: Do native HTML date pickers automatically fail SC1.4.4 (Resize Text)?
← Previous message | Next message →

While this is not specific, as a blind, screen reader user, I will tell you that date pickers on airline sites, hotel sites, and concert ticket places, are a huge problem. Not all are inaccessible, but most are. This is true for both web sites, and smart phone apps.

I recently bought an expensive airline ticket, and thought I got it right, but am having to go a day earlier than I intended, to change would be $1200.  So, I am just going to suck it up, and go to Paris a day earlier!

Dave

From: Birkir R. Gunnarsson
Date: Thu, May 23 2024 6:34PM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

maThis is but one of many examples where browser vendors have dropped the
ball (and are not picking it up).
Other examples:
* Native HTML form validation errors - not visually persistent, not
connected to the invalid inputs
* Native autocomplete (<datalist> elements with an <input> and the list
attribute), can't be resized


Again, we should not expect every developer to have to custom code a
workaround for common native HTML widgets, just because the user agent
developers can't be bothered to make sure it' accessible.

Accessibility has to be made as easy as possible, including having to code
to standards/valid HTML and trust that when you do the browser will turn it
into an accessible experience.
We collectively waste thousands of hours every month working with
developers to custom code solutions that can be coded in native HTML but
have insufficient accessibility support in user agents.

This isn't fair on us or on the developers we work with.

From: Dean.Vasile
Date: Thu, May 23 2024 6:45PM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

Birkir,
I agree with your points on this issue. Do we fail it? It's not the owner's fault, but it's a significant accessibility issue.
Dean

From: Steve Green
Date: Thu, May 23 2024 8:39PM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

I am inclined to agree, but I am trying to understand why we think it's not non-conformant, because I feel we should always be able to point to the specific phrases in the success criteria that support our decision.

One argument is that content authors should not be on the hook for the failings of UA controlled widgets, but the SC does not include such an exemption. Other SCs do, and there doesn't appear to be a general exemption that applies to all SCs, unless I'm missing something. The counter-argument is that content authors have the choice not to use these components, so they should be on the hook if they do.

Another possibility is that the SC does not even apply to this type of component because it's not actually text. This argument hinges on the meaning of the phrase "text-based controls", which WCAG describes as "text characters that have been displayed so that they can be seen [vs. text characters that are still in data form such as ASCII])." I think this phrase is intended to exclude native HTML components such as comboboxes and the date picker on the grounds that they contain glyphs, not ASCII characters.

Steve

From: Patrick H. Lauke
Date: Fri, May 24 2024 2:51AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

On 24/05/2024 01:45, = EMAIL ADDRESS REMOVED = wrote:
> Do we fail it? It's not the owner's fault, but it's a significant
accessibility issue.

I'd add here that *if* the problem with a specific browser/user agent's
handling and implementation of a widget, the responsibility is also on
the users themselves to choose browsers/UAs that work for them - with
exception of effectively closed platforms like iOS/iPadOS at the moment
(where you can have different browsers, except they're all Safari/WebKit
under the hood).

My take, again, is that for pure WCAG compliance, it's not the fault of
the developer, as long as the technology they use is accessibility
supported (i.e. it's implemented correctly and accessibly in at least
one widely available UA)

Developers may then *choose* to put extra effort in to work around
broken/inaccessible implementations in other browsers, but that goes
beyond pure WCAG compliance, IMO.

P
--
Patrick H. Lauke

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

From: Patrick H. Lauke
Date: Fri, May 24 2024 2:58AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

On 24/05/2024 03:39, Steve Green wrote:
> I am inclined to agree, but I am trying to understand why we think it's not non-conformant, because I feel we should always be able to point to the specific phrases in the success criteria that support our decision.
>
> One argument is that content authors should not be on the hook for the failings of UA controlled widgets, but the SC does not include such an exemption. Other SCs do, and there doesn't appear to be a general exemption that applies to all SCs, unless I'm missing something. The counter-argument is that content authors have the choice not to use these components, so they should be on the hook if they do.

A line has to be drawn about what is and isn't under the control of *web
content* authors. For things that are outside of their direct control
(things like the browser's own UI, its own widgets, things like the File
dialog, etc) we're not talking *web content* anymore, in my view. We
then fall back on (also fluffy and vague) concepts like "accessibility
supported" https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported I'd
say - which can then be used to justify the more radical "they simply
shouldn't be using that particular approach/technology then" answer.

P
--
Patrick H. Lauke

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

From: Birkir R. Gunnarsson
Date: Fri, May 24 2024 4:24AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

To the user, it doesn't matter whose fault it is when they run into issues,
like content that stubbornly refuses to resize.
When it fails, ultimately it is the content author's responsibility to fix
it or at least tell the user how to work around it.
It should be flagged and the choice should be laid in front of the
stakeholders, to go with inaccessible out-of-the-box control or to custom
build a more accessible one.
I think, as a community of experts working with development teams, it is
also our responsibility to try and flag and promote issues where browsers
are letting developers and users down.
I admit I need to do better myself in this area.

From: Steve Green
Date: Fri, May 24 2024 4:53AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

This is all true, but there is a practical difficulty. Most of our clients get their websites built and maintained by third-party development companies. Invariably, the contract states that the website must be conformant with WCAG 2.2 AA. If we say that something needs to be changed, the developers will expect our client to pay for the change unless we can show that it is required due to a non-conformance. This is why most of my questions relate to conformance.

Some fixes can be trivial, but ripping out a native date picker isn't, especially when there is no consensus as to what it should be replaced with. Options include a single textbox, three textboxes, three comboboxes or a custom date picker, but I have seen strong objections to all of them.

Steve

From: Birkir R. Gunnarsson
Date: Fri, May 24 2024 10:34AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

Would a single text input for the date be equivalent to a datepicker?
In most generaal situations I'd say it would be equivalent.

Where a datepicker provides critical info about what dates to pick, e.g. it
is an appointment calendar and you can see which days have available
appointments, or it's a calendar for booking a flight or hotel and prices
are attached to each day, obviously you need that info when you are
selecting.

So if the datepicker does not show anything over a date input, other than
indicating the days of the week, I think you can justify that it does not
have to be fully accessible, especially when it's native, but if it shows
such info I think you'd have to code something.
Again, opinions vary among experts and an expert can even have different
opinions based on minor context differences, but that's how I would
approach it, for what it's worth (which probably isn't much). ;)

From: Steve Green
Date: Fri, May 24 2024 11:55AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

A single textbox is as accessible as a date picker, arguably more so. However, the argument against it is that it is much more prone to incorrect data entry, so it is necessary to include more error handling. That's not a big issue when starting from scratch, but it's more of an issue when you are asking someone to rip out a component that already works, especially if you are not going to pay them for that work.

Steve

From: Birkir R. Gunnarsson
Date: Sun, May 26 2024 2:56PM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

Yeah man, it's a tough situation.
You can use the date input type, though it doesn't offer much in the way of
auto-formatting.
You can add some Javascript auto formatting without too much work (i.e.
allow the user a more flexible input.
e.g.
https://codepen.io/tutsplus/pen/KMWqRr

With some copying and pasting it should only take an extra hour of work,
definitely a lot less work than trying to write an accessible datepicker.

That's the route I'd try to go with this, but honestly it's up to the
client and your feel for the dynamics. Whatever you do, make sure to file
or comment on browser bugs for this in Firefox/Safari/Chrome/Edge.
If you post the URL for the issues back here I'll take time to comment on
them and ask some of my colleagues to do the same . It may not be much, but
if you can point to the fact you have tried to do something about the
inaccessibility of the datepickers that might be of some value.

From: Graham Armfield
Date: Mon, May 27 2024 5:20AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | Next message →

Hi there, I know it's probably not the point you're trying to make but in
your Codepen example, the hint text for the date format will probably not
be read out by screen readers like NVDA and Jaws. The user will be in
'Forms' mode and the text is not linked to the input.

Use of aria-describedby to link the format information to the input would
help here.

Regards
Graham Armfield
Coolfields Consulting

From: Steve Green
Date: Mon, May 27 2024 9:59AM
Subject: Re: Do native HTML date pickers automatically fail SC 1.4.4 (Resize Text)?
← Previous message | No next message

If you're doing it for yourself, it may well only be an hour's work, but in a commercial situation it can take much longer. When we worked for a bank, they told us that every change had to be approved by people from about ten different departments such as UX, development, security, marketing, legal etc. The cost of even the smallest change was huge and took weeks even if there were no objections. Spelling errors and small bugs were never fixed even though the fixes themselves would only take seconds to implement. Even "agile" digital agencies and their clients can take hours to reach agreement on what we think are simple issues.

This is why I frequently refer to context in my posts. Most people seem oblivious to contexts other than their own.

Steve