Thread Subject: Re: Accessible document encodingscheme requirements

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: Sean Hayes
Date: Wed, Feb 28 2007 10:10 AM

I agree, lets keep provisions which talk about operation of content in the web/software clauses. Lets keep the content provisons specific to the issue of binding in the information required to support the software provions once the content is received and rendered.


Sean Hayes
Standards and Policy Team
Accessible Technology Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 27 February 2007 10:20
To: TEITAC Web/Software Subcommittee
Cc: Peterson, Bill; Myers, James <CTR>
Subject: Re: [teitac-websoftware] Accessible document encodingscheme requirements

Hi Allen,

It seems odd to try to address keyboard navigation/manipulation of content via language that starts with content encoding schemes. Perhaps if we started the sentence/paragraph talking about content viewers & content editors/creators, things would feel more comfortable.

In fact, I wonder if we can't just have a sentence that points folks back at the general software guidelines - that the process of content viewing/editing must likewise meet all of the other software guidelines
- must reflect color/contrast settings of desktop, must be 100% keyboard operable, etc.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> 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