Thread Subject: Gaps in Web requirements - error handling techniques

Return to this mailing list's archives

From: Andi Snow-Weaver
Date: Sun, Dec 17 2006 6:30 AM
Subject: Gaps in Web requirements - error handlingtechniques

Kate Walser raised the following point:

Error handling is a frequent function in web and software applications that
often gets neglected in specific Section 508 standards/requirements. Pop-up
messages for errors are usually handled well by assistive technologies.
However, errors that are indicated at the top of pages (typically in red)
or by red error graphics next to fields in errors create significant issues
for people with disabilities. Users typically do not know that they have
errors and if they do, getting to the errors to correct is difficult at
best. Error detection and correction is certainly not comparable to sighted
and mouse users.

Do we need to recommend adding a requirement to address this situation?

Andi

From: Hoffman, Allen
Date: Mon, Dec 18 2006 7:00 AM
Subject: Re: Gaps in Web requirements - errorhandlingtechniques

Andi wrote:
"
Kate Walser raised the following point:

Error handling is a frequent function in web and software applications
that often gets neglected in specific Section 508
standards/requirements. Pop-up messages for errors are usually handled
well by assistive technologies.
However, errors that are indicated at the top of pages (typically in
red) or by red error graphics next to fields in errors create
significant issues for people with disabilities. Users typically do not
know that they have errors and if they do, getting to the errors to
correct is difficult at best. Error detection and correction is
certainly not comparable to sighted and mouse users.

Do we need to recommend adding a requirement to address this situation?"

I think if we address focus problems, and logical reading order, this
one will fall in line. We might certainly consider using error pop-ups
as an example in the language of something that would require attention.

Allen Hoffman
Department of Homeland Security Office on Accessible Systems &
Technology

From: Peter Korn
Date: Mon, Dec 18 2006 11:25 AM
Subject: Re: Gaps in Web requirements - error handling techniques

H Andi, Kate,

> Kate Walser raised the following point:
>
> Error handling is a frequent function in web and software applications that
> often gets neglected in specific Section 508 standards/requirements. Pop-up
> messages for errors are usually handled well by assistive technologies.
> However, errors that are indicated at the top of pages (typically in red)
> or by red error graphics next to fields in errors create significant issues
> for people with disabilities. Users typically do not know that they have
> errors and if they do, getting to the errors to correct is difficult at
> best. Error detection and correction is certainly not comparable to sighted
> and mouse users.
>
> Do we need to recommend adding a requirement to address this situation?

Perhaps.

AT is able to handle pop-up messages (at least in their own windows)
because there is sufficient semantic information (or meta-data)
available to the AT to determine this. In most GUI systems there is a
small collection of styled dialog boxes - "message box", "alert", etc.,
whose role can be determined by the AT via operating system API calls.

If we do decide to address this issue in 508, we should consider doing
so with web document structure or WAI ARIA meta-data tagging, so that
web authors can directly indicate that some portion of the web
document/web application is acting as an alert of some sort. That
information must then be conveyed to the AT via the user agent in some
fashion (such as via DOM events exposed via some special API that the
browser implements and the AT is using; or via a general desktop
accessibility API).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Andi Snow-Weaver
Date: Tue, Jan 09 2007 1:50 PM
Subject: Re: Gaps in Web requirements - error handlingtechniques

At our meeting last week, we discussed the issue of error handling. There
was general consensus that recovering from errors can be an accessibility
issue, there was concern that if we try to put something in the standard to
cover the issue raised, it will be too prescriptive. We briefly discussed
the WCAG 2.0 provision on error handling. I took an action item to post it
here as a proposal for discussion this week.

WCAG 2.0 provision on error handling:

If an input error is detected, the error is identified and described to the
user in text.

WCAG 2.0 provides several strategies (also known as sufficient techniques)
in the "How to meet" information for this provision. See them at
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060801/Overview.html#minimize-error-identified

Andi

From: Fratkin, Mike
Date: Wed, Jan 10 2007 5:55 AM
Subject: Re: Gaps in Web requirements - errorhandlingtechniques

The WCAG 2.0 provides some very good direction and techniques. However,
the part that is missing from WCAG 2.0 is the ability to productively
navigate to the error field in question. Pop-up messages are fine but
when errors are identified at the top of the screen and when fields are
flagged, there needs to be a way for the user to go directly to the
field in error to correct the problem.

Mike Fratkin
SSA

[Andi wrote:]

At our meeting last week, we discussed the issue of error handling.
There was general consensus that recovering from errors can be an
accessibility issue, there was concern that if we try to put something
in the standard to cover the issue raised, it will be too prescriptive.
We briefly discussed the WCAG 2.0 provision on error handling. I took an
action item to post it here as a proposal for discussion this week.

WCAG 2.0 provision on error handling:

If an input error is detected, the error is identified and described to
the user in text.

WCAG 2.0 provides several strategies (also known as sufficient
techniques) in the "How to meet" information for this provision. See
them at
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060801/Overvie
w.html#minimize-error-identified

Andi

From: Sean Hayes
Date: Wed, Jan 10 2007 8:10 AM
Subject: Re: Gaps in Web requirements - errorhandling techniques

I assume WCAG uses 'in text' as it is assuming it is some sort of lowest common denominator, but probably it ought to say something like 'in the most appropriate/accessible manner' e.g. in a speech interface, speech might be the most appropriate.

Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi Snow-Weaver
Sent: 09 January 2007 20:45
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Gaps in Web requirements - error handling techniques


At our meeting last week, we discussed the issue of error handling. There
was general consensus that recovering from errors can be an accessibility
issue, there was concern that if we try to put something in the standard to
cover the issue raised, it will be too prescriptive. We briefly discussed
the WCAG 2.0 provision on error handling. I took an action item to post it
here as a proposal for discussion this week.

WCAG 2.0 provision on error handling:

If an input error is detected, the error is identified and described to the
user in text.

WCAG 2.0 provides several strategies (also known as sufficient techniques)
in the "How to meet" information for this provision. See them at
http://www.w3.org/WAI/GL/WCAG20/WD-UNDERSTANDING-WCAG20-20060801/Overview.html#minimize-error-identified

Andi