E-mail List Archives

Search E-mail List Archives for

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

From: Jeremy Echols
Date: Fri, Sep 25 2020 2:00PM
Subject: "Error feedback MUST be programmatically-associated with the appropriate element"
No previous message | Next message →

I'm going through the Deque training, and while I have so far found it extremely informative, I wish it would specify things like which SC a requirement falls under, what level, etc. The subject of this email is one that I'm totally unfamiliar with. I knew that errors in forms had to be identified clearly such that a screen reader user could fix any mistakes, but this section of the training talks about associating each error message with a specific form field, for instance via aria-describedby.

What SC would this fall under? What level? Is this a AAA thing? That would explain why I've never run into it. Or am I just ignorant of a requirement I've been failing for years?

From: Kathryn.Frederick
Date: Fri, Sep 25 2020 2:09PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

Hi,

While I'm unable to give you an exact SC for this situation, I can offer my personal perspective, as a screen reader user. When filling out a form, it's helpful to know which specific field has the error(s) because sometimes those general messages aren't clear enough to be understood.

Katie Frederick

From: Vaughn, Michael
Date: Fri, Sep 25 2020 2:16PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

I agree that the Deque training could be improved by incorporating the SC that applies into the training. Especially if you’re using this training to help improve the ability to conduct WCAG audits.

You might find it helpful to refer to their WCAG checklist<https://dequeuniversity.com/checklists/web/>. So for example searching for the topic finds on page 35 of the PDF version<https://media.dequeuniversity.com/public/en/docs/deque_web_accessibility_checklist.pdf> that it indicates this would fail 3.3.1<https://www.w3.org/WAI/WCAG21/Understanding/error-identification>.


From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = >
Date: Friday, September 25, 2020 at 4:01 PM
To: = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] "Error feedback MUST be programmatically-associated with the appropriate element"
I'm going through the Deque training, and while I have so far found it extremely informative, I wish it would specify things like which SC a requirement falls under, what level, etc. The subject of this email is one that I'm totally unfamiliar with. I knew that errors in forms had to be identified clearly such that a screen reader user could fix any mistakes, but this section of the training talks about associating each error message with a specific form field, for instance via aria-describedby.

What SC would this fall under? What level? Is this a AAA thing? That would explain why I've never run into it. Or am I just ignorant of a requirement I've been failing for years?

From: Jared Smith
Date: Fri, Sep 25 2020 2:27PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

3.3.1 requires that error information, if detected, be identified and described in text. 3.3.3 does the same for error suggestions. These, however, do not specifically require that this information be associated to the relevant inputs.

This would instead generally fall under 1.3.1. If a visual association between the error information and the relevant input is present, this should also be programmatically defined - probably via aria-describedby (and aria-invalid is a good idea too).

This would not apply for error information that is not presentationally associated to the inputs. For example, if the error message appears at the top of a form, it's not visually associated to the input, so there is no requirement in WCAG to programmatically associate it.

Jared Smith

From: Jeremy Echols
Date: Fri, Sep 25 2020 2:31PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

Interesting. I think the Deque training, in this case, may be misusing the "MUST" keyword. One of the major drawbacks to not having budget for in-person training, I suppose.

From: Jeremy Echols
Date: Fri, Sep 25 2020 2:35PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

Looking over that checklist, I came to the same conclusion Jared just stated: showing error messages is required, and making sure they're clear is required. But they aren't required to be associated with a specific input programmatically unless they are associated visually.

I get the annoyance of not having these things easily identified, and I need to improve my form design for sure in some ways, but I also need to know when I can actually cite a failure as opposed to stating that something is a best practice.

From: Patrick H. Lauke
Date: Fri, Sep 25 2020 5:37PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

On 25/09/2020 21:27, Jared Smith wrote:
> This would instead generally fall under 1.3.1. If a visual association between the error information and the relevant input is present, this should also be programmatically defined - probably via aria-describedby (and aria-invalid is a good idea too).

A quick drive-by +1 from me on this - in the common cases where the
error appears right next to/underneath/above the form field, I'd
generally fail it if it's not associated (either via aria-describedby,
or somehow part of the <label> for the field, or replicated verbatim in
aria-label or similar).

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Fri, Sep 25 2020 8:26PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

This is part interpretation, part what I would term 4.6.2 (3.3.1 + 1.3.1)
The text for 3.3.1 says:

"Error Identification: If an input error is automatically detected,
the item that is in error is identified and the error is described to
the user in text."

So that is required, both identifying the erronious input and
describing the error in text.
Here's where the standard is showing its age, the understanding
document goes on to say:


"The identification and description of an error can be combined with
programmatic information that user agents or assistive technologies
can use to identify an error and provide error information to the
user. For example, certain technologies can specify that the user's
input must not fall outside a specific range, or that a form field is
required. Currently, few technologies support this kind of
programmatic information..."

This was true in 2008 when the specification was published, which is
why the most accessible error message mechanism people could come up
with was to put the error descriptions in a link at the top of the
form. Clicking the link took the user to the erronious input.

Now we have aria-invalid to mark an input as invalid, and
aria-describedby to programmatically associate the error message with
the invalid input. Both conditions are required by 3.3.1.
So I think this argument actually holds, that aria-invalid +
aria-describedby are required for an error message to pass 3.3.1.
Mind you, HTML5 validation lets the browser do both these things, if
an input fails browser validation it will do the equivalent
association e.g. type="email" or using the pattern attribute, a new
favorite of mine for form validation, though I had to brush up on
regular expressions.


Then there is 1.3.1. If you identify the error input visually and
place the error message next to it you've created a visual association
between the two. 1.3.1 says that information that is communicated
visually must also be made available programmatically or described in
text.
Describing it in text is tricky, unless you stuff the form field
label, which makes for a bad user experience, or resort to exposing
errors as links at the top of the form, which is worse usability for
low vision users and people with cognitive impairments.

So I say 4.6.2 covers it. ;)






On 9/25/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 25/09/2020 21:27, Jared Smith wrote:
>> This would instead generally fall under 1.3.1. If a visual association
>> between the error information and the relevant input is present, this
>> should also be programmatically defined - probably via aria-describedby
>> (and aria-invalid is a good idea too).
>
> A quick drive-by +1 from me on this - in the common cases where the
> error appears right next to/underneath/above the form field, I'd
> generally fail it if it's not associated (either via aria-describedby,
> or somehow part of the <label> for the field, or replicated verbatim in
> aria-label or similar).
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Sat, Sep 26 2020 8:35AM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

On 26/09/2020 03:26, Birkir R. Gunnarsson wrote:
> This is part interpretation, part what I would term 4.6.2 (3.3.1 + 1.3.1)
> The text for 3.3.1 says:
>
> "Error Identification: If an input error is automatically detected,
> the item that is in error is identified and the error is described to
> the user in text."
>
> So that is required, both identifying the erronious input and
> describing the error in text.

But it doesn't say when/how this identification/description should
happen. If the error message is a paragraph that comes after an input
but is not associated, you could still say that "the error is identified
and the error is described to the user in text". Just that the user
needs to find that. It doesn't qualify how it should be done, or that it
should be programmatic/automatic.

> Here's where the standard is showing its age, the understanding
> document goes on to say:
>
>
> "The identification and description of an error can be combined with
> programmatic information that user agents or assistive technologies
> can use to identify an error and provide error information to the
> user [...]"

But of course, that part isn't normative, and it's more a
suggestion/best practice of what *can* be done.

So it still feels like for normative fail, 1.3.1 is the best bet.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Sat, Sep 26 2020 8:37AM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

On 26/09/2020 15:35, Patrick H. Lauke wrote:
> On 26/09/2020 03:26, Birkir R. Gunnarsson wrote:

>> "The identification and description of an error can be combined with
>> programmatic information that user agents or assistive technologies
>> can use to identify an error and provide error information to the
>> user [...]"
>
> But of course, that part isn't normative, and it's more a
> suggestion/best practice of what *can* be done.
>
> So it still feels like for normative fail, 1.3.1 is the best bet.

And to close that additional loop, providing/not providing aria-invalid
would fall under 4.1.2 as it's a state.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Sat, Sep 26 2020 9:01AM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

Welcome to WCAG interpretation gymnastics. ;)


On 9/26/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 26/09/2020 15:35, Patrick H. Lauke wrote:
>> On 26/09/2020 03:26, Birkir R. Gunnarsson wrote:
>
>>> "The identification and description of an error can be combined with
>>> programmatic information that user agents or assistive technologies
>>> can use to identify an error and provide error information to the
>>> user [...]"
>>
>> But of course, that part isn't normative, and it's more a
>> suggestion/best practice of what *can* be done.
>>
>> So it still feels like for normative fail, 1.3.1 is the best bet.
>
> And to close that additional loop, providing/not providing aria-invalid
> would fall under 4.1.2 as it's a state.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: Katie Haritos-Shea
Date: Sat, Sep 26 2020 1:45PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

I've always liked how you think Birkir!

On Sat, Sep 26, 2020, 11:01 AM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Welcome to WCAG interpretation gymnastics. ;)
>
>
> On 9/26/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> > On 26/09/2020 15:35, Patrick H. Lauke wrote:
> >> On 26/09/2020 03:26, Birkir R. Gunnarsson wrote:
> >
> >>> "The identification and description of an error can be combined with
> >>> programmatic information that user agents or assistive technologies
> >>> can use to identify an error and provide error information to the
> >>> user [...]"
> >>
> >> But of course, that part isn't normative, and it's more a
> >> suggestion/best practice of what *can* be done.
> >>
> >> So it still feels like for normative fail, 1.3.1 is the best bet.
> >
> > And to close that additional loop, providing/not providing aria-invalid
> > would fall under 4.1.2 as it's a state.
> >
> > P
> > --
> > Patrick H. Lauke
> >
> > https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> > https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Sailesh Panchang
Date: Sat, Sep 26 2020 2:51PM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

Jared's response to the question that started off this thread is most
accurate IMO.
And I have to disagree with my friend Birkir when he categorically
states, "So I think this argument actually holds, that aria-invalid +
aria-describedby are required for an error message to pass 3.3.1".
Here is an article, "Using Aria-invalid for Error Indication" I wrote
before I wrote up the first draft for the technique ARIA21. The
examples and some text in the technique are from the blog article I
had written.
Blog article:
https://www.deque.com/blog/aria-invalid-error-indication/
ARIA21: aria-invalid
https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21

Best wishes,

--
Join me at axe-con 2021: a free digital accessibility conference. Read more at
https://www.deque.com/axe-con/
Feel free to contact Deque marketing if you have any questions. Thanks!

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

From: Birkir R. Gunnarsson
Date: Sun, Sep 27 2020 11:29AM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

Well, I admit my argument is pretty weak (see my use of "I think").
After all Sailesh is one of the jedi masters of accessibility, and one
of the people who taught me what I do know about it.
I still confidently claim that use of aria-describedby to associate
error messages is the best experience:
* It allows users to visually place error messages adjacent to invalid
inputs, important for low vision users and users with cognitive
impairments), using a pop up or links, users do not necessary see the
error message and the invalid form input together, they have to
memorize it.
Note: I filed screen reader bugs for what I term insufficient support
of the ARIA 1.1 aria-errormessage attribute, I need to check in on
those bugs and see if support has improved. Use of aria-describedby is
problematic, because it does not respect the visibility of the error
message, and I repeatedly run into implementation complications with
it. Those would be solved with aria-errormessage, but until it has
sufficient user agent/assistive technology support, thatis of very
limited value.



On 9/26/20, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> Jared's response to the question that started off this thread is most
> accurate IMO.
> And I have to disagree with my friend Birkir when he categorically
> states, "So I think this argument actually holds, that aria-invalid +
> aria-describedby are required for an error message to pass 3.3.1".
> Here is an article, "Using Aria-invalid for Error Indication" I wrote
> before I wrote up the first draft for the technique ARIA21. The
> examples and some text in the technique are from the blog article I
> had written.
> Blog article:
> https://www.deque.com/blog/aria-invalid-error-indication/
> ARIA21: aria-invalid
> https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21
>
> Best wishes,
>
> --
> Join me at axe-con 2021: a free digital accessibility conference. Read more
> at
> https://www.deque.com/axe-con/
> Feel free to contact Deque marketing if you have any questions. Thanks!
>
> Sailesh Panchang
> Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon, VA 20170
> Mobile: 571-344-1765
> > > > >


--
Work hard. Have fun. Make history.

From: Sailesh Panchang
Date: Mon, Sep 28 2020 11:22AM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | Next message →

Hi Birkir,
Thanks appreciate your thoughts greatly. Perhaps the tables have
reversed now I learn more from the ARIA guru and Accessibility Lead
these days!
Best wishes,
Sailesh


On 9/27/20, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> Well, I admit my argument is pretty weak (see my use of "I think").
> After all Sailesh is one of the jedi masters of accessibility, and one
> of the people who taught me what I do know about it.
> I still confidently claim that use of aria-describedby to associate
> error messages is the best experience:
> * It allows users to visually place error messages adjacent to invalid
> inputs, important for low vision users and users with cognitive
> impairments), using a pop up or links, users do not necessary see the
> error message and the invalid form input together, they have to
> memorize it.
> Note: I filed screen reader bugs for what I term insufficient support
> of the ARIA 1.1 aria-errormessage attribute, I need to check in on
> those bugs and see if support has improved. Use of aria-describedby is
> problematic, because it does not respect the visibility of the error
> message, and I repeatedly run into implementation complications with
> it. Those would be solved with aria-errormessage, but until it has
> sufficient user agent/assistive technology support, thatis of very
> limited value.
>
>
>
> On 9/26/20, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
>> Jared's response to the question that started off this thread is most
>> accurate IMO.
>> And I have to disagree with my friend Birkir when he categorically
>> states, "So I think this argument actually holds, that aria-invalid +
>> aria-describedby are required for an error message to pass 3.3.1".
>> Here is an article, "Using Aria-invalid for Error Indication" I wrote
>> before I wrote up the first draft for the technique ARIA21. The
>> examples and some text in the technique are from the blog article I
>> had written.
>> Blog article:
>> https://www.deque.com/blog/aria-invalid-error-indication/
>> ARIA21: aria-invalid
>> https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21
>>
>> Best wishes,
>>
>> --
>> Join me at axe-con 2021: a free digital accessibility conference. Read
>> more
>> at
>> https://www.deque.com/axe-con/
>> Feel free to contact Deque marketing if you have any questions. Thanks!
>>
>> Sailesh Panchang
>> Principal Accessibility Consultant
>> Deque Systems Inc
>> 381 Elden Street, Suite 2000, Herndon, VA 20170
>> Mobile: 571-344-1765
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >


--
Join me at axe-con 2021: a free digital accessibility conference. Read more at
https://www.deque.com/axe-con/
Feel free to contact Deque marketing if you have any questions. Thanks!

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

From: Mallory
Date: Wed, Sep 30 2020 5:16AM
Subject: Re: "Error feedback MUST be programmatically-associated with the appropriate element"
← Previous message | No next message

I tend to mention them under 1.3.1. There is a visual relationship between an error message and its invalid field, and it is possible to programmatically associate it, so when someone doesn't, I tend to make a ticket.

cheers,

On Fri, Sep 25, 2020, at 10:35 PM, Jeremy Echols wrote:
> Looking over that checklist, I came to the same conclusion Jared just
> stated: showing error messages is required, and making sure they're
> clear is required. But they aren't required to be associated with a
> specific input programmatically unless they are associated visually.
>
> I get the annoyance of not having these things easily identified, and I
> need to improve my form design for sure in some ways, but I also need
> to know when I can actually cite a failure as opposed to stating that
> something is a best practice.
>
>