- From: Michael Cooper <michaelc@watchfire.com>
- Date: Mon, 20 Mar 2006 11:20:50 -0500
- To: <public-wcag-teamc@w3.org>
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