New wiki pages for widget design planning

[Todd Parker]

Hi all -

Thanks again for meeting with us today. We're fired up to get started.
We'll keep our conversations here and start building out info on the
hidden part of the wiki here:
http://docs.jquery.com/UI/Planning

The idea is to develop a detailed page per widget that includes all
facets of it's definition: design, accessibility, requirements,
ownership, and code. I created a skeleton page for a widget definition
here:
http://docs.jquery.com/UI/Planning/Datepicker

And dropped much of our conversation about the collection and best
practice research here:
http://docs.jquery.com/UI/Planning/UICollection

I'll try to clean this up as the week progresses. Please try to help
us flesh this out, I just wanted to start things off.

[David Bolter]

Thanks Todd.

The DatePicker template looks good to me. I think you've captured the
two main bullets for accessibility: ARIA and keyboard. I wonder if we
want address High Contrast Mode (where, for example, background images
get turned off)? I personally feel HCM to be less important than the
keyboard and ARIA work. The basic strategy to deal with HCM is to
detect the mode in onload (and to be the first onload handler), and
dynamically load a style sheet which might for example, change a close
box background image into a letter 'x'. To try out HCM on Windows try
[Left alt]+[Left shift]+[print screen]

The UICollection looks good and I look forward to helping the team get
the ARIA right for the various widgets here :)

cheers,
David

[clown]

Hi Todd,

Just a note to point to the DTHML style guide. It outlines a set of
keystrokes for "date picker":
http://dev.aol.com/dhtml_style_guide#datepicker

The purpose of the style guide is promote a consistent set of
keystrokes for similar widgets. I'm not sure if it covers everything
in jQueryUI's date picker, but it's worth considering.

Hoping this is useful,
Joseph

[Todd Parker]

Hi all - The high contrast mode and AOL keyboard styleguide are all
great. I've added them to the datepicker wiki page, but feel free to
create and account and add all your great input directly.
http://docs.jquery.com/UI/Planning/Datepicker#Accessibility_recommendations_for_scripting

I also added a section about HCM in the themes section. Good to keep
in mind. I guess we should whip up a HCM theme in Themeroller. Anyone
want to take a crack at it and post the TR url here for us to check
out? At the very least, if there are good example other than Windows,
I'd like to see 'em.

http://docs.jquery.com/UI/Planning/Themes

David- any details you coudl offer about how to detect is a person is
using this mode? Is there already a jQuery plug-n to do this?

[David Bolter]

Hi Todd. No HCM detection in jq that I know of (yet). I'm waiting (a
long time) to get a password reset email, and when I do I'll jump back
into the wiki... others, please feel free to jump in too!

Todd, for the HC theme in Themeroller are you suggesting to produce a
theme that plays nice with HC 'mode', or a theme that is simply high
contrast in nature?

cheers,
David

On Oct 15, 9:38 pm, Todd Parker <fg.t...@gmail.com> wrote:
> Hi all - The high contrast mode and AOL keyboard styleguide are all
> great. I've added them to the datepicker wiki page, but feel free to

> create and account and add all your great input directly.http://docs.jquery.com/UI/Planning/Datepicker#Accessibility_recommend...

[alexander farkas]

On 16 Okt., 04:22, David Bolter <david.bol...@gmail.com> wrote:
> No HCM detection in jq that I know of (yet).

Hi everyone,

i created some very basic HCM-Detection-Plugin for jQuery. The projet-
page is here: http://plugins.jquery.com/project/usermode.
There is no documentation yet, but you can check tis demo if you want:
http://www.protofunc.com/scripts/jquery/checkbox-radiobutton/

The script only handles user mode (high contrast mode) not pircture
off - mode.

For german speakers, here is a tutorial about the radiobutton
replacement script, that deals with high contrast mode.

[David Bolter]

Thanks Alexander!

A quick question: how did you decide on the 5 second interval in your
timer?

cheers,
David

[Scott González]

Can HCM be handled simply by not having any plugins rely on images?  For example, we handle the close button for dialogs with the following markup:

<a href="#" class="ui-dialog-titlebar-close"><span>X</span></a>

Then if you want to use an image for your close button, you just do:

.ui-dialog-titlebar-close {
    background-image: url(...);
    height: X;
    width: X;
}
.ui-dialog-titlebar-close span {
    display: none;

[alexander farkas]

> A quick question: how did you decide on the 5 second interval in your
> timer?

This is more or less accidental. i didn´t wanted to call the detection
too often. i think 5 sec are responsive enough.

[alexander farkas]

> Can HCM be handled simply by not having any plugins rely on images?

Yes and No, HCM means that foreground and backgroundcolors are set by
the user of the page. The user sees images, but not backgroundimages,
so most of the image-replacement techniques are not "allowed".


> .ui-dialog-titlebar-close span {
>     display: none;
>
> }
>

elements, that are hidden with display: none aren´t usually read by
screenreaders. you should move them out of viewport instead.

[Scott González]

On Sat, Oct 18, 2008 at 2:11 PM, alexander farkas <in...@corrupt-system.de> wrote:

> Can HCM be handled simply by not having any plugins rely on images?

Yes and No, HCM means that foreground and backgroundcolors are set by
the user of the page. The user sees images, but not backgroundimages,
so most of the image-replacement techniques are not "allowed".

I was thinking that by doing this, developers would have the flexibility to either use the default textual representation, or do the image replacement.  You could have one stylesheet that does the display: none for regular users and then load a second stylesheet that undoes the display: none for HCM.  Then you can just toggle the stylesheets wheenver the user changes to/from HCM.

> .ui-dialog-titlebar-close span {

>     display: none;
>
> }

elements, that are hidden with display: none aren´t usually read by
screenreaders. you should move them out of viewport instead.

In this specific case, wouldn't the best solution be to apply a title to the anchor tag?  By the way, is there anything in ARIA for defining that an element will cause something else to open or close?

[David Bolter]

Hi Scott,

I think a clean way to swap image for text is to have sibling elements
one that holds the 'X' and one that has the background image (with
only one ever displayed). If HCM is detected, the ascii version should
win.

So if HCM is detected, add a class to the body element: <body
class="hcmode ...">
Then for the text version have a selector .hcmode .closeboxText
{ display: inline;
For the bg image version .hcmode .closebox {display: none;

As for ARIA for an open/close question, I'm not sure what the context
is. Here's some properties to look at:
aria-controls (http://www.w3.org/TR/wai-aria/#controls)
aria-haspopup
aria-expanded

Hope that helps...

cheers,
David
On Oct 18, 3:29 pm, "Scott González" <scott.gonza...@gmail.com> wrote:

[Scott González]

Maybe there's some key problem I'm missing, but I don't see how
sibling elements provides better accessibility than nested elements.
If you have to use a stylesheet to get the proper display in either
case, where does the benefit come from?

[David Bolter]

I can't recall the advantage if there is one, but if there is I bet it
was something to do with IE, styles, and pixels ;)

I'm fine with going with the nested approach. Whatever works :)

cheers,
David

[Rich Caloggero]

I'm sure this is a naive question, but could you use the word Close instead
of simply "x" to label the control? Perhaps an option (as if there aren't
enough of those already <smile>)?

Also, is there a reason not to use a true HTML button instead of a span?
Perhaps it has to do with visual presentation - styling? I have no vision,
so have little knowledge of CSS and other than in an abstract sort of way. I
can read the code and have some abstract idea of what it does, but this is
far from actually knowing why an HTML button is not the same as a span with
a background image of a button overlayed; sounds the same to me.

-- Rich

[Scott González]

I don't see any reason that we can't change the x to close. As for
the button, I believe the current markup is solely for styling. It
provides an easy way to use CSS to hide the text and show an image
instead. Changing to a button would make image replacement tricky
because we would have to move the event handler to the element that
contains the text, so we couldn't just hide that element. Maybe this
is the reason that David suggested having sibling element instead of
nested elements. We'll definitely look into this.

[Richard D. Worth]

How about ABBR?

<abbr title="Close">X</abbr>

- Richard

[Scott González]

Thinking about this some more, I don't see any reason that we can't
keep the event handler on the div and change the span to a button.

[David Bolter]

Yes.

Tip: If styling a button nicely becomes an issue, you can keep styling
the div, and have the user interact with a transparent button
(opacity: 0.01;) inside the div.

(BTW, I liked Rich's idea of an <abbr> tag too, but it is a little
less PE)

cheers,
D

On Oct 25, 3:27 pm, "Scott González" <scott.gonza...@gmail.com> wrote:
> Thinking about this some more, I don't see any reason that we can't
> keep the event handler on the div and change the span to a button.
>

> On 10/25/08, Scott González <scott.gonza...@gmail.com> wrote:
>
> > I don't see any reason that we can't change the x to close.  As for
> > the button, I believe the current markup is solely for styling. It
> > provides an easy way to use CSS to hide the text and show an image
> > instead.  Changing to a button would make image replacement tricky
> > because we would have to move the event handler to the element that
> > contains the text, so we couldn't just hide that element.  Maybe this
> > is the reason that David suggested having sibling element instead of
> > nested elements. We'll definitely look into this.

> >> <david.bol...@gmail.com>wrote:

[ScottJehl]

Forgive me for coming in a little late on this discussion.
Regarding the close "x":
By button, do you mean an anchor or a button element? The current
markup in the dialog (at least on the live UI site) is an anchor
element with a span inside.
It seems like an anchor works well here for allowing keyboard focus
natively, as well as being a lot easier to style across browsers than
a button element.
The text inside the anchor can be whatever you'd like, as I am usually
just hiding it with negative text indent in the ThemeRoller themes.

Perhaps there should be an option for "closeLinkText" to allow for
localization as well?

-Scott

[Alexander Farkas]

ScottJehl schrieb:

> By button, do you mean an anchor or a button element? The current
> markup in the dialog (at least on the live UI site) is an anchor
> element with a span inside.

> It seems like an anchor works well here ...
>

Hi Scott,

I totally agree. I only added button semantics to this anchor via the
role-attribute.

> Perhaps there should be an option for "closeLinkText" to allow for
> localization as well?
>

I added a feature, where you can decide the innerHTML of the anchor. But
i mixed text with markup here (<span>X</span><span
class="ui-accessible-hidden"> close</span>). For simple localization
this should be ok. But jquery ui code standards seem to strongly
seperate text from markup options.
> -Scott
>
>
> >
>

[Scott González]

Rich,

Any objections to an anchor tag with a role of button rather than an
actual button element?

[Scott González]

The close link now has a role of button. See http://ui.jquery.com/bugs/ticket/3637

[Scott González]

I also created a ticket to allow the user to change the close text
( http://ui.jquery.com/bugs/ticket/3638 ). Even though this is
extremely easy to implement, I'm waiting until we figure out how we
want to handle i18n in UI. I'll discuss this with the other team
leads and see if they're okay with adding this option now and then
changing it when we support i18n across all plugins.

[Scott González]

I decided to start a thread in the dev list instead ( http://groups.google.com/group/jquery-ui-dev/browse_thread/thread/c0def8715cda5bd7 ).

[Rich Caloggero]

I'm working with a client who needs this functionality to work with the Jaws
screen reader. After testing both with Jaws and with NVDA, I've found the
current version (1.8rc3) does not work with these assistive technologies.

I've found a workaround which seems to do the right thing. Instead of
tagging the menu with role "menu", use role "listbox" instead. Now both
screen readers speak the item currently selected when you press arrow keys.

Here's the appropriate function starting at line 311 from
...\development-bundle\ui\jquery.ui.autocomplete.js

...
$.widget("ui.menu", {
_create: function() {
var self = this;
this.element
.addClass("ui-menu ui-widget ui-widget-content ui-corner-all")
.attr({
role: "listbox",
"aria-activedescendant": "ui-active-menuitem"
})
.click(function(e) {
// temporary
e.preventDefault();
self.select();
});
this.refresh();
},
...

[Richard D. Worth]

Thanks Rich. Now fixed in trunk:

http://dev.jqueryui.com/ticket/5368

http://dev.jqueryui.com/changeset/3942

- Richard

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