Thread Subject: Re: Accessibledocument encodingschemerequirements

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Gregg Vanderheiden
Date: Tue, Feb 27 2007 9:00 AM

Alan,

If you use "OR" then you allow mouse only operation.

If you use AND then you require that everything done from a keyboard be
do-able from a non-keyboard input device.

We went round on this for extended periods of discussions in multiple groups
and it always came down to the 'all things operable from keyboard except if'
provision.

Once you have keyboard operation (actually 'keyboard interface' ) then you
can use speech, pointing device (on a pointing keyboard) and many other
forms. But it doesn't work the other way around.

We ALSO encourage other input but don't require it.

But OR doesn't work.

It always looks like there is something else -- or should be -- but it
always evaporates when examined closely.

That said, I'd be happy to take time on a call sometime to walk through this
and see if there is something the other groups all missed.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Monday, February 26, 2007 9:01 AM
> To: TEITAC Web/Software Subcommittee
> Cc: Peterson, Bill; Myers, James <CTR>
> Subject: Re: [teitac-websoftware] Accessible document
> encodingschemerequirements
>
> All:
> I concur with Peter.
>
> Regarding keyboard input, can anyone propose language that is
> sufficient to describe the requirement that the encoding
> format include non-input device specific functionality for
> any user-interaction elements encodable? The issue is
> complicated due to the user-agent/encoding scheme
> combination, and where the lines are.
>
> Maybe something such as:
>
> When an encoding scheme includes the capacity to present
> elements for user-interaction, a device independent
> interaction method shall be available which allows
> interactive elements to be used via a keyboard or other interface.
>
>
> Allen Hoffman -- 202-447-0303
> DHS Office on Accessible Systems & Technology
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Friday, February 23, 2007 8:45 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Accessible document
> encodingscheme requirements
>
> Hi Andi, Allen,
>
> This is a great list. I have just a few comments on some of
> the items, which I am placing in-line for context.
>
> > Proposed CFR1194.27
> >
> > (a) An encoding mechanism shall be provided to associate non-text
> > elements with textual descriptions displayable by a user-agent.
> >
>
> We need to be clear on whether this applies to all non-text
> elements, or only certain elements (or perhaps define
> "element"). For example, is it necessary to be able to
> encode a text description for each and every line that makes
> up spokes of a wheel graphic that is embedded within a text
> document advertisement for bicycle wheels? Or only the group
> of non-text elements that make up the graphic?
>
> > ...
> >
> > (f) An encoding mechanism shall be provided to associated row and
> > column headers with other table cells, displayable by a user-agent.
> >
>
> I think you mean "associate" here, vs. "associated".
>
>
> Separate from those two points, should there be any statement
> about keyboard navigation to content? Imagine for example
> the objects that make up a slide presentation - the header,
> the body text, multiple images in the body of the slide, etc.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University