Implementation high contrast support

[Hans Hillen]

Hi All,

I want to start working on implementing support on high contrast
mode.

As most of you will know, 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.

I was hoping to get some feedback here about this plan and whether it
is a good idea. Additionally, I would like to know how to approach
with implementing this. For example, what would be the recommended
part of jQuery to add such a test div element, and in what namespace
should the high contrast flag be set?

Thanks,

Hans

[Hans Hillen]

My colleague Gijs KruitBosch has started working on a patch for this:
http://dev.jqueryui.com/attachment/ticket/5233/high_contrast_support.txt

It follows a similar approach as the description I gave before, and
currently makes icon buttons, the close button in dialogs, and the
progress bar compatible with high contrast mode.

Any feedback would be appreciated,

Hans

[Scott González]

This looks like a good start, but I've got a few comments:

- The styling for the test div should be in the JavaScript instead of the theme file (see how jQuery.support works).
- We should run this code immediately and store the flag as part of the public API. Maybe expose the flag as jQuery.highContrast.
- Can the style property checks go through jQuery instead of using the native DOM methods? If so, it'll make the code smaller.

--
You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.

[Gijs]

Hi Scott,

Thanks for the comments. Some replies inline:

On Feb 26, 3:07 am, Scott González <scott.gonza...@gmail.com> wrote:
> This looks like a good start, but I've got a few comments:
>
> - The styling for the test div should be in the JavaScript instead of the
> theme file (see how jQuery.support works).

OK, will do.

> - We should run this code immediately and store the flag as part of the
> public API. Maybe expose the flag as jQuery.highContrast.

It is currently run as the page HTML is loaded, there's a call: $
(document).ready($.ui.highContrastMode); towards the end of the core
jQuery UI file. Should it be done differently? Where would be a good
place to do so? (I'll happily take pointers to source code or howtos
if that wastes less of your time. :-)

As for the flag, OK. I figured exposing it on the UI object sort of
made sense as it will mostly be the UI that cares about it. Should the
detection code move to jQuery proper, too, or only the flag itself?

> - Can the style property checks go through jQuery instead of using the
> native DOM methods? If so, it'll make the code smaller.

Doh. I'm a jQuery novice, and did look for a getCS equivalent but
couldn't find one. After some more googling, looks like $(el).css(...)
should work, I'll test that and submit an updated patch.

Cheers,
Gijs

[Scott González]

Hey Gijs,

You can see how jQuery core does testing against elements in http://github.com/jquery/jquery/blob/master/src/support.js. The tests don't wait for the document to be ready, they're just run immediately when the script is parsed. Matching that style would be ideal, but if the style properties require the element to be attached to the page, then we may have to use document.ready.

As for where the flag and code should live (directly on jQuery or on jQuery.ui), I'll talk to the core team and see what they think. Similar to how support.js works, I think the function that runs shouldn't be stored on an object anywhere since it won't be useful after it runs.

Also, you should be able to use $.curCSS(el, prop) and it should be slightly faster than $(el).css('prop') since it won't create a new jQuery instance.

Thanks.

--

[Gijs Kruitbosch]

Hi Scott,

Thanks for your comments. I've updated the ticket with a new attachment ( http://dev.jqueryui.com/attachment/ticket/5233/patch-mar-1.txt ), which uses the curCSS approach, and puts a flag on jQuery.

About running the detection, at the moment I still rely on some external CSS (the ui-icon class) and append the element to the body (which requires being run using document.ready, which is also used for some of the jQuery supports bits). To copy/paste from my comment about the patch:

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 I don't know how to determine 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), and still relies on CSS rather than just setting style properties. If there is a better way to solve this problem, do let me know.

Let me know what you think!

Cheers,
Gijs

2010/2/26 Scott González <scott.g...@gmail.com>

[Gijs Kruitbosch]

PS: credit where credit's due - the ui-icon class was a suggestion from Paul (nick paul_irish) over IRC. :-)

[Scott González]

Hey Gijs,

Thanks for updating the patch. Can we use a data URI instead of the icon class to remove the external image dependency? Also, let's store the flag as $.support.highContrast.

[Gijs Kruitbosch]

Hi Scott,

I thought IE6 and 7 didn't support those? I'm actually running into a similar issue with the grippy icon on dialogs: fixing that requires an actual <img>, which of course needs a src attribute with a working URL... So a data URI would work great as a solution for those, but if we need to care about IE6/7 we'll need an alternative solution for them.

Cheers,
Gijs

2010/3/2 Scott González <scott.g...@gmail.com>

[Scott González]

Hey Gijs,

Only took me 8 months to respond, but... here's a solution for using data URIs in IE 6/7: http://jonraasch.com/blog/css-data-uris-in-all-browsers