Thread Subject: Re: Hardware Labels/LCD Windows

Return to this mailing list's archives

From: Jim Tobias
Date: Fri, Jun 15 2007 12:35 PM
Subject: Re: Hardware Labels/LCD Windows

For those not on the call, this issue came up regarding small LCDs on
copiers, printers, etc., used to inform the user about machine status,
collating options, etc. They are typically monochrome backlit LCDs.

First, any provision for this would require a new subsection in the Hardware
section; I propose "2.4 If the product has visual output". Second, here is
some language for a provision:
"All electronic visual displays must have a contrast ratio of at least N:1,
as a default or as adjusted by the user."

Note that "N:1" is the placeholder in the software/web/content provisions.




***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias




_____

From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, June 15, 2007 1:53 PM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: [teitac-websoftware] Hardware Labels/LCD Windows



During today's Hardware teleconference I brought up that for many low vision
users the ability to read the prompts, operation touch controls for features
like number of copies, simplex/duplex, and collating, and warning messages
is very difficult because the characters are small and they lack contrast
and brightness.



As part of the discussion it was asked if there should be a provision in
Section 508 to address the LCD window that used to display information or
feature controls. Another question was raised regarding which subcommittee
had jurisdiction of this provision-Hardware or Web/Software.



I would propose that language be crafted that provides a minimum level of
contrast and brightness so that people with low vision would be able to
utilize products with this type of display effectively.







Tom Brett

From: Jim Tobias
Date: Fri, Jun 15 2007 12:40 PM
Subject: Re: Hardware Labels/LCD Windows

For those not on the call, this issue came up regarding small LCDs on
copiers, printers, etc., used to inform the user about machine status,
collating options, etc. They are typically monochrome backlit LCDs.

First, any provision for this would require a new subsection in the Hardware
section; I propose "2.4 If the product has visual output". Second, here is
some language for a provision:
"All electronic visual displays must have a contrast ratio of at least N:1,
as a default or as adjusted by the user."

Note that "N:1" is the placeholder in the software/web/content provisions.




***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias




_____

From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, June 15, 2007 1:53 PM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: [teitac-websoftware] Hardware Labels/LCD Windows



During today's Hardware teleconference I brought up that for many low vision
users the ability to read the prompts, operation touch controls for features
like number of copies, simplex/duplex, and collating, and warning messages
is very difficult because the characters are small and they lack contrast
and brightness.



As part of the discussion it was asked if there should be a provision in
Section 508 to address the LCD window that used to display information or
feature controls. Another question was raised regarding which subcommittee
had jurisdiction of this provision-Hardware or Web/Software.



I would propose that language be crafted that provides a minimum level of
contrast and brightness so that people with low vision would be able to
utilize products with this type of display effectively.







Tom Brett

From: David Poehlman
Date: Fri, Jun 15 2007 1:10 PM
Subject: Re: Hardware Labels/LCD Windows

If I cannot see the display, how can I adjust it?

----- Original Message -----
From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Friday, June 15, 2007 2:32 PM
Subject: Re: [teitac-websoftware] Hardware Labels/LCD Windows


For those not on the call, this issue came up regarding small LCDs on
copiers, printers, etc., used to inform the user about machine status,
collating options, etc. They are typically monochrome backlit LCDs.

First, any provision for this would require a new subsection in the Hardware
section; I propose "2.4 If the product has visual output". Second, here is
some language for a provision:
"All electronic visual displays must have a contrast ratio of at least N:1,
as a default or as adjusted by the user."

Note that "N:1" is the placeholder in the software/web/content provisions.




***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias




_____

From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, June 15, 2007 1:53 PM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: [teitac-websoftware] Hardware Labels/LCD Windows



During today's Hardware teleconference I brought up that for many low vision
users the ability to read the prompts, operation touch controls for features
like number of copies, simplex/duplex, and collating, and warning messages
is very difficult because the characters are small and they lack contrast
and brightness.



As part of the discussion it was asked if there should be a provision in
Section 508 to address the LCD window that used to display information or
feature controls. Another question was raised regarding which subcommittee
had jurisdiction of this provision-Hardware or Web/Software.



I would propose that language be crafted that provides a minimum level of
contrast and brightness so that people with low vision would be able to
utilize products with this type of display effectively.







Tom Brett








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

From: Hoffman, Allen
Date: Mon, Jun 18 2007 1:45 PM
Subject: Re:

All:

I have been wrestling a proposal in to shape for a while now but am
really running out of time.

Let me describe what I'm after, describe the three ways I think we can
get there, and ask for your help in planning the best way to present
recommendations for the final 06/30 draft TEITAC.


When the TEITAC was initiated by the US Access-Board the Board included
a theme regarding applicability of the EIT accessibility standards to
electronic content as a whole. This applicability question has been a
continuing challenge for Federal and industry partners alike since the
standards were adopted. Often CFR1194.22(a-p) standards are applied to
electronic content encoded in other than HTML or "mark up" based
formats, and because of this they often are not easily scoped to all
format situations. For example in CFR1194.22(e), "server-side image
maps shall not be used accept where geometric shapes can not be
represented", is specifically connected to the <ismap> HTML tag of that
content format. When it is applied to other formats, such as the widely
used Microsoft Office format, it is just not easily transferable, and
causes confusion and a wide variety of requirements to be presented both
to industry and Federal employees alike. Questions arose about if
electronic content NOT transported by the HTTP or HTTPS protocols, for
the "web", were covered by the standards. Even an HTML document sent
via email might not be covered in the email, but may be if placed on a
web site and accessed as part of a web-based email service.

To address this problem several additions to the standards are needed.
First, minimum accessibility standards for formats are required to
eliminate formats which by their inability to store sufficient
information AND accessibility attributes can not be authored to be
accessible. Second, either the standards for web must be broadened to
more directly address a wider set of electronic content formats, or a
broadly scoped standard must be developed to require that the
accessibility attributes of a format are to be used when available, and
that accessible formats MUST be used. Broadening the existing
CFR1194.22 standards may reduce their effectiveness in addressing this
large area of electronic content, so could be a step backwards,
Broadening the CFR1194.22 "web" standards would also present multiple
standards for web developers which goes against the general theme of
harmonizing with the W3C WAI and other standards bodies. Developing an
adequately scoped standard that is effective in directing that
electronic content is produced in accessible formats and with sufficient
accessibility attributes is also a challenge but may be the most direct
path to fully clarifying how accessibility is to be achieved for
electronic content. Third, if the standards are re-organized so that
standards for electronic content are provided with HTML and other
mark-up based formats as a subset of those standards, this applicability
challenge can be addressed in a logical, and effective fashion.

I have been working to pull together all the standards that would apply
to "content" as a whole, and then insert as subsets the standards that
fall for web-only, software only, etc. I'm just having a slow go of it
with the WIKI and a screen reader.

i propose a provision, possibly in information/documentation/support or
at the top of the proposed content format accessibility stqandards
section that says:

Electronic content shall be provided in at least one format that meets
minimum format accessibility standards, and shall be authored to be
accessible using the accessibility functionalities of that format, and
MUST meet technical provisions (list), and functional performance
criteria from subpart C.

The rationale for such a statement is that while we may include format
standards, right now "content" standards are primarily for the web.
Some have mentioned that the "web" standards are not specifically for
the web, but they have tradditionally been interpreted this way, and
their current title includes intra and internet information and
applications. The web standards as they are known are probably the most
successful set of standards of the current set, so broadening them to
address content in general may not get us what we want.

Below please find the draft authoring tool standards which are part of
this equation. I think several of these should and can be comtined, but
the point for these is that authors need consistent help and guidance to
allow them to produce accessible content, or content which meets
accessibility standards via the accessibility functionalities the
storeage format includes.

>
>1. Authoring tools must have the ability to produce content which
>passes the electronic content provisions.
Note: we have inter/intranet information and application provisions only
now.
>
>2. Authoring tools must, except by explicit user action, preserve
>accessibility information necessary for meeting the electronic content
>provisions.
>
>3. Authoring tools must allow the author to augment
>automatically-generated content with accessibility information.
>
>4. For authoring tools with a user interface, authoring tools must
>provide a mode which prompts authors to create accessible content.
>
>5. For authoring tools with a user interface, authoring tools must
>provide a mode which assists authors in checking for accessibility
problems.
>
>6. Authoring tools, when providing templates or other pre-authored
>content, should provide templates that facilitate production of
>accessible content, and pre-authored content that is accessible.
>
>7. Authoring tools should give prominence to the most accessible
>authoring action for achieving an authoring outcome.
>
I think 4, 5, and 7 can be integrated successfully without losing
meaning, but we can discuss the requirements individually until we come
to final consensus.

So, three ways I propose we solve this are:

1. Add the proposed provision above to information documentation and
support to say electronic content must be provided in at least one
accessible format, and must be authored to meet technical standards and
functional performande criteria, using the available accessibility
functionalities of the format. Include minimum format accessibility
standards.

2. Broaden the provisions in current CFR 1194.22 so they can be
applicable to "any" electronic content that includes specific kinds of
functionality such as tables, frmaes, images, etc. include minimum
format accessibility standards. No need to explicitly require
electronic meet broadened cfr1194.22 standards as they are broad enough
now. Note, this approach won't say that such content must be in an
accessible format however.

3. (the hard way). For each minimum accessibility format standard,
include language to say that electronic content that includes that
functionality and attributes must meet the standard. Basically wrap it
all in one set. hard to do effectively.

From: Katie Haritos-Shea
Date: Mon, Jun 18 2007 1:48 PM
Subject: Re:

Allen,

I think that this is a very important (perhaps *most* important) provision to be added.

I see the dilemma. Hmmm....

First thought, in answer to your question on where/how to insert it is, certainly choice A or B. It needs to be an overarching requirement. Second thought, I lean towards B because I think that this is a Technical Requirement.

Katie Haritos-Shea

-----Original Message-----
>From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
>Sent: Jun 12, 2007 3:36 PM
>To: Katie Haritos-Shea < = EMAIL ADDRESS REMOVED = >, TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >
>Subject: RE: [teitac-content accessibility general
>
>All:
>
>I have been wrestling a proposal in to shape for a while now but am
>really running out of time.
>
>Let me describe what I'm after, describe the three ways I think we can
>get there, and ask for your help in planning the best way to present
>recommendations for the final 06/30 draft TEITAC.
>
>
>When the TEITAC was initiated by the US Access-Board the Board included
>a theme regarding applicability of the EIT accessibility standards to
>electronic content as a whole. This applicability question has been a
>continuing challenge for Federal and industry partners alike since the
>standards were adopted. Often CFR1194.22(a-p) standards are applied to
>electronic content encoded in other than HTML or "mark up" based
>formats, and because of this they often are not easily scoped to all
>format situations. For example in CFR1194.22(e), "server-side image
>maps shall not be used accept where geometric shapes can not be
>represented", is specifically connected to the <ismap> HTML tag of that
>content format. When it is applied to other formats, such as the widely
>used Microsoft Office format, it is just not easily transferable, and
>causes confusion and a wide variety of requirements to be presented both
>to industry and Federal employees alike. Questions arose about if
>electronic content NOT transported by the HTTP or HTTPS protocols, for
>the "web", were covered by the standards. Even an HTML document sent
>via email might not be covered in the email, but may be if placed on a
>web site and accessed as part of a web-based email service.
>
>To address this problem several additions to the standards are needed.
>First, minimum accessibility standards for formats are required to
>eliminate formats which by their inability to store sufficient
>information AND accessibility attributes can not be authored to be
>accessible. Second, either the standards for web must be broadened to
>more directly address a wider set of electronic content formats, or a
>broadly scoped standard must be developed to require that the
>accessibility attributes of a format are to be used when available, and
>that accessible formats MUST be used. Broadening the existing
>CFR1194.22 standards may reduce their effectiveness in addressing this
>large area of electronic content, so could be a step backwards,
>Broadening the CFR1194.22 "web" standards would also present multiple
>standards for web developers which goes against the general theme of
>harmonizing with the W3C WAI and other standards bodies. Developing an
>adequately scoped standard that is effective in directing that
>electronic content is produced in accessible formats and with sufficient
>accessibility attributes is also a challenge but may be the most direct
>path to fully clarifying how accessibility is to be achieved for
>electronic content. Third, if the standards are re-organized so that
>standards for electronic content are provided with HTML and other
>mark-up based formats as a subset of those standards, this applicability
>challenge can be addressed in a logical, and effective fashion.
>
>I have been working to pull together all the standards that would apply
>to "content" as a whole, and then insert as subsets the standards that
>fall for web-only, software only, etc. I'm just having a slow go of it
>with the WIKI and a screen reader.
>
>i propose a provision, possibly in information/documentation/support or
>at the top of the proposed content format accessibility stqandards
>section that says:
>
>Electronic content shall be provided in at least one format that meets
>minimum format accessibility standards, and shall be authored to be
>accessible using the accessibility functionalities of that format, and
>MUST meet technical provisions (list), and functional performance
>criteria from subpart C.
>
>The rationale for such a statement is that while we may include format
>standards, right now "content" standards are primarily for the web.
>Some have mentioned that the "web" standards are not specifically for
>the web, but they have tradditionally been interpreted this way, and
>their current title includes intra and internet information and
>applications. The web standards as they are known are probably the most
>successful set of standards of the current set, so broadening them to
>address content in general may not get us what we want.
>
>Below please find the draft authoring tool standards which are part of
>this equation. I think several of these should and can be comtined, but
>the point for these is that authors need consistent help and guidance to
>allow them to produce accessible content, or content which meets
>accessibility standards via the accessibility functionalities the
>storeage format includes.
>
>>
>>1. Authoring tools must have the ability to produce content which
>>passes the electronic content provisions.
>Note: we have inter/intranet information and application provisions only
>now.
>>
>>2. Authoring tools must, except by explicit user action, preserve
>>accessibility information necessary for meeting the electronic content
>>provisions.
>>
>>3. Authoring tools must allow the author to augment
>>automatically-generated content with accessibility information.
>>
>>4. For authoring tools with a user interface, authoring tools must
>>provide a mode which prompts authors to create accessible content.
>>
>>5. For authoring tools with a user interface, authoring tools must
>>provide a mode which assists authors in checking for accessibility
>problems.
>>
>>6. Authoring tools, when providing templates or other pre-authored
>>content, should provide templates that facilitate production of
>>accessible content, and pre-authored content that is accessible.
>>
>>7. Authoring tools should give prominence to the most accessible
>>authoring action for achieving an authoring outcome.
>>
>I think 4, 5, and 7 can be integrated successfully without losing
>meaning, but we can discuss the requirements individually until we come
>to final consensus.
>
>So, three ways I propose we solve this are:
>
>1. Add the proposed provision above to information documentation and
>support to say electronic content must be provided in at least one
>accessible format, and must be authored to meet technical standards and
>functional performande criteria, using the available accessibility
>functionalities of the format. Include minimum format accessibility
>standards.
>
>2. Broaden the provisions in current CFR 1194.22 so they can be
>applicable to "any" electronic content that includes specific kinds of
>functionality such as tables, frmaes, images, etc. include minimum
>format accessibility standards. No need to explicitly require
>electronic meet broadened cfr1194.22 standards as they are broad enough
>now. Note, this approach won't say that such content must be in an
>accessible format however.
>
>3. (the hard way). For each minimum accessibility format standard,
>include language to say that electronic content that includes that
>functionality and attributes must meet the standard. Basically wrap it
>all in one set. hard to do effectively.
>
>
>
>
>
>


* katie *

Katie Haritos-Shea
Section 508 Technical Policy Analyst

703-371-5545

People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......

From: Tom Brett
Date: Mon, Jun 18 2007 1:50 PM
Subject: Hardware Labels/LCD Windows

During today's Hardware teleconference I brought up that for many low vision
users the ability to read the prompts, operation touch controls for features
like number of copies, simplex/duplex, and collating, and warning messages
is very difficult because the characters are small and they lack contrast
and brightness.



As part of the discussion it was asked if there should be a provision in
Section 508 to address the LCD window that used to display information or
feature controls. Another question was raised regarding which subcommittee
had jurisdiction of this provision-Hardware or Web/Software.



I would propose that language be crafted that provides a minimum level of
contrast and brightness so that people with low vision would be able to
utilize products with this type of display effectively.







Tom Brett

From: David Poehlman
Date: Mon, Jun 18 2007 1:50 PM
Subject: Re: Hardware Labels/LCD Windows

If I cannot see the display, how can I adjust it?

----- Original Message -----
From: "Jim Tobias" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Friday, June 15, 2007 2:32 PM
Subject: Re: [teitac-websoftware] Hardware Labels/LCD Windows


For those not on the call, this issue came up regarding small LCDs on
copiers, printers, etc., used to inform the user about machine status,
collating options, etc. They are typically monochrome backlit LCDs.

First, any provision for this would require a new subsection in the Hardware
section; I propose "2.4 If the product has visual output". Second, here is
some language for a provision:
"All electronic visual displays must have a contrast ratio of at least N:1,
as a default or as adjusted by the user."

Note that "N:1" is the placeholder in the software/web/content provisions.




***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias




_____

From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, June 15, 2007 1:53 PM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: [teitac-websoftware] Hardware Labels/LCD Windows



During today's Hardware teleconference I brought up that for many low vision
users the ability to read the prompts, operation touch controls for features
like number of copies, simplex/duplex, and collating, and warning messages
is very difficult because the characters are small and they lack contrast
and brightness.



As part of the discussion it was asked if there should be a provision in
Section 508 to address the LCD window that used to display information or
feature controls. Another question was raised regarding which subcommittee
had jurisdiction of this provision-Hardware or Web/Software.



I would propose that language be crafted that provides a minimum level of
contrast and brightness so that people with low vision would be able to
utilize products with this type of display effectively.







Tom Brett








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

From: Gregg Vanderheiden
Date: Mon, Jun 18 2007 1:50 PM
Subject: Re: Hardware Labels/LCD Windows

Looks good.



The Contrast in SoftwareWeb group (Web) is similar and harmonized with
WCAG. The new text there is:


Text <http://www.w3.org/TR/2007/WD-WCAG20-20070517/#textdef> (and images of
text) have a contrast
<http://www.w3.org/TR/2007/WD-WCAG20-20070517/#contrast-ratiodef> ratio of
at least 5:1, except if the text is pure decoration
<http://www.w3.org/TR/2007/WD-WCAG20-20070517/#puredecdef> . Larger-scale
<http://www.w3.org/TR/2007/WD-WCAG20-20070517/#larger-scaledef> text or
images of text can have a contrast ratio of 3:1.










Do we want to use the same wording? (that one is limited to text since
contrast will vary all over the place for pictures. )



Another thing occurs to me. The contrast of the text on the screen would
be a function of hardware and software. This would need to cover both the
simple B/W displays and the increasingly more common graphic and color
displays. Even the B/W displays are using grayscale. I wonder if this
should be in the GENERAL TECHNICAL REQUIREMENT section ??



And another - don't we need a contrast for labels too (not just displayed
info)?

Again use same?




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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Friday, June 15, 2007 1:33 PM
To: 'TEITAC Web/Software Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Hardware Labels/LCD Windows

For those not on the call, this issue came up regarding small LCDs on
copiers, printers, etc., used to inform the user about machine status,
collating options, etc. They are typically monochrome backlit LCDs.



First, any provision for this would require a new subsection in the Hardware
section; I propose "2.4 If the product has visual output". Second, here is
some language for a provision:

"All electronic visual displays must have a contrast ratio of at least N:1,
as a default or as adjusted by the user."



Note that "N:1" is the placeholder in the software/web/content provisions.







***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias






_____


From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, June 15, 2007 1:53 PM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: [teitac-websoftware] Hardware Labels/LCD Windows

During today's Hardware teleconference I brought up that for many low vision
users the ability to read the prompts, operation touch controls for features
like number of copies, simplex/duplex, and collating, and warning messages
is very difficult because the characters are small and they lack contrast
and brightness.



As part of the discussion it was asked if there should be a provision in
Section 508 to address the LCD window that used to display information or
feature controls. Another question was raised regarding which subcommittee
had jurisdiction of this provision-Hardware or Web/Software.



I would propose that language be crafted that provides a minimum level of
contrast and brightness so that people with low vision would be able to
utilize products with this type of display effectively.







Tom Brett

From: Gregg Vanderheiden
Date: Mon, Jun 18 2007 1:50 PM
Subject: Re: Hardware Labels/LCD Windows

Looks good.



The Contrast in SoftwareWeb group (Web) is similar and harmonized with
WCAG. The new text there is:


Text <http://www.w3.org/TR/2007/WD-WCAG20-20070517/#textdef> (and images of
text) have a contrast
<http://www.w3.org/TR/2007/WD-WCAG20-20070517/#contrast-ratiodef> ratio of
at least 5:1, except if the text is pure decoration
<http://www.w3.org/TR/2007/WD-WCAG20-20070517/#puredecdef> . Larger-scale
<http://www.w3.org/TR/2007/WD-WCAG20-20070517/#larger-scaledef> text or
images of text can have a contrast ratio of 3:1.










Do we want to use the same wording? (that one is limited to text since
contrast will vary all over the place for pictures. )



Another thing occurs to me. The contrast of the text on the screen would
be a function of hardware and software. This would need to cover both the
simple B/W displays and the increasingly more common graphic and color
displays. Even the B/W displays are using grayscale. I wonder if this
should be in the GENERAL TECHNICAL REQUIREMENT section ??



And another - don't we need a contrast for labels too (not just displayed
info)?

Again use same?




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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Friday, June 15, 2007 1:33 PM
To: 'TEITAC Web/Software Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-websoftware] Hardware Labels/LCD Windows

For those not on the call, this issue came up regarding small LCDs on
copiers, printers, etc., used to inform the user about machine status,
collating options, etc. They are typically monochrome backlit LCDs.



First, any provision for this would require a new subsection in the Hardware
section; I propose "2.4 If the product has visual output". Second, here is
some language for a provision:

"All electronic visual displays must have a contrast ratio of at least N:1,
as a default or as adjusted by the user."



Note that "N:1" is the placeholder in the software/web/content provisions.







***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias






_____


From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, June 15, 2007 1:53 PM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Web/Software Subcommittee
Subject: [teitac-websoftware] Hardware Labels/LCD Windows

During today's Hardware teleconference I brought up that for many low vision
users the ability to read the prompts, operation touch controls for features
like number of copies, simplex/duplex, and collating, and warning messages
is very difficult because the characters are small and they lack contrast
and brightness.



As part of the discussion it was asked if there should be a provision in
Section 508 to address the LCD window that used to display information or
feature controls. Another question was raised regarding which subcommittee
had jurisdiction of this provision-Hardware or Web/Software.



I would propose that language be crafted that provides a minimum level of
contrast and brightness so that people with low vision would be able to
utilize products with this type of display effectively.







Tom Brett