- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Mon, 5 Mar 2007 08:13:58 -0600
- To: "'Bailey, Bruce'" <Bruce.Bailey@ed.gov>, "'WCAG'" <w3c-wai-gl@w3.org>
Hi Bruce, Hmmmm. Lots of questions have come up around this. So let me cover some of them here - both yours and others'. 1) I haven't been able to find any gap between the two definitions. I thought we did earlier with Jims suggestion but on closer look it was just a bad example that would pass both. The two descriptions cover the same ground as far as I could determine. They were both designed to describe the same set - "those things you can't do from a keyboard". But to do it in a more descriptive way. Both should cover the same ground. The difference was in the ability to understand them or to describe what causes something to not be 'do-able from a keyboard". 2) the provisions do not really have anything to do with 'can a blind person do this'. It has to do with 'can this be done by people who cannot use various input mechanisms. If it can be done from the keyboard it can be done from a wide range of alternate keyboards as well as mouse-based keyboards, speech input etc. It is the closest you can get to device independence, or better yet - alternate approach support. Keyboard operation helps access by people who are blind but there are many tasks that would also involve vision (like the ones you cite) that could be keyboard operable and still not doable by people who are blind. But that isn't the point here. There are many sighted people who cannot use a mouse etc. 3) The items in your list below don't fall in a gap between the two definitions - they all pass both and should be keyboard controllable. In fact they already are in some incarnation for example: 1 - simple scrolling 2 - similar to resizing and scrolling windows from the keyboard 4) As per the last phone call, "Discern" is the wrong word in any case. Discern means to perceive. You can discern text if it is presented (visually or auditorily, but you can't discern with text. The original if I remember correctly was "The command or outcome can be described in words". Hope this helps Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. > -----Original Message----- > From: w3c-wai-gl-request@w3.org > [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Bailey, Bruce > Sent: Monday, March 05, 2007 7:32 AM > To: WCAG > Subject: Not described in words > > > On the last call I expressed a concern that there is a gap > between WCAG 2.0 SC 2.1.1 [1] and Section 508 1194.21(a) [2] > because there are significant on-screen activities which > cannot be "discerned textually" but still do not require > "time-dependent analog input". There was an action item to > work on the definition of the latter [3], so any perceived > gap will probably narrow, but this difference is not expected > to be entirely eliminated. > > The following examples are off the top of my head and may > reflect an imperfect understanding of one or both terms. For > some, but not all, an alternative keyboard-oriented > equivalent may be quite reasonable for a visually-oriented > person who cannot use a mouse. For others, the > "time-dependent" aspect is only true if real world > productivity is considered. For all of these, I cannot > imagine how to make them actually useable for someone who is > blind. I am at a loss for suggesting verbiage that splits > the gap, but having gotten used to "discerned textually" over > the last several years, I favor that term and I am quite > comfortable that it is testable. > > Examples of activities that are not textually discernable but > are digital and/or time-independent: > > 1. Centering a map on a particular point so that other > features of interest are included in the view, or to correct > the default positioning returned for a street address. > > 2. Cropping a photograph so that it is center on the subject > or satisfies other criteria (like canvas size). > > 3. Adjusting the color balance, white point, or applying > other variable effects to a photograph. > > 4. Identifying pupils in a photograph so that red-eye > correction can be applied. > > 5. Assembling a puzzle, especially if the pieces can be > rotated and are of odd sizes (so that any underlying grid > arrangement is not obvious). > > 6. A simple paint program. > > 7. A complex vector drawing application. (AutoCAD, as but > one example in this genre, has amazing keyboard > accessibility, but selecting objects without using a mouse > equivalent remains tedious to the point of impracticality.) > > 8. A data visualization program that lets one manipulate data > points in a cube as a means to facilitate pattern recognition. > > My questions: > Can people think of other good examples that fall in this gap? > Is there really a gap? > Does it mater if there is? > > Thanks! Excepts from references follow. > > [1] > http://www.w3.org/WAI/GL/WCAG20/#keyboard-operation-keyboard-operable > All functionality of the content is operable through a > keyboard interface without requiring specific timings for > individual keystrokes, except where the underlying task > requires time-dependent analog input. [Level 1] > > [2] http://www.access-board.gov/sec508/standards.htm#Subpart_b > When software is designed to run on a system that has a > keyboard, product functions shall be executable from a > keyboard where the function itself or the result of > performing a function can be discerned textually. > > [3] http://www.w3.org/WAI/GL/WCAG20/#analog-tim-dep-inputdef > input whose result is different depending on the rate of the > analog movement (such as when line width varies with pen > speed or pressure). > Note: Most actions carried out by a pointing device > can also be done from the keyboard (for example, clicking, > selecting, moving, sizing). However, there is a small class > of input that is done with a pointing device that cannot be > done from the keyboard in any known fashion. This type of > input can be best characterized by the fact that the outcome > can only be achieved by moving the pointer in a smooth > fashion at a certain rate. For example, in a watercolor > program stroke width and transparency may depend on the rate > of movement (and/or pressure) of a "brush." Another example > would be a real-time helicopter flight simulator. > >
Received on Monday, 5 March 2007 14:14:10 UTC