RE: Responsive design and "loss of functionality"

Unfortunately, in my humble opinion and for what it’s worth, there is nothing in WCAG 2.x that I can find that would make either of these widgets non-conforming at any level assuming all the other aspects of their respective implementations are themselves conforming.

 

The normative definitions of ‘functionality’ and ‘same functionality’ are framed in terms of an end rather than a means. 

 

And ’process’ is an unquantified series of user actions without reference to efficiency or requirements for effort. 

 

In my view, this is a significant omission in WCAG 2.x … imagine if the definition of functionality was ’the minimum number of user actions required to achieve an outcome. Or something that required consideration of the efficiency of interactions for all users rather than merely the ability of people to achieve an outcome successfully?

 

However, having said this, it sounds like from your description of the ‘accessible version’ that there are a number of other conformance issues? For example, do the keyboard focusable items have a role? Do these items indicate their select state if someone was to return to the dropdown? 

 

And, to Karen’s point in a subsequent email,  accessible to whom and in what circumstances? 

 

I’d also be interested to know whether the client’s functional requirements specified that it must be possible to delete multiple items simultaneously or whether they specified that this or that particular widget must be used or provided a visual design?

 

If it’s the latter, I’d be telling them and the developers who support their decision to stick with their knitting. 

 

 

 

 

From: Michael Livesey <mike.j.livesey@gmail.com> 
Sent: Sunday, June 9, 2024 8:13 AM
To: David Woolley <forums@david-woolley.me.uk>
Cc: w3c-wai-ig@w3.org
Subject: Re: Responsive design and "loss of functionality"

 

The original UI was a select drop-down with only selection functionality.

I'm well aware that a grid pattern with checkboxes would be preferable, but due to various reasons, including the client's requirements we are stuck with the drop-down for now.

I'm still interested in opinions regarding the functionality/processes question and whether any criteria and broken.

On Saturday, June 8, 2024, David Woolley <forums@david-woolley.me.uk <mailto:forums@david-woolley.me.uk> > wrote:
> On 08/06/2024 19:35, Michael Livesey wrote:
>>
>> I can't share the actual UX, but perhaps this visualisation might help - in
>> non-accessible mode, the user can click any "X" icon (a button) and delete
>> one or more list items.
>>
>
> The standard user interface paradigm for this would be check boxes. pre-populated as ticked.  You'd delete by clicking on  each box, and there would be a commit  button, for when you were done.  I'm not sure why you need to deviate from user expectations.
>
>