Thread Subject: color and contrast *within* a graphic

From: Jim Tobias
Date: Mon, Apr 02 2007 11:00 AM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Gregg Vanderheiden: "Re: color and contrast *within* a graphic"
• Previous message in thread: None
• Messages sorted by: Author | Thread | Date

Thanks, Barbara -- that's very clear.

Another related issue that to my knowledge has never been dealt with is how
the graphic uses color
and contrast internally. That is, a high-contrast line drawing may be
easier to understand than a
greyscale image with lots of subtle shading; similarly, an image may
unintentionally be an Ishihara test:
composed of adjoining colored shapes whose colors are not perceptible to
people who are colorblind.

Has anyone ever encountered either a situation in which the current 508
provisions were applied to
these cases, or another standard that explicitly deals with them?


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




_____

From: Lybarger, Barbara (MOD) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, April 02, 2007 11:33 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Allen's proposal for a newsection
oncontent


Is this mixing up the issues involving color with those involving contrast?
At least the way I've always thought about those two standards:

1.

The color provision is about not using color alone (i.e. without
text) to convey information, because folks who are color blind or have low
to no vision can't distinguish the color.
2.

The contrast provision is about text on a background not using
colors (or grays) the density of which are so close together that they are
hard to distinguish for folks who are color blind or who have low vision.


The issue you seem to be dealing with is really the latter. The existing
508 approach, although needing better specificity, deals with the degree of
contrast between colors. AT doesn't really address the contrast issue for
the reasons you identify. Given this, the standard may need to at least
stay as is (i.e. contrast is in the eye of the beholder thru manual
testing), unless someone has comes up with a viable means of automated
measurement of contrast.

Hoping this is helpful,
Barbara Lybarger

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Monday, April 02, 2007 10:27 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Allen's proposal for a newsection
oncontent


Hmmm:
Gregg wrote:
"Hi Allen,

On your second point below. That is fine. If people will read 'encoding'
in the general sense then we are ok.

On the first point, (i.e. color values of the foreground text and
background) I still am not sure I understand the benefit. If the content
is rendered
to the screen the AT can always get the color values. But from discussions
in our other group it was my understanding that there are no AT that can
deal
with presenting the millions of colors to people in a way that they can
understand.

Could you provide some examples of how this information would be used by AT?


Also, why you think that it wouldn't always be available anyway?"

Let me take a stab at this by retracing my original thinking which of course
could be faulty:

The idea is to define a minimum set of accessibility capacities that *m7st*
be included in a method to store information for presentation. For example,
if tabular formats are supported in the format, then we need to be able to
associate headers and cells specifically.

Next:

When thinking about color we have "color shall not be used as the only means
to convey information..."

We also have requirements now about text attributes such as font, etc.

So if color is supported in the format, we need to ensure that the color
values, which could be from a wide range, are accessible by AT. This may be
mute as we have discussed, as the color has to be represented in some way,
and the user-agent would then present it. I guess I'm thinking that we just
should say that color values should be accessible which may not need saying
at all.

Color values are used by AT to tell what color items are, and in HTML is
definitely derived from the HTML generally.

I may be talking myself out of this requirement for encoding schemes, but
that's fine as long as we at least explored it before tossing it out.




Allen hoffman -- 202-447-0303



_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, April 02, 2007 9:52 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Allen's proposal for a newsection
oncontent



Hi Allen,



On your second point below. That is fine. If people will read 'encoding'
in the general sense then we are ok.



On the first point, (i.e. color values of the forground text and
background) I still am not sure I understand the benefit. If the content
is rendered to the screen the AT can always get the color values. But from
discussions in our other group it was my understanding that there are no AT
that can deal with presenting the millions of colors to people in a way that
they can understand.



Could you provide some examples of how this information would be used by AT?


Also, why you think that it wouldn't always be available anyway?



Maybe I'm just missing what you are saying.



Thanks.


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






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Monday, April 02, 2007 7:24 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Allen's proposal for a new section
oncontent

Gregg:

I think a couple of your comments may be coming from the perspective of web
accessibility, rather than "general format" or "encoding" capacities
viewpoint which I was working from. I'll explain:



3. When a content format supports color, an encoding mechanism shall be
provided to identify all colors selected for text, both foreground and
background displayable by a user-agent.

GV: Not clear the benefit of this. Since there are millions of colors and
there are not names for them and few people could identify a color by its
codes. Suggest two other guidelines

a) information is not presented only using color.

b) that foreground text and its background have a contrast of at least
relative luminance contrast of X:1 (5?). (which makes the contrast color
insensitive)



My intentionwas to ensure that a mechanism is included in the format to
identify by coding, probably unique set of number values within specified
ranges, of foreground and background colors. maybe this is a mute point, as
in if an encoding scheme does include this capacity how would it be
inaccessible to inspection? This might be rewritten to include your points
as:



When an encoding scheme includes the capacity to represent color, color
values shall also be represented with an associated contrast value. (I'm not
fond of this to be honest).



I am not certain how we can ensure that color is not used as the only means
of conveying information purely from an encoding scheme perspective, as this
involves the full usage of the encoding scheme by the author via the
authoring tool and the viewing by the user-agent.





GV: maybe delete 'encoding' to make them more technology neutral



To me the concept for "encoding mechanism" is that the format, (a format by
definition is a mechanism to encode information through repeatable
processes", is technology neutral and only applies to the specific "format"
such as HTML, PDF, Word Star, etc that is used.



I do believe that #2 could be refined to reflect the in-process definition
of captioning and possibly "video description" also.



Finally:

Here is a link to the NIMAS format specifications. I'm combing through
these now to see what can be referenced, used, or otherwise provide better
requirements for encoding schemes/formats minimum specifications.

http://nimas.cast.org/about/proposal/spec-v1_1.html







Allen Hoffman -- 202-447-0303






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Sunday, April 01, 2007 3:05 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Allen's proposal for a new section
oncontent



Overall I think this is a good direction and in keeping with what the
General Group discovered (the need to qualify the application of the
various guidelines)



Couple of comments here and three below marked GV:

Some others look like they need some tuning.



GV: maybe delete 'encoding' to make them more technology neutral

GV: 'verbal' means 'words' not 'speech' (vocal). Braille is verbal.
Maybe use "Auditory"





Add a new section to 508 (1194.27?)



1. When a content format supports non-text objects, an encoding mechanism
shall be provided to associate non-text objects with textual descriptions
displayable by a user-agent.

2. When a content format supports multimedia, an encoding mechanism shall
be provided to include synchronized text of verbal content, and audio
descriptions of critical nonverbal activity displayable by a user-agent.

GV: 'verbal means words not speech (vocal). Braille is verbal. Maybe
use "Auditory" would work better here than 'verbal'.

3. When a content format supports color, an encoding mechanism shall be
provided to identify all colors selected for text, both foreground and
background displayable by a user-agent.

GV: Not clear the benefit of this. Since there are millions of colors and
there are not names for them and few people could identify a color by its
codes. Suggest two other guidelines

a) information is not presented only using color.

b) that foreground text and its background have a contrast of at least
relative luminance contrast of X:1 (5?). (which makes the contrast color
insensitive)



4. When a content format supports 2 dimensional display of information,
an encoding mechanism shall be provided to identify the logical linear
reading order of the content displayable by a user-agent.

5. When a content format supports data tables, an encoding mechanism
shall be provided to identify row and column headers for tabular information
displayable by a user-agent.

6. When a content format supports data tables, an encoding mechanism
shall be provided to associate row and column headers with other table
cells, displayable by a user-agent.

7. When a content format supports interactive elements, an encoding
mechanism shall be provided to identify identity, operation, and state, of
any interactive elements displayable by a user-agent.

GV: Should add "name" to the lists. Identity is often a unique number or
code.



8. When a content format supports links, an encoding mechanism shall be
provided to identify link text or graphics displayable by a user-agent.

9. When a content format supports embedded comments, an encoding
mechanism shall be provided to identify embedded comments and associate
those comment locations within the document.

10. Encoding mechanism which allow programmatic input and execution of
end-user scripting, shall provide access to the embedded scripts.

11. When a content format supports scanned images of text, an encoding
mechanism shall be provided to identify text of scanned images of text,
displayable by a user-agent. Note, this means allowing for inclusion of the
text of a scanned image of text.

12. When a content format supports dynamic presentations, graphs, or other
extracted information, an encoding mechanism shall be provided to include
data used for any dynamic presentations, graphs, or other extracted
information displayable by a user-agent.





Gregg

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

Gregg C Vanderheiden Ph.D.







> -----Original Message-----

> From: = EMAIL ADDRESS REMOVED =

> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf

> Of Andi Snow-Weaver

> Sent: Friday, March 30, 2007 3:12 PM

> To: = EMAIL ADDRESS REMOVED =

> Subject: [teitac-websoftware] Allen's proposal for a new

> section on content

>

>

> Please carefully review Allen's proposal on content before

> next week. [1] As I said yesterday in the meeting, I added a

> phrase to the beginning of each one to cover a concern that

> was raised about applicability; that is, you only have to

> provide an encoding mechanism for table headers if the

> content format supports data tables.

>

> I provided some comments and questions on the wiki "discuss"

> page. [2] Feel free to add your comments to the wiki or to

> post them here on the mailing list and we will summarize

> before next week's call.

>

> [1]

> http://teitac.org/wiki/Web_and_Software:content#Add_a_new_sect

> ion_to_508_.281194.27.3F.29

> [2] http://teitac.org/wiki/Talk:Web_and_Software:content

>

> Andi

>

>

• Next message in Thread: Gregg Vanderheiden: "Re: color and contrast *within* a graphic"
• Previous message in Thread: None