Thread Subject: Group A: 21(a) keyboard operation

Return to this mailing list's archives

From: Andi Snow-Weaver
Date: Thu, Oct 19 2006 9:05 AM
Subject: Group A: 21(a) keyboard operation

Starting off the discussion on Group A items with 21 (a).

Current 508 wording:

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.

As Jonathon pointed out on the wiki, there is no 508 provision for keyboard
operation for web content. And he also comments that 508 seems to imply
that this is only for people with visual impairments because it is only
required "where the function itself or the result of performing a function
can be discerned textually."

Thinking about harmonization, I looked at both ISO 9241 part 171 and WCAG
2.0:

ISO: Unless the task requires time-dependent analogue input, software shall
provide users with the option to carry out all tasks using only non-time
dependent (or keyboard equivalent) input.

WCAG 2.0 Last Call Draft: All functionality of the content is operable in a
non-time-dependent manner through a keyboard interface, except where the
task requires analog, time-dependent input.

[WCAG 2.0 Editor's Draft: All functionality of the content is operable
through a keyboard interface without requiring specific timings for
individual keystrokes, except where the underlying task requires analog,
time-dependent input.]

Both of these seem to be a higher bar than 508. The ISO spec provides an
example of time dependent analog function that would not have to be
accessible. In this example of a water color painting application, the
color darkness is dependent on the amount of time the mouse pointer spends
positioned at a location. So the drawing functions of the application would
have to be keyboard accessible but this one time-dependent analog function
would not.

Andi

From: Peter Korn
Date: Thu, Oct 19 2006 10:35 AM
Subject: Re: Group A: 21(a) keyboard operation

Hi Andi, gang,
> Starting off the discussion on Group A items with 21 (a).
>
> Current 508 wording:
>
> 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.
>
> As Jonathon pointed out on the wiki, there is no 508 provision for keyboard
> operation for web content. And he also comments that 508 seems to imply
> that this is only for people with visual impairments because it is only
> required "where the function itself or the result of performing a function
> can be discerned textually."

I like my understanding of Gregg Vanderheiden's notion of "discernable
textually" - can you precisely describe in text the thing on the
screen. By that definition, a rectangle is "discernable textually"
because I can tell you that it is so many pixels tall & wide, and and
such and such location on the screen (including telling you its position
relative to other objects). I cannot discern textually a photograph
(which is one reason we have ALT text).

With that definition, then I should provide keyboard access to the tool
that allows me to place a rectangle on the screen in a CAD package (and
to manipulate it), but I do not need to provide keyboard access to the
tool that paints pictures on the screen.

By the way, this is essentially how we interpret this standard at Sun.


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Jonathan Avila
Date: Thu, Oct 19 2006 10:40 AM
Subject: Re: Group A: 21(a) keyboard operation

[peter korn wrote] //With that definition, then I should provide keyboard
access to the tool that allows me to place a rectangle on the screen in a
CAD package (and to manipulate it), but I do not need to provide keyboard
access to the tool that paints pictures on the screen. //

I believe there should be keyboard access to allow me to draw with a
pen/pencil on screen that allows me to draw in freeform a line vertically,
horizontally, and diagonally (not the same as a line tool). The actual
shape I come up with my not be discernable textually but I should have the
right to draw this shape if I'm can't use the mouse. In fact many drawing
programs already have keyboard commands in them to help user keep straight
lines, this concept just need to be extended to actually drawing with
pencil, pen, or even a spray can.

Jonathan

From: Peter Korn
Date: Thu, Oct 19 2006 11:10 AM
Subject: Re: Group A: 21(a) keyboard operation

Hi Jonathan,
> [peter korn wrote] //With that definition, then I should provide keyboard
> access to the tool that allows me to place a rectangle on the screen in a
> CAD package (and to manipulate it), but I do not need to provide keyboard
> access to the tool that paints pictures on the screen. //
>
> I believe there should be keyboard access to allow me to draw with a
> pen/pencil on screen that allows me to draw in freeform a line vertically,
> horizontally, and diagonally (not the same as a line tool). The actual
> shape I come up with my not be discernable textually but I should have the
> right to draw this shape if I'm can't use the mouse. In fact many drawing
> programs already have keyboard commands in them to help user keep straight
> lines, this concept just need to be extended to actually drawing with
> pencil, pen, or even a spray can.

Today all three desktop OSes (Windows, Mac, and UNIX) provide MouseKeys
functionality that allows any user who can press a single key on the
keypad to move the mouse. Is this reasonable and sufficient? Or should
we actually require that every software application provide mouse
movement alternatives for moving things like spray cans in painting
programs?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Jonathan Avila
Date: Thu, Oct 19 2006 11:30 AM
Subject: Re: Group A: 21(a) keyboard operation

Peter:

//Today all three desktop OSes (Windows, Mac, and UNIX) provide MouseKeys
functionality that allows any user who can press a single key on the keypad
to move the mouse. Is this reasonable and sufficient? Or should we
actually require that every software application provide mouse movement
alternatives for moving things like spray cans in painting programs?//

Personally in Windows I find it impossible to turn on shift w/ sticky keys
(for drawing a horizontal line in Paint), pressing numpad 5 to left click
and then press an arrow key to move in a direction. Perhaps I'm missing a
way to lock the left button. My point being though, it can be difficult to
do this and we don't know if all Operating systems have equivalent mouse key
functionality.

Jonathan

From: Luke Kowalski
Date: Thu, Oct 19 2006 11:45 AM
Subject: Re: Group A: 21(a) keyboard operation

[Peter korn wrote] Today all three desktop OSes (Windows, Mac, and UNIX) provide MouseKeys functionality that allows any user who can press a single key on the keypad to move the mouse. Is this reasonable and sufficient? Or should we actually require that every software application provide mouse movement alternatives for moving things like spray cans in painting programs?

--------------------------

I would like to second Peter's comment about deferring this to the OS layer. Overriding standard mouse control at the OS level with different/local app settings would prob be in conflict with ISO and WCAG points about not breaking interop. Besides...Consistency issues would surface shortly if this were up to each individual authoring app. If there are issues with mousekyes not working in a particular Linux, Windows, or Mac OS, it is probably a separate thing to consider.
The point made earlier about the shapes drawn not being discernible by the reader is also something to mull over as a factor.

luke kowalski, CPE
Corporate UI Architect
http://ui.oracle.com
Redwood Shores, CA 94065
650 506 1227

From: Jonathan Avila
Date: Thu, Oct 19 2006 12:35 PM
Subject: Re: Group A: 21(a) keyboard operation

Luke,
//I would like to second Peter's comment about deferring this to the OS
layer. Overriding standard mouse control at the OS level with
different/local app settings would prob be in conflict with ISO and WCAG
points about not breaking interop. Besides...Consistency issues would
surface shortly if this were up to each individual authoring app. If there
are issues with mousekyes not working in a particular Linux, Windows, or Mac
OS, it is probably a separate thing to consider.
The point made earlier about the shapes drawn not being discernible by the
reader is also something to mull over as a factor. //
----

I wasn't in any way suggesting that software move the mouse pointer or
provide keys to move the mouse pointer. I was instead suggesting that all
mouse operations be supplemented by keyboard actions. Others have agreed
that having MouseKeys in the OS shouldn't be an OS requirement. If it is
not an OS requirement and not a software requirement then a user will then
need to bring an AT into the mix.

Jonathan

From: Barrett, Don
Date: Thu, Oct 19 2006 12:55 PM
Subject: Re: Group A: 21(a) keyboard operation

" [Peter korn wrote] Today all three desktop OSes (Windows,
" Mac, and UNIX) provide MouseKeys functionality that allows
" any user who can press a single key on the keypad to move the
" mouse. Is this reasonable and sufficient? Or should we
" actually require that every software application provide
" mouse movement alternatives for moving things like spray cans
" in painting programs?

To desire that a screen reader user be able to draw is beyond what 508
was meant to do. I don't know of one blind person in any government
agency who would ever use such a feature. Even the current standard
requiring that menu functions and other controls in software like
Illustrator or PhotoShop be accessible has never proven itself useful in
the performance of any job functions. However, I think the standard as
it now exists does what it is designed to do and that is provide
accessibility to that which is reasonably expected to be accessible and
that is textual information. Remember, these standards are not a wish
list for a perfect world; they help people get their jobs done on an
equal basis and drawing isn't part of that functionality for a blind
user.

From: Andi Snow-Weaver
Date: Thu, Oct 19 2006 1:05 PM
Subject: Re: Group A: 21(a) keyboard operation

<Don't comment>

To desire that a screen reader user be able to draw is beyond what 508
was meant to do. ... Remember, these standards are not a wish
list for a perfect world; they help people get their jobs done on an
equal basis and drawing isn't part of that functionality for a blind
user.

<end of Don's comment>

Don, I think the original point was that, while the 508 keyboard
requirement may be sufficient for blind users, it is not sufficient for
people who are not blind but cannot use a mouse. They have a need to be
able to do free form drawing.

Andi

From: Barrett, Don
Date: Thu, Oct 19 2006 1:10 PM
Subject: Re: Group A: 21(a) keyboard operation

Thanks; got it.

From: Victor Tsaran
Date: Thu, Oct 19 2006 2:25 PM
Subject: Re: Group A: 21(a) keyboard operation

> " [Peter korn wrote] Today all three desktop OSes (Windows,
> " Mac, and UNIX) provide MouseKeys functionality that allows
> " any user who can press a single key on the keypad to move
> the
> " mouse. Is this reasonable and sufficient? Or should we
> " actually require that every software application provide
> " mouse movement alternatives for moving things like spray
> cans

If operating system already provides such functionality, I'd say
we should not have software developers reinvent the same
behavior, rather, in my opinion, we should ask them to respect
operating system's built-in feature and either let users enable
it from inside the software in question.

From: Jonathan Avila
Date: Thu, Oct 19 2006 5:10 PM
Subject: Re: Group A: 21(a) keyboard operation

> " [Peter korn wrote] Today all three desktop OSes (Windows, " Mac, and
> UNIX) provide MouseKeys functionality that allows " any user who can
> press a single key on the keypad to move the " mouse. Is this
> reasonable and sufficient? Or should we " actually require that every
> software application provide " mouse movement alternatives for moving
> things like spray cans

"[victor wrote] If operating system already provides such functionality, I'd
say we should not "have software developers reinvent the same behavior,
rather, in my opinion, we should ask "them to respect operating system's
built-in feature and either let users enable it from "inside the software in
question.

With this line of reasoning software applications shouldn't need to put any
keyboard access in, because mouse keys are available and JAWS has the "JAWS
cursor".

Jonathan

From: Travis Roth
Date: Thu, Oct 19 2006 5:15 PM
Subject: Re: Group A: 21(a) keyboard operation

Don wrote:
"To desire that a screen reader user be able to draw is beyond what 508 was
meant to do."

Keyboard access is used by more users than just screen reader users. I
encourage consideration of all users.

Travis Roth
Production Manager
TecAccess, LLC
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
www.TecAccess.net
Experts in Section 508 Compliance & Accessibility

NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
have received this communication in error, please reply to the sender
indicating that fact and delete the copy you received. Thank you.

From: Travis Roth
Date: Thu, Oct 19 2006 5:20 PM
Subject: Re: Group A: 21(a) keyboard operation

> " [Peter korn wrote] Today all three desktop OSes (Windows, " Mac, and
> UNIX) provide MouseKeys functionality that allows " any user who can
> press a single key on the keypad to move the " mouse. Is this
> reasonable and sufficient? Or should we " actually require that every
> software application provide " mouse movement alternatives for moving
> things like spray cans

A level of effort to perform a task should be considered.
An example: If an OS provides a method to use the keyboard to move the
mouse, is it reasonable to ask that all keyboard users use this method to
move the mouse to perform common tasks such as opening a menu and making a
selection?
Depending on the mouse movement intervals allowed, this could be a time
consuming and extraneous task.

I do not think that the ability of the OS to provide keyboard replacement
for a pointing device should be the sole means to meeting a keyboard
accessibility requirement.

Travis Roth
Production Manager
TecAccess, LLC
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
www.TecAccess.net
Experts in Section 508 Compliance & Accessibility

NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
have
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. Thank you.

From: Barrett, Don
Date: Thu, Oct 19 2006 6:45 PM
Subject: Re: Group A: 21(a) keyboard operation

Yes, we need to differentiate between mouse-related cursor functionality
being available through an alternate method, and Windows control
navigation/activation via the keyboard.

Rather than changing Standard .21 A, perhaps we really need an
additional standard which specifically addresses alternate methods for
mouse-specific functionality such as drawing, dragging, etc. It seems
to me that these are two separate though related issues, and we might
consider an additional standard to cover them both.

From: Gani, Dewi
Date: Fri, Oct 20 2006 5:20 AM
Subject: Re: Group A: 21(a) keyboard operation OnBehalf of Dewi Gani

Jonathan's comment:
"Others have agreed that having MouseKeys in the OS shouldn't be an OS
requirement."

I think this statement is overgeneralized. According to ISO 9241-171
9.1.2: Platform software shall provide a keyboard alternative to
standard pointing devices that enables keyboard (or keyboard equivalent)
control of pointer movement and pointer button functions in parallel
with the standard pointing devices.

I agree with ISO 9241-171 9.1.2 that Platform software shall provide
this alternative. Thus, it is the requirement of the OS to provide such
a feature.


Best Regards,

Dewi Gani

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Jonathan Avila
Sent: Donnerstag, 19. Oktober 2006 20:31
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group A: 21(a) keyboard operation

Luke,
//I would like to second Peter's comment about deferring this to the OS
layer. Overriding standard mouse control at the OS level with
different/local app settings would prob be in conflict with ISO and WCAG
points about not breaking interop. Besides...Consistency issues would
surface shortly if this were up to each individual authoring app. If
there
are issues with mousekyes not working in a particular Linux, Windows, or
Mac
OS, it is probably a separate thing to consider.
The point made earlier about the shapes drawn not being discernible by
the
reader is also something to mull over as a factor. //
----

I wasn't in any way suggesting that software move the mouse pointer or
provide keys to move the mouse pointer. I was instead suggesting that
all
mouse operations be supplemented by keyboard actions. Others have
agreed
that having MouseKeys in the OS shouldn't be an OS requirement. If it
is
not an OS requirement and not a software requirement then a user will
then
need to bring an AT into the mix.

Jonathan

From: Gregg Vanderheiden
Date: Fri, Oct 20 2006 9:50 AM
Subject: Re: Group A: 21(a) keyboard operation

Just some thoughts..


MouseKeys should NOT be relied on for most keyboard input. But some things
cannot be done from a keyboard. To capture these 508 used to say 'where the
action or output can be described in a sentence'

Many people thought that meant you needed to build voice control into
programs. So in WCAG we have changed it to

" All functionality of the content is operable through a keyboard interface
without requiring specific timings for individual keystrokes, except where
the underlying task requires analog, time-dependent input."


MouseKeys would not qualify in the first part and the exception would not
cover simple line drawing where you use rubber band like drawing. Freehand
line drawing (where the line is the same no matter how slow or quickly it is
drawn) is an interesting case. It doesn't qualify for the exception, but
keyboard based drawing would be identical to pixel by pixel MouseKeys
movement. That is MouseKeys would appear to be identical to building a
pixel by pixel freehand drawing capability into a tool.


Gregg

-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
The Player for my DSS sound file is at http://tinyurl.com/dho6b


> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Thursday, October 19, 2006 12:08 PM
> To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group A: 21(a) keyboard operation
>
> Hi Jonathan,
> > [peter korn wrote] //With that definition, then I should provide
> > keyboard access to the tool that allows me to place a
> rectangle on the
> > screen in a CAD package (and to manipulate it), but I do
> not need to
> > provide keyboard access to the tool that paints pictures on the
> > screen. //
> >
> > I believe there should be keyboard access to allow me to
> draw with a
> > pen/pencil on screen that allows me to draw in freeform a line
> > vertically, horizontally, and diagonally (not the same as a line
> > tool). The actual shape I come up with my not be discernable
> > textually but I should have the right to draw this shape if
> I'm can't
> > use the mouse. In fact many drawing programs already have keyboard
> > commands in them to help user keep straight lines, this
> concept just
> > need to be extended to actually drawing with pencil, pen,
> or even a spray can.
>
> Today all three desktop OSes (Windows, Mac, and UNIX) provide
> MouseKeys functionality that allows any user who can press a
> single key on the keypad to move the mouse. Is this
> reasonable and sufficient? Or should we actually require
> that every software application provide mouse movement
> alternatives for moving things like spray cans in painting programs?
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>