Issue summary for Guideline 2.5

The following issues for Guideline 2.5 have landed on our plate since
the last time we went through issues. Here are proposals for them.
Michael

1653: 2.5.1 you'll have to reword this
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1653

If you want content designed for audio-only output to be able to claim
L2 compliance, you'll have to reword this, as they normally don't
provide anything to the user as text.

Audio-only content would not meet the requirements of WCAG under several
SC. While WCAG describes accessibility features of audio, audio cannot
be used alone without alternatives and be accessible to all users.

Proposal: CLOSE with above explanation.

---

1883: SC 2.5.1 & 2.5.2: Error alerts cause other accessibility problems
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1883

Aren't there potential accessibility issues/assistive technology
conflicts by throwing up an alert as part of client-side validation? The
timing of the alert and what triggers the alert is crucial to affecting
accessibility. For instance if you type the wrong character in a text
input field and an alert pops up, that is very intrusive and disruptive
for screen reader users and may result in accessibility issues.

Most of the techniques describe providing the alert only when the user
attempts to submit the form. "Providing a text message when the user
provides information that is not in list of allowed values"
<http://tinyurl.com/7nl4w> does discuss alerts on a field by field
basis, it implies providing the alert only when the field is exited but
does not state that, and there is a comment about difficulty even with
that situation.

Proposal: Add note about not doing an alert the instant a wrong
character is input to the above technique. The possibility of doing an
alert on each form field, though intrusive, does not seem
discriminatorily intrusive on people with disabilities and probably
cannot be forbidden for WCAG conformance. CLOSE this issue.

---

1884: SC 2.5.1 & 2.5.2: client-side validation should be optional
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1884

It should be made clear that for security/technology support reasons,
client-side validation should never be used on its own. It should always
be backed up by server-side validation.

Team C has discussed this and said Team C: this is a baseline issue - if
script in baseline it should be fine. Either client-side or server-side
validation is sufficient (depending on baseline). Note for security this
is crucial but that's beyond our scope. Techniques for both client-side
and server-side validation are suggested in the general techniques for
this SC.

Proposal: CLOSE with the above explanation.

---

1885: SC 2.5.1: improvements for technique
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1885

Shouldn't the redisplaying of the form with a summary of errors
preceding the form (summary identifies the number of errors and each
error is listed with a link to the field where the error occurred). The
error would also be included in the label associated with the form field
where the error occurred. This would be much more accessible than any
client-side validation could be.

Team C liked this in previous discussion. This has been provided in
examples to several techniques for this SC.

Proposal: CLOSE with above explanation.

---

1888: SC 2.5.1: examples should show server-side, not client side,
solution
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1888

Wouldn't it be better to have a server-side solution rather than a
client-side solution for the example? Probably the most useful example
would be the redisplaying of the form with a summary of errors preceding
the form (summary identifies the number of errors and each error is
listed with a link to the field where the error occurred). The error
would also be included in the label associated with the form field where
the error occurred.

This has been provided as an option in examples to several techniques
for this SC.

Proposal: CLOSE with above explanation.

---

1890: SC 2.5.3: issues with techniques
http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1890

Is an alert or pop-up window a good solution? Wouldn't this create
accessibility issues? What about popup blockers? Is it a good idea to
include "Are you sure?" as an example? This is making the assumption
that the user knows the context of the alert which is not necessarily
the case.

Techniques all refer to the use of "alerts", not "popup windows". In
discussion, Team C leans toward recommending that this popup be
permitted, which would mean rejecting this issue. Recent work on the
change of context guideline explicitly permits this approach.

Proposal: CLOSE with above explanation.

Received on Monday, 20 March 2006 16:20:55 UTC