Re: "Error correction (Processes)" to WCAG 2.2 draft

Hello Alastair,

Call it what you will, but data integrity is still being vetted that
triggers the warning.
Yes on step 2 one can get a warning that 'this change will make the
hotel selection in step 3 invalid'.
And on step 3 one should get a warning or such if one attempts to go
to step 4 without changing hotel selection so it is in sync with
destination selected in step 2.

There are already two SCs that address input errors 3.3.4 and 3.3.6.
Adding a third one with very little difference will give accessibility
experts a hard time trying to discern the difference ... let alone one
who is acquainting oneself with the guidance.
It should not sound like a broken record. I would elevate SC 3.3.6
rather than add a new one.
Thanks,
Sailesh



On 7/17/20, Alastair Campbell <acampbell@nomensa.com> wrote:
> Hi Sailesh,
>
>  > That a warning for "invalidates other previously entered information" is
> in the SC suggests that some validation is present.
>
> It isn't speaking to form validation, it is whether the data (potentially
> later in the same process) would still be valid. However, that is not the
> same as form validation for the page you are on.
>
> Speaking from a developer stand point, if you discuss validation of a form,
> they would not expect that to include data later on in the same form.
>
> Also, what is hopefully clear from the understanding doc is that 'previously
> entered' information can be on a later step that the one you are on. E.g.
> You might fill in 5 pages, go back to page 2, change something, and then
> have to re-enter information later.
>
> We also don't want to setup a clash with "Redundent entry", which is asking
> for forms not to ask the same info twice.
>
>
>  > SC 3.3.6 applies to all forms and submissions including multi step
> processes.
>
> Indeed, so the new one applies less widely and is at a higher level.
>
>
>  > is it really necessary to explicitly include an exception like, "unless
> the  information cannot be modified for logical, security, or privacy
> reasons"? SC 3.3.6 can be effectively applied  even without including this
> explicit exception, no?
>
> 3.3.6 is at level AAA, so we are acknowledging that it may not be applicable
> in all scenarios. The higher level version (3.3.4) is scoped to a narrower
> set of scenarios.
>
>
>  > If for instance, one is not able to change  quantity ordered or shipping
> address (which are not privacy or security info), it impacts all users and
> is a functionality issue and results in poor user experience.
>
> Sure, but the idea here is that the requirement is to allow everyone,
> particularly people with cognitive issues who might not notice mistakes, the
> ability to change the entries.
> There are various feasibility issues with making that a blanket requirement,
> so we did need to introduce some exceptions.
>
>
>  > My general  thought is that we should try to elevate Level AAA SCs first
> before crafting new SCs.
>
> I would agree with that in general. In this case the final SC has come
> closer to 3.3.4/6 than where it started, but I think it is still different
> enough that raising 3.3.6 would not have the same effect. We did discuss the
> similarities during the previous calls.
>
> Kind regards,
>
> -Alastair
>
>
>


-- 
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon, VA 20170
Mobile: 571-344-1765

Received on Friday, 17 July 2020 18:30:24 UTC