2.5.8 Target size (minimum) lacks 'Alternative' exception

[mbgower]

During the conversation for allowing a user agent exception for target size as per #1904, ShawnT gave the date picker (and color picker) as an example of a native html element that have target sizes that fail the criterion. @awkawk also mentioned the spin button.

Looking at an example of an input type="date" implementation,

I realized I've always ignored these because I simply type in the data. Which made me realize that there is no wording here for an alternative method exception.

Such wording exists in the AAA Target Size (Enhanced) requirement:

Equivalent
The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;

I propose modifying that slightly for the AA to read:

Equivalent
The function can be achieved through an equivalent control that is at least 24 by 24 CSS pixels;

---

On the related topic of user agent exception, I thought I'd mention that there is also an exception in our AAA requirement:

User Agent Control
The size of the target is determined by the user agent and is not modified by the author;

so it seems odd that we do not have at least this equivalent in the AA criterion

---

Part of me wonders if we need both exceptions. I believe the user agent exception may suffice?

[mbgower]

@rachaelbradley ^

[mraccess77]

Typing in a date in not equivalent to having access to the calendar to provide context of dates by day of week, month, looking in future, or and allows selection without typing. We wanted all of the pointer related criteria to apply regardless of keyboard alternative.

[mbgower]

There are a few interesting things to parse there, @mraccess77. Going to divide my responses into 2 comments by topic...

User agent exception

I just pasted in a snippet of the same calendar widget, this time taken from Chrome (in my original post, it's Safari). Interestingly, all the calendar grid components pass in the Chrome example, while all of them appear to fail in the Safari example.

So that speaks to the user agent exception. Are we sentencing authors to test against all browsers to determine if they've failed? Are we forcing authors to do a custom calendar across all browsers to ensure it works (again, forcing them to test against all browsers to ensure they haven't introduced a bug)? If a certain browser does this fine, is the one that doesn't just a bug in the browser?

Between those questions and the fact the AAA SC allows a user agent exception, I think I'm less confortable with the PR wording of only excepting user agent defaults where the author can't change. It just seems too heavy a lift.

[mbgower]

Equivalent facilitation and use of keyboard

For both browsers, the actual text inputs for the date meet all existing criteria in WCAG 2.1. So here's an example where the new SC is going to potentially fail a lot of existing sites.

In both, I can even click on the separate YYYY MM or DD parts of the input as complying targets (the day is highlighted in the prior comment's shot) and adjust each value separately by arrow keys, which is actually a very fast way of moving by year and month.

The actual ability to launch the calendar grid has a sufficient target in both implementations, so a sighted user can see all that context you're talking about for the current month.

@mraccess77 said:

allows selection without typing

I believe you're arguing that, unless we except user agent defaults, this would fail my proposed Equivalent bullet for Target Size (Minimum) because the user, in order to see the correct month of the calendar, has to use the arrow keys in the above example to increment the values? That seems like something of a slippery slope. What if this was a simple text input? A mouse user can click on the input target but is going to have to use their keyboard to input the text (at least on the desktop). What if the calendar grid did not exist, and the YYYY MM and DD targets were the only parts of this widget? The targets would be the right size, but the user would still need a keyboard to operate. Does that mean that all inputs where keyboard entry is required fail Target Size?

Stated another way, if we are going to bring equivalent facilitation into it, how far does the equivalent have to be pointer only?
Whether a date input is equivalent facilitation for a date calendar widget is an old debate, and I see points on both sides -- so I'd like to ensure we don't only discuss this issue in relation to that component. My point is that some kinds of interaction require keyboard operation even for users who bias to a pointer, so I wonder how this informs our discussion about any single scenario.

@awkawk mentioned a number input as another example. Are the +/- increment controls an additional mechanism besides the ability for all users to enter in a value? Or are those controls a core part of the element that needs to provided in any implementation? If a user agent only provided a standard text input for numbers, without the increment controls, would that be a failure on its own?

[mbgower]

BTW, the other stock HTML component mentioned was colour picker. Again, seeing super different presentations in Safari, which fails at less than 19x19 for each swatch in the grid of about 150 colors

versus Chrome which offers two continuum gradient selectors

These rectangular bars that span a colour spectrum pass based on the note language:

Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

It's also worth mentioning the secondary methods on these pages.

The Chrome version also offers an eye dropper mechanism as well as direct inputs, the former offering another successful pointer interaction, the latter offering a keyboard equivalent. The eye dropper doesn't required drag and drop (as is typical for eye droppers, which essentially offer a built-in 'press and hold' feature as part of their functionality).

The Show colors button on Safari provides a second view, which offers a continuous color wheel, which passes due to that same 'spatially based' language. This second view also offers an eye dropper.

So, here there's a pretty good case that we potentially need the equivalent as well. The Safari colour picker provides mouse-only selection via the second view. There doesn't seem to be a good reason Safari's picker should fail strictly because the first view does not meet target size for each swatch.

What about the eye dropper?

Finally, the eye dropper, although not failing dragging, offers an intersting discussion on target size. The dropper literally offers an ability to select a pixel. It uses a low-level of magnification to make the pixels larger, but they are nothing like 24x24. I'm assuming this gets a pass through the same 'spatially based' note.

[mraccess77]

If a user agent did not provide arrows for a spin button control and only allowed the keyboard then in my opinion that would not be a failure of this requirement. If some user agents had sufficient size and others did not that seems like a pass if the author can't change those sizes. They shouldn't fail for not being able to control the user agent styling. I don't think we want to allow a keyboard alternative as that would basically mean nothing needs to be done for any of those. If a button is too small someone could just say the button is keyboard accessible so why have this criteria if it's always passed with a keyboard. This criteria would never fail as WCAG already requires every function to be keyboard accessible.

[mbgower]

@mraccess77, you said:

If a button is too small someone could just say the button is keyboard accessible so why have this criteria if it's always passed with a keyboard.

That would fail my proposed wording:

Equivalent
The function can be achieved through an equivalent control that is at least 24 by 24 CSS pixels;

[alastc]

Closed by #2328