RE: WCAG strategy [was:RE: Responsive design and "loss of functionality"]

What you’re proposing is fine if you’re doing your own development. However, if you outsource development to a third party, you need a binary “right” or “wrong” standard in order to assess whether they have met their contractual obligations. In the absence of such a binary standard, who is to say whether a website is sufficiently accessible, and crucially, who is to pay for any improvements?

Many national accessibility laws, such as the UK Equality Act, are concerned with “actual outcomes” rather than technical conformance, which sounds like the sort of thing you are proposing. This has positive and negative consequences, such as:


  *   Organisations can engage third-party developers to achieve WCAG conformance, which has predictable cost and (fairly) binary acceptance criteria. The developer bears the cost of any necessary fixes to achieve this. The organisation can then request further improvements, for which they need to pay extra. This is potentially open-ended.

  *   The organisation has no way of knowing if they have done enough to meet the law. Despite going way beyond what WCAG requires (even at AAA), it’s possible the website will not be accessible to someone who then brings a legal case.

Despite this, I think the current situation of a binary technical standard and a woolly legal requirement based on actual outcomes is probably the best. On their own, both the binary and woolly standards are problematic.

Steve Green
Managing Director
Test Partners Ltd


From: Urban, Mark (CDC/OCOO/OCIO/CEO) <fka2@cdc.gov>
Sent: Monday, June 10, 2024 12:41 PM
To: Michael Livesey <mike.j.livesey@gmail.com>; Adam Cooper <cooperad@bigpond.com>
Cc: David Woolley <forums@david-woolley.me.uk>; w3c-wai-ig@w3.org
Subject: WCAG strategy [was:RE: Responsive design and "loss of functionality"]

Hi all,

Slight detour here as this touches an important strategic point, namely a recurring tension in WCAG:  Do we define things so tightly there’s a binary “right” or “wrong”, or do we say there’s a “minimum/better/best” continuum?

I support the latter – the continuum.  Accessibility as a quality, not a quantity. While this may frustrate developers who want “THE correct answer, testable via automation/AI”, we are dealing with human factors and capacity, not code for code’s sake.  If people are struggling to use it EASILY due to a disability, its not fully accessible, but that doesn’t mean its completely inaccessible, either.

The goal of WCAG should be to allow people to innovate, but to have a well-defined “North Star” of functional, multi-disability ease of use and interoperability with assistive technology.  This model necessitates people taking detours, and sometimes needing to backtrack when they reach a roadblock.

Loss of Functionality is such an element.  The standard is designed to be interpretive, to give leeway to different service delivery models. However, if you CAN’T access that function (vs. annoying or hard), then it fails.  Annoying or hard (e.g. have to use an accessible backtrack to the beginning) is probably not a complete failure, but it’s not good accessibility, either.

Regards,

[Office of the Chief Information Officer (OCIO) | Office of the Chief Operating Officer (OCOO)]
Mark Urban
CDC/ATSDR Accessibility Program Director
Office of the Chief Information Officer (OCIO)
Office of the Chief Operating Officer (OCOO)
919-541-0562  (office) | (470) 532-2968 (mobile)
fka2@cdc.gov<mailto:fka2@cdc.gov>
Accessibility Needs?  Use the Service Portal<https://servicedesk.cdc.gov/sp?id=search&spa=1&t=sc_ossam,sc_ofr,kb,sc,kb_hro,sc_hro&q=accessibility>!


From: Michael Livesey <mike.j.livesey@gmail.com<mailto:mike.j.livesey@gmail.com>>
Sent: Saturday, June 8, 2024 10:40 PM
To: Adam Cooper <cooperad@bigpond.com<mailto:cooperad@bigpond.com>>
Cc: David Woolley <forums@david-woolley.me.uk<mailto:forums@david-woolley.me.uk>>; w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Subject: Re: Responsive design and "loss of functionality"

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________

I believe it largely follows the below pattern for role, aria attributes and functionality.

https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/


On Sunday, June 9, 2024, Adam Cooper <cooperad@bigpond.com<mailto:cooperad@bigpond.com>> wrote:
> 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<mailto:mike.j.livesey@gmail.com>>
> Sent: Sunday, June 9, 2024 8:13 AM
> To: David Woolley <forums@david-woolley.me.uk<mailto:forums@david-woolley.me.uk>>
> Cc: w3c-wai-ig@w3.org<mailto: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.
>>
>>