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:
- 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.
- 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").
- 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 (13)
Changed 10 years ago by
| Attachment: | high_contrast_support.txt added |
|---|
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
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.
comment:3 Changed 10 years ago by
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
| Type: | enhancement → feature |
|---|
comment:5 Changed 8 years ago by
| Status: | new → open |
|---|
Another work in progress: https://github.com/jquery/jquery-ui/pull/217
Looking for Hans to send a new pull request.
comment:6 Changed 8 years ago by
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
| Milestone: | 1.9.0 → 1.10.0 |
|---|
comment:8 Changed 7 years ago by
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
| Keywords: | haspatch added; a11y removed |
|---|
comment:10 Changed 7 years ago by
| 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: