Opened 10 years ago

Last modified 7 years ago

#5233 open feature

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:

Description

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.

  1. 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").

  1. 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 styles.

  • 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 elements.

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 10 years ago.
patch-mar-1.txt (5.3 KB) - added by Gijs 9 years ago.
Updated version of the patch
patch-mar-2.txt (7.9 KB) - added by Gijs 9 years ago.
Updated version of the patch

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by hhillen

Attachment: high_contrast_support.txt added

comment:1 Changed 10 years ago by hhillen

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 9 years ago by Gijs

Attachment: patch-mar-1.txt added

Updated version of the patch

comment:2 Changed 9 years ago by Gijs

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 9 years ago by Gijs

Attachment: patch-mar-2.txt added

Updated version of the patch

comment:3 Changed 9 years ago by Gijs

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 event.target.parentNode 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.

comment:4 Changed 9 years ago by Jörn Zaefferer

Type: enhancementfeature

comment:5 Changed 7 years ago by Jörn Zaefferer

Status: newopen

Another work in progress: https://github.com/jquery/jquery-ui/pull/217

Looking for Hans to send a new pull request.

comment:6 Changed 7 years ago by Scott González

Microsoft has a media query for high contrast support: http://msdn.microsoft.com/en-us/library/ie/hh771830(v=vs.85).aspx

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

comment:7 Changed 7 years ago by Scott González

Milestone: 1.9.01.10.0

comment:8 Changed 7 years ago by Jörn Zaefferer

The pull at https://github.com/jquery/jquery-ui/pull/217 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.

comment:9 Changed 7 years ago by mikesherov

Keywords: haspatch added; a11y removed

comment:10 Changed 7 years ago by tj.vantoll

Milestone: 1.10.0none
Note: See TracTickets for help on using tickets.