Skip to main content

Search and Top Navigation

#5233 open feature ()

Opened February 25, 2010 11:45PM UTC

Last modified January 25, 2013 09:22PM UTC

Add support for high contrast mode

Reported by: hhillen Owned by:
Priority: major Milestone: none
Component: ui.core Version: 1.8rc2
Keywords: haspatch Cc:
Blocked by: Blocking:

High contrast mode is an accessibility

feature in the Windows operating system that changes background and

foreground colors so that they are easier to perceive by low vision

users who require a particular contrast scheme. Browsers generally

inherit this scheme, usually by overriding background and foreground

color and removing background images.

The plan is to follow a similar approach as DOJO does, which in a

nutshell would mean the following:

1. When jQuery loads, create a test div element that is positioned

off-screen. Set different border colors for individual sides of the

div. Also set a background image.

2. After creation, check the element's computed styles. If the border

colors are now the same for each side of the div, or the background

image is no longer set, this means high contrast mode is active. This

is then indicated as a globally accessible flag somewhere on the

jQuery object (for example, "$.highContrast = true").

3. When the high contrast flag is set to true, widgets that normally

have problems displaying correctly in high contrast mode will apply

specific HTML and/or CSS changes to solve these issues.

Examples of changes that could be made when high contrast mode is on:

  • Adding border styles. Border styles remain visible in high contrast

mode. this is specifically useful for widgets that indicate selection

using background styles.

  • Inserting text. For example, the progressbar widget is difficult to

see in high contrast mode because it uses background images. To get

around this we could ensure that the current value of the progressbar

is shown as text as well when high contrast mode is active (e.g.

"54%"). The text would then correctly inherit the high contrast


  • Inserting images. For example, some components may normally use

background images, but in high contrast mode the widget could instead

inject a high contrast version of the image into the DOM (images in

the DOM will still be visible in high contrast mode)

  • Unhiding content. for example, icon buttons are implemented using a

background image. These buttons also have a hidden span element that

contains the button's textual name. In high contrast mode, we can

unhide this element, so that the button would still be usable as a

text button.

  • Applying focus styles. To make it easier to see which element has

focus, we could add thicker outline or border styles for focused


The point is, there will be a flag set that will allow us to do

whatever is necessary to make widgets usable in high contrast mode.

Attachments (3)
  • high_contrast_support.txt (4.4 KB) - added by hhillen February 25, 2010 11:46PM UTC.
  • patch-mar-1.txt (5.3 KB) - added by Gijs March 01, 2010 07:27PM UTC.

    Updated version of the patch

  • patch-mar-2.txt (7.9 KB) - added by Gijs March 02, 2010 11:37PM UTC.

    Updated version of the patch

Change History (10)

Changed February 25, 2010 11:51PM UTC by hhillen comment:1

My colleague Gijs KruitBosch has started working on a patch for this (see attached file).

So far the patch works as follows:

There's four code (JS) change hunks: a method to check whether HCM is on, automatically running that method on page load, using it to make icon buttons display as text buttons, and adding the value of a progressbar to itself in text. Then there's a whole bunch of style changes that use the attribute added to the <body> in the code blocks. Together, this ensures:

  • icon buttons display as text buttons in high contrast mode.
  • the date picker buttons display as text in HCM.
  • the tabs and accordion widgets get a better focus indication (for the accordion, also outside of HCM)
  • the progress bar gets a value shown in HCM.

The following issues remain:

  • Buttons which have a pressed state (like the B/I/U buttons on the default button visual test) don't show that in HCM.
  • The dialog resize handle isn't visible in HCM.

Changed March 01, 2010 07:34PM UTC by Gijs comment:2

I've added an updated version of the patch. Changes are:

  • Move to just having a property on jQuery's global object rather than a method.
  • Use no CSS for the detection of HCM.
  • Use jQuery's own curCSS method to detect the div's styling.

Note that I'm using the ui-icon class in order to avoid dealing with paths to image files from the jQuery JS, which I think will be treated as being "from" the including page, from which we don't know the location of the jQuery themes/image directory. On the other hand, the current approach will break if there are themes which don't use the same approach to show icons as the default (a single background image, and background offsets to control which icon is shown). If there is a better way to solve this problem, do let me know.

Changed March 02, 2010 11:59PM UTC by Gijs comment:3

Still more updates just added. Changes:

  • Use $.support.highContrast
  • Switch to using position:relative on the progressbar container, and position: absolute within, to work around IE6 sucking. This may be a problem if the user of the library could/does decide to use other values for 'position' on the progressbar? To fix that, one could add another div to contain the valueDiv and valueTextDiv, and give that position: relative, or just not care about IE6 and revert to the approach used in the previous patch (which does work in IE7, IE8, Firefox, etc.).
  • Use an <img> for the dialog resize grippy in HCM only, so that it can still be seen and used in HCM. This hacks into the resizable code in order to ensure dragging the <img> works, by adding it to the handles collection. If that's undesirable for reasons that I missed, a different way to make it work is to also check if is a handle, in _mouseCapture in jquery.ui.resizable.js.

I haven't changed the ui-icon approach to use a data: URI, because... it doesn't seem to work! :-(

For some reason both Firefox (3.6) and IE6-8 don't remove the backgroundImage in the computedstyle, even though it is not displayed. The same happens when using an ordinary http url from the JS too, though... Honestly not sure why at this point.

With the caveats above, I think this is getting somewhere. The only other issue I know of at this time is showing the pressed state of push buttons, and I'm not quite sure how to go about doing that at this point.

Changed July 30, 2010 10:09AM UTC by jzaefferer comment:4

type: enhancementfeature

Changed February 27, 2012 03:54PM UTC by jzaefferer comment:5

status: newopen

Another work in progress:

Looking for Hans to send a new pull request.

Changed May 17, 2012 05:42PM UTC by scottgonzalez comment:6

Microsoft has a media query for high contrast support:

There is work to get this standardized for Media Queries 4.

Changed October 11, 2012 02:42PM UTC by scottgonzalez comment:7


Changed November 05, 2012 10:26AM UTC by jzaefferer comment:8

The pull at got closed and has some unrelated commits, but the actual change to ui.core.js should still be good.

We should probably use that as a fallback, using media queries as the primary detection mechanism.

Changed November 05, 2012 12:39PM UTC by mikesherov comment:9

keywords: a11yhaspatch

Changed January 25, 2013 09:22PM UTC by tj.vantoll comment:10

milestone: 1.10.0none