E-mail List Archives
Thread: colour contrast algorithm
Number of posts in this thread: 11 (In chronological order)
From: Dey Alexander
Date: Thu, Sep 18 2003 2:43AM
Subject: colour contrast algorithm
No previous message | Next message →
The suggested algorithm for testing to see if text and background
colours provide sufficient contrast (as documented in the W3C's draft
techniques document for Accessibility Evaluation and Repair Tools at
http://www.w3.org/TR/AERT#color-contrast) has recently been discussed on
this list (between 20-26 August 2003).
However the discussion did not lead anywhere terribly useful, and my
query is slightly different to the original focus of the earlier discussion.
The W3C document indicates that the algorithm is a "suggested" one that
is "still open to change". Can anyone shed any light on whether this is
then a reliable indicator of colour contrast, or whether some more
authoritative/reliable algorithm exists?
Reason for my question: sponsors/clients of a project I am currently
working on believe that the requirements are too stringent. This view
was expressed after I used the algorithm to generate a report on a range
of colour options that were being considered--very few of them passed
muster, as I expected.
I would be extremely grateful for any advice or references to other
resources/expert opinions.
Cheers,
Dey
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: gez
Date: Thu, Sep 18 2003 6:12AM
Subject: Re: colour contrast algorithm
← Previous message | Next message →
Hi Dey,
I've been trying to find out myself if there has been any more work on the
algorithm, but haven't been able to come up with anything.
Personally, I think the suggested algorithms works well, but I think the
threshold for the difference in colour is a bit high. I know that HP use the
algorithm, but instead of using a threshold of 500 for the colour
difference, they use a colour difference of 400, which is much more
workable. The W3C's threshold for the difference in brightness seems to work
OK from the tests I've done.
The algorithms only really work with normal text, and don't take into
account the weight of the font. You get the same results for bold or normal
text, where bold text will obviously be more distinguishable.
I've implemented the algorithm on my site, so you can quickly test colours
to see what works: http://www.juicystudio.com/services/colourcontrast.asp
Best regards.
Gez
----- Original Message -----
From: "Dey Alexander" < = EMAIL ADDRESS REMOVED = >
To: "Webaim forum" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, September 18, 2003 9:38 AM
Subject: colour contrast algorithm
> The suggested algorithm for testing to see if text and background
> colours provide sufficient contrast (as documented in the W3C's draft
> techniques document for Accessibility Evaluation and Repair Tools at
> http://www.w3.org/TR/AERT#color-contrast) has recently been discussed on
> this list (between 20-26 August 2003).
>
> However the discussion did not lead anywhere terribly useful, and my
> query is slightly different to the original focus of the earlier
discussion.
>
> The W3C document indicates that the algorithm is a "suggested" one that
> is "still open to change". Can anyone shed any light on whether this is
> then a reliable indicator of colour contrast, or whether some more
> authoritative/reliable algorithm exists?
>
> Reason for my question: sponsors/clients of a project I am currently
> working on believe that the requirements are too stringent. This view
> was expressed after I used the algorithm to generate a report on a range
> of colour options that were being considered--very few of them passed
> muster, as I expected.
>
> I would be extremely grateful for any advice or references to other
> resources/expert opinions.
>
> Cheers,
> Dey
>
>
>
>
>
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/
>
>
>
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: John Britsios
Date: Fri, Sep 19 2003 7:21AM
Subject: Re: colour contrast algorithm
← Previous message | Next message →
Dear all!
Here is a tool a found to this topic!
http://colorpro.com/info/tools/convert.htm
I have found many links to this topic and whcih I have posted them in my
forum here:
http://www.webnauts.net/phpBB2/viewtopic.php?t=52&;sid=cd52ed69455e27753d0df431c25eda43
Worth to have a look at!
My kindest regards,
John Britsios
Web Accessibility and Usability Consultant
----- Original Message -----
From: "gez" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, September 18, 2003 2:09 PM
Subject: Re: colour contrast algorithm
> Hi Dey,
>
>
>
> I've been trying to find out myself if there has been any more work on the
> algorithm, but haven't been able to come up with anything.
>
>
>
> Personally, I think the suggested algorithms works well, but I think the
> threshold for the difference in colour is a bit high. I know that HP use
the
> algorithm, but instead of using a threshold of 500 for the colour
> difference, they use a colour difference of 400, which is much more
> workable. The W3C's threshold for the difference in brightness seems to
work
> OK from the tests I've done.
>
>
>
> The algorithms only really work with normal text, and don't take into
> account the weight of the font. You get the same results for bold or
normal
> text, where bold text will obviously be more distinguishable.
>
>
>
> I've implemented the algorithm on my site, so you can quickly test colours
> to see what works: http://www.juicystudio.com/services/colourcontrast.asp
>
>
>
> Best regards.
>
>
>
> Gez
>
>
>
> ----- Original Message -----
> From: "Dey Alexander" < = EMAIL ADDRESS REMOVED = >
> To: "Webaim forum" < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, September 18, 2003 9:38 AM
> Subject: colour contrast algorithm
>
>
> > The suggested algorithm for testing to see if text and background
> > colours provide sufficient contrast (as documented in the W3C's draft
> > techniques document for Accessibility Evaluation and Repair Tools at
> > http://www.w3.org/TR/AERT#color-contrast) has recently been discussed on
> > this list (between 20-26 August 2003).
> >
> > However the discussion did not lead anywhere terribly useful, and my
> > query is slightly different to the original focus of the earlier
> discussion.
> >
> > The W3C document indicates that the algorithm is a "suggested" one that
> > is "still open to change". Can anyone shed any light on whether this is
> > then a reliable indicator of colour contrast, or whether some more
> > authoritative/reliable algorithm exists?
> >
> > Reason for my question: sponsors/clients of a project I am currently
> > working on believe that the requirements are too stringent. This view
> > was expressed after I used the algorithm to generate a report on a range
> > of colour options that were being considered--very few of them passed
> > muster, as I expected.
> >
> > I would be extremely grateful for any advice or references to other
> > resources/expert opinions.
> >
> > Cheers,
> > Dey
> >
> >
> >
> >
> >
> > ----
> > To subscribe, unsubscribe, suspend, or view list archives,
> > visit http://www.webaim.org/discussion/
> >
> >
> >
>
>
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/
>
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: jeb
Date: Sat, Sep 20 2003 12:59PM
Subject: Dreamweaver MX 2004
← Previous message | Next message →
Has anyone done a review about the newest version of Dreamweaver (DW MX
2004) regarding accessibility? I've only seen what Macromedia is reporting
on their website which looks pretty good:
http://www.macromedia.com/macromedia/accessibility/mx/dw/
Is there anyone out there using this that confirm?
John E. Brandt
Augusta, ME 04330
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
www.jebswebs.com <http://www.jebswebs.com>;
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Dey Alexander
Date: Sat, Sep 20 2003 6:52PM
Subject: Re: Dreamweaver MX 2004
← Previous message | Next message →
I am a very occasional user of Dreamweaver MX and one thing that alarms
me having read the documentation on the Macromedia page mentioned below
is that authors now need to turn on the accessibility features from the
preferences menu. Unless I'm mistaken (as I said, I'm only a casual DW
user) many of the accessibility features mentioned are already available
in MX by default.
Cheers,
Dey
jeb wrote:
> Has anyone done a review about the newest version of Dreamweaver (DW MX
> 2004) regarding accessibility? I've only seen what Macromedia is reporting
> on their website which looks pretty good:
>
> http://www.macromedia.com/macromedia/accessibility/mx/dw/
>
> Is there anyone out there using this that confirm?
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Cheryl D. Wise
Date: Sat, Sep 20 2003 8:20PM
Subject: RE: Dreamweaver MX 2004
← Previous message | Next message →
No, they weren't available by default in Dreamweaver MX either. You've
always had to turn them on in the preference menu. I just installed
Dreamweaver MX 2004 on my PC. I've been using the trial on the Mac for about
a week but since I never used Dreamweaver on the Mac before I can't say how
many changes there were.
Cheryl D. Wise
MS-MVP- FrontPage
www.wiserways.com
mailto: = EMAIL ADDRESS REMOVED =
713.353.0139 Office
From: Stephanie Sullivan
Date: Tue, Sep 23 2003 8:59PM
Subject: Re: Dreamweaver MX 2004
← Previous message | Next message →
The DW 2004 report... :)
The accessibility tools are definitely better. There were definite changes
made. There were SOME things you could do in MX, but now there's much more.
One of the things I like is that when you turn the accessibility options ON
in the preferences, you get an accessibility dialogue as you place the
element on the page.
So for instance, you insert a table -- besides the normal table settings,
you can now set table headers (none, left, top, both), Captions (and their
alignment), and summary... You do it right there as you're inserting the
table.
Inserting an image gives you a dialog that allows you to add your alt tag
and long desc url and such at the time of insertion. Form objects, frames
and media are the other options.
It's a definite improvement. I hope people will actually use it. ;)
Stephanie Sullivan
Contributing Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
CommunityMX Team Member :: http://www.communitymx.com
Technical Editor .: "DreamweaverMX Killer Tips" :. New Riders
VioletSky Design :: http://www.violetsky.net
"If we knew what we were doing, it wouldn't be called research , would
it?"-- Albert Einstein
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Stephanie Sullivan
Date: Tue, Sep 23 2003 9:10PM
Subject: Tabindex and skip links...
← Previous message | Next message →
Hi all. I have not been on this list long so I apologize if this has already
been discussed ad infinitum.
I have a site that will be going live next week. It is a 'mildly accessible'
site with inline UL for most navigation, uses CSS with one overall table for
the three columns (not the header of footer), XHTML Transitional.
We have used tabindexes to take the user from each nav button to their
respective subnav group in order... Then on to the sign in and search forms.
All this is working swimmingly.
Here's my issue.
We also created four visible skip links (we opted not to use display:none)
which are the first four tabindexes for each page. These go to the log in
form, the main content, the list of that day's new content and the search
box. HOWEVER, what I've found is that though the user can tab to the skip
link that takes them to the search box -- once they click on the skip link
and actually jump to the anchor in the search form -- when they hit tab
again to get INTO the text field to search, they pop back over to the next
tab index... Not the form field.
I've tried several workarounds. Some were likely not too kosher. But I can't
get anything to work. <sigh />
So is this an "either/or" situation? Can I not have a tabindex AND skip
links? Does anyone have an idea for a solution?
TIA,
Stephanie Sullivan
Contributing Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
CommunityMX Team Member :: http://www.communitymx.com
Technical Editor .: "DreamweaverMX Killer Tips" :. New Riders
VioletSky Design :: http://www.violetsky.net
You may have a fresh start any moment you choose, for this thing we call
failure is not the falling down, but the staying down. - Mary Pickford
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: gez
Date: Tue, Sep 23 2003 9:57PM
Subject: Re: Tabindex and skip links...
← Previous message | Next message →
Hi Stephanie,
I would also be interested in hearing opinions on this problem. I've found
the behaviour is different, depending on the browser. IE and Lynx behave how
you would expect them to behave. They maintain the tab order, from the point
of the in-page link. Mozilla and Opera appear to reset the tab index when
you click on an in-page link. Skip links are just like any other in-page
link, so clicking on one means the next tab in the sequence will be the
first in the defined tab order. Unless I'm missing something fundamental, I
would say the behaviour of Mozilla and Opera is buggy, and defeats the
purpose of providing skip links, or any other type of in-page link with a
view to aiding keyboard navigation.
Strangely, Mozilla (and other Gecko based browsers) will respect the tab
order if you enter the address directly, including fragment identifier (or
navigate to the fragment identifier from another page).
Best regards.
Gez
________________________
Supplement your vitamins
http://www.juicystudio.com
Keeping developers informed!
----- Original Message -----
From: "Stephanie Sullivan" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, September 24, 2003 4:03 AM
Subject: Tabindex and skip links...
> Hi all. I have not been on this list long so I apologize if this has
already
> been discussed ad infinitum.
>
> I have a site that will be going live next week. It is a 'mildly
accessible'
> site with inline UL for most navigation, uses CSS with one overall table
for
> the three columns (not the header of footer), XHTML Transitional.
>
> We have used tabindexes to take the user from each nav button to their
> respective subnav group in order... Then on to the sign in and search
forms.
> All this is working swimmingly.
>
> Here's my issue.
>
> We also created four visible skip links (we opted not to use display:none)
> which are the first four tabindexes for each page. These go to the log in
> form, the main content, the list of that day's new content and the search
> box. HOWEVER, what I've found is that though the user can tab to the skip
> link that takes them to the search box -- once they click on the skip link
> and actually jump to the anchor in the search form -- when they hit tab
> again to get INTO the text field to search, they pop back over to the next
> tab index... Not the form field.
>
> I've tried several workarounds. Some were likely not too kosher. But I
can't
> get anything to work. <sigh />
>
> So is this an "either/or" situation? Can I not have a tabindex AND skip
> links? Does anyone have an idea for a solution?
>
> TIA,
>
> Stephanie Sullivan
>
> Contributing Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New
Riders
> CommunityMX Team Member :: http://www.communitymx.com
> Technical Editor .: "DreamweaverMX Killer Tips" :. New Riders
> VioletSky Design :: http://www.violetsky.net
>
> You may have a fresh start any moment you choose, for this thing we call
> failure is not the falling down, but the staying down. - Mary Pickford
>
>
>
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/
>
>
>
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: gez
Date: Tue, Sep 23 2003 10:08PM
Subject: Re: Tabindex and skip links...
← Previous message | Next message →
Having read my reply, I've just realised something relatively significant.
Mozilla (and other Gecko based browsers) will respect the tab order if you
navigate to an in-page link using the keyboard. It only seems to break when
using the mouse to click an in-page link, followed by keyboard navigation.
That's not as bad a situation as I first imagined, but I would still be
interested in people's opinion on this behaviour.
Best regards.
Gez
________________________
Supplement your vitamins
http://www.juicystudio.com
Keeping developers informed!
----- Original Message -----
From: "gez" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, September 24, 2003 4:55 AM
Subject: Re: Tabindex and skip links...
> Hi Stephanie,
>
> I would also be interested in hearing opinions on this problem. I've found
> the behaviour is different, depending on the browser. IE and Lynx behave
how
> you would expect them to behave. They maintain the tab order, from the
point
> of the in-page link. Mozilla and Opera appear to reset the tab index when
> you click on an in-page link. Skip links are just like any other in-page
> link, so clicking on one means the next tab in the sequence will be the
> first in the defined tab order. Unless I'm missing something fundamental,
I
> would say the behaviour of Mozilla and Opera is buggy, and defeats the
> purpose of providing skip links, or any other type of in-page link with a
> view to aiding keyboard navigation.
>
> Strangely, Mozilla (and other Gecko based browsers) will respect the tab
> order if you enter the address directly, including fragment identifier (or
> navigate to the fragment identifier from another page).
>
> Best regards.
>
> Gez
>
> ________________________
> Supplement your vitamins
> http://www.juicystudio.com
> Keeping developers informed!
>
> ----- Original Message -----
> From: "Stephanie Sullivan" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >
> Sent: Wednesday, September 24, 2003 4:03 AM
> Subject: Tabindex and skip links...
>
>
> > Hi all. I have not been on this list long so I apologize if this has
> already
> > been discussed ad infinitum.
> >
> > I have a site that will be going live next week. It is a 'mildly
> accessible'
> > site with inline UL for most navigation, uses CSS with one overall table
> for
> > the three columns (not the header of footer), XHTML Transitional.
> >
> > We have used tabindexes to take the user from each nav button to their
> > respective subnav group in order... Then on to the sign in and search
> forms.
> > All this is working swimmingly.
> >
> > Here's my issue.
> >
> > We also created four visible skip links (we opted not to use
display:none)
> > which are the first four tabindexes for each page. These go to the log
in
> > form, the main content, the list of that day's new content and the
search
> > box. HOWEVER, what I've found is that though the user can tab to the
skip
> > link that takes them to the search box -- once they click on the skip
link
> > and actually jump to the anchor in the search form -- when they hit tab
> > again to get INTO the text field to search, they pop back over to the
next
> > tab index... Not the form field.
> >
> > I've tried several workarounds. Some were likely not too kosher. But I
> can't
> > get anything to work. <sigh />
> >
> > So is this an "either/or" situation? Can I not have a tabindex AND skip
> > links? Does anyone have an idea for a solution?
> >
> > TIA,
> >
> > Stephanie Sullivan
> >
> > Contributing Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New
> Riders
> > CommunityMX Team Member :: http://www.communitymx.com
> > Technical Editor .: "DreamweaverMX Killer Tips" :. New Riders
> > VioletSky Design :: http://www.violetsky.net
> >
> > You may have a fresh start any moment you choose, for this thing we call
> > failure is not the falling down, but the staying down. - Mary Pickford
> >
> >
> >
> > ----
> > To subscribe, unsubscribe, suspend, or view list archives,
> > visit http://www.webaim.org/discussion/
> >
> >
> >
>
>
> ----
> To subscribe, unsubscribe, suspend, or view list archives,
> visit http://www.webaim.org/discussion/
>
>
>
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Stephanie Sullivan
Date: Wed, Sep 24 2003 2:55PM
Subject: Re: Tabindex and skip links...
← Previous message | No next message
on 9/23/03 11:03 PM, Stephanie Sullivan at = EMAIL ADDRESS REMOVED = profoundly
spewed forth their very articulate thoughts:
> I've tried several workarounds. Some were likely not too kosher. But I can't
> get anything to work. <sigh />
I have one working now. But I have no idea who can actually use it. I'd
appreciate feedback if anyone has knowledge of this.
For the two forms that the skip links go to (log in and search), we are
using an onClick JavaScript that will take the user to the first form field
and give it focus.
I know this will work for people that need to tab through pages. But I'm not
sure about assistive technology and javascript.
Is there a compiled list anywhere that tells what assistive tech does with
JS? I'd be very interested in that.
Thanks again. :)
Stephanie Sullivan
Contributing Author .: "Macromedia Dreamweaver MX 2004 Magic" :. New Riders
CommunityMX Team Member :: http://www.communitymx.com
Technical Editor .: "DreamweaverMX Killer Tips" :. New Riders
VioletSky Design :: http://www.violetsky.net
"Your assumptions are your windows on the world. Scrub them off every once
in a while, or the light won't come in." - Isaac Asimov
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/