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: |
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.
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
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)
Change History (10)
Changed February 25, 2010 11:51PM UTC by comment:1
Changed March 01, 2010 07:34PM UTC by 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 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 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.
Changed July 30, 2010 10:09AM UTC by comment:4
| type: | enhancement → feature |
|---|
Changed February 27, 2012 03:54PM UTC by comment:5
| status: | new → open |
|---|
Another work in progress: https://github.com/jquery/jquery-ui/pull/217
Looking for Hans to send a new pull request.
Changed May 17, 2012 05:42PM UTC by comment:6
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.
Changed October 11, 2012 02:42PM UTC by comment:7
| milestone: | 1.9.0 → 1.10.0 |
|---|
Changed November 05, 2012 10:26AM UTC by comment:8
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.
Changed November 05, 2012 12:39PM UTC by comment:9
| keywords: | a11y → haspatch |
|---|
Changed January 25, 2013 09:22PM UTC by comment:10
| milestone: | 1.10.0 → none |
|---|
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:
The following issues remain: