Thread Subject: Appeal - Please change the subject line whensubject changes

Return to this mailing list's archives

From: Jim Thatcher
Date: Wed, Oct 11 2006 10:55 AM
Subject: Appeal - Please change the subject line whensubject changes

I hope everyone remembers to change the subject line on messages to this
list when the subject changes.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

-----Original Message-----
From: Barrett, Don [mailto: = EMAIL ADDRESS REMOVED = ] On
Behalf Of Barrett, Don
Sent: Wednesday, October 11, 2006 9:30 AM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: RE: [teitac-websoftware] TEITAC - Software andWeb:Meeting
tomorrowand co-chairs

Good thinking Jonathan. I actually am happy with whatever breakdown we use;
it's the chunking it down that really matters at this point so all are
focused in the same direction.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = on behalf of Jonathan
Avila
Sent: Wed 10/11/2006 9:21 AM
To: 'TEITAC Web/Software Subcommittee'
Cc:
Subject: Re: [teitac-websoftware] TEITAC - Software andWeb:Meeting
tomorrowand co-chairs

Peter,
1194.21C has a visual and programmatic component, perhaps it should be split
up into both categories. Another approach would be to break these items
into media types such as forms, tables, color, animation, and images.

Jonathan

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Tuesday, October 10, 2006 9:34 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] TEITAC - Software and Web:Meeting
tomorrowand co-chairs

Hi Don,

> One possible strategy for identifying issues might be to break up the
total of 28 standards into let's say four groups of seven and bring the
wisdom of the group to bear on each group of seven before moving on to the
next group. What I want to avoid are (just as an example) potentially 28
separate discussions resulting from people randomly bringing up various
aspects of acessibility related to each standard. Dividing them into groups
would force us all to focus, and would also ensure that those who were
expert in a given area could sit back and listen for one group, and really
chime in hard for another. Just a thought.

I think breaking them up into groups makes sense. However, I think there
are a number of related sets of standards, and rather than than having an
arbitrary grouping of "the first seven", "the second seven", etc., it would
make more sense to group similar with similar.

Looking through 1194.21 and 1194.22, I see two obvious sub-groupings:
standards relating to visual rendering, and standards relating to
programmatic exposure of information (with a third, catch-all category).
See my categorization below. If we divided them up in this fashion (and
assuming we are in general agreement with where I've put things), we could
take them as groups of: 5 1194.21 visual standards, 2 1194.22 visual
standards, 5 1194.21 programmatic standards, 7 1194.22 programmatic
standards, 2 1194.21 misc. standards, and 7 1194.22 misc.
standards.

What do folks think about a strategy like that?


Standards relating to visual rendering (color, contrast, etc.):
--------------

[1194.21]
(g) Applications shall not override user selected contrast and color
selections and other individual display attributes.

(h) When animation is displayed, the information shall be displayable in at
least one non-animated presentation mode at the option of the user.

(i) Color coding shall not be used as the only means of conveying
information, indicating an action, prompting a response, or distinguishing a
visual element.

(j) When a product permits a user to adjust color and contrast settings, a
variety of color selections capable of producing a range of contrast levels
shall be provided.

(k) Software shall not use flashing or blinking text, objects, or other
elements having a flash or blink frequency greater than 2 Hz and lower than
55 Hz.

[1194.22]
(c) Web pages shall be designed so that all information conveyed with color
is also available without color, for example from context or markup.

(j) Pages shall be designed to avoid causing the screen to flicker with a
frequency greater than 2 Hz and lower than 55 Hz.



Standards relating to programmatic exposure of information:
----------

[1194.21]
(c) A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input
focus changes. The focus shall be programmatically exposed so that
assistive technology can track focus and focus changes.

(d) Sufficient information about a user interface element including the
identity, operation and state of the element shall be available to
assistive technology. When an image represents a program element, the
information conveyed by the image must also be available in text.

(e) When bitmap images are used to identify controls, status indicators,
or other programmatic elements, the meaning assigned to those images
shall be consistent throughout an application's performance.

(f) Textual information shall be provided through operating system
functions for displaying text. The minimum information that shall be
made available is text content, text input caret location, and text
attributes.

(l) When electronic forms are used, the form shall allow people using
assistive technology to access the information, field elements, and
functionality required for completion and submission of the form,
including all directions and cues.

[1194.22]
(a) A text equivalent for every non-text element shall be provided
(e.g., via "alt", "longdesc", or in element content).

(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for
data tables that have two or more logical levels of row or column headers.

(i) Frames shall be titled with text that facilitates frame
identification and navigation.

(l) When pages utilize scripting languages to display content, or to
create interface elements, the information provided by the script shall
be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other
application be present on the client system to interpret page content,
the page must provide a link to a plug-in or applet that complies with
§1194.21(a) through (l).

(n) When electronic forms are designed to be completed on-line, the form
shall allow people using assistive technology to access the information,
field elements, and functionality required for completion and submission
of the form, including all directions and cues.


Misc./other standards:
-----------

[1194.21]
(a) 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.

(b) Applications shall not disrupt or disable activated features of
other products that are identified as accessibility features, where
those features are developed and documented according to industry
standards. Applications also shall not disrupt or disable activated
features of any operating system that are identified as accessibility
features where the application programming interface for those
accessibility features has been documented by the manufacturer of the
operating system and is available to the product developer.

[1194.22]
(b) Equivalent alternatives for any multimedia presentation shall be
synchronized with the presentation.

(d) Documents shall be organized so they are readable without requiring
an associated style sheet.

(e) Redundant text links shall be provided for each active region of a
server-side image map.

(f) Client-side image maps shall be provided instead of server-side
image maps except where the regions cannot be defined with an available
geometric shape.

(k) A text-only page, with equivalent information or functionality,
shall be provided to make a web site comply with the provisions of this
part, when compliance cannot be accomplished in any other way. The
content of the text-only page shall be updated whenever the primary page
changes.

(o) A method shall be provided that permits users to skip repetitive
navigation links.

(p) When a timed response is required, the user shall be alerted and
given sufficient time to indicate more time is required.


Regards,

Peter Korn,
Accessibility Architect,
Sun Microsystems, Inc.


>
> Don Barrett
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = on behalf of Andi
Snow-Weaver
> Sent: Tue 10/10/2006 11:24 AM
> To: = EMAIL ADDRESS REMOVED =
> Cc: = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; Shannon Rapuano; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; Richard Schwerdtfeger;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED = ;
= EMAIL ADDRESS REMOVED = ; = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] TEITAC - Software and Web: Meeting
tomorrowand co-chairs
>
>
> All,
>
> Reluctantly, Curtis and I have agreed that it is best to cancel tomorrow's
> teleconference. We are still working out tools to manage the
teleconference
> speaker queue which is an absolute necessity for our subcommittee of about
> 50 participants.
>
> I think we are closed on Curtis and myself as subcommittee co-chairs. Not
> everyone has registered a position but there have been no negative votes
> and no other volunteers. So, unless there are objections raised by the end
> of this week, I will send this recommendation to Jim and Mike on Monday
for
> their approval.
>
> Curtis and I think that the next order of business is to define the
> workscope and goals for this subcommittee. From the TEITAC meeting and
> Gregg's note to the General issues subcommittee, we are charged with:
>
> Reviewing the provisions (in our case, this would be 1194.21
Software
> applications and operating systems and 1194.22 Web-based intranet and
> Internet information and applications):
> 1) Looking for gaps
> 2) Looking for problems
> 3) Considering the themes throughout
>
> If you have further thoughts on this, please send them to
> = EMAIL ADDRESS REMOVED = . I'll start a draft on our web page
> tomorrow.
>
> Andi
>
>

From: Jared Smith
Date: Wed, Oct 11 2006 11:00 AM
Subject: Re: Appeal - Please change the subject linewhen subject changes

On 10/11/06, Jim Thatcher wrote:
>
> I hope everyone remembers to change the subject line on messages to this
> list when the subject changes.


As well as trim irrelevant and redundant information from their messages.
Please only quote relevant portions of the message. This will ensure that
messages are tidy, easy-to-understand, and most of all, accessible. The list
archives can become quite unreadable if the previous 30 messages are all
included in the body.

Thanks!

Jared