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

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

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

> 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

> On Oct 14, 5:32 pm, Todd Parker <fg.t...@gmail.com> wrote:
> > 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.

> }

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

> > }

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

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

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

> > On Sat, Oct 18, 2008 at 2:11 PM, alexander farkas <i...@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?

> On Oct 18, 10:25 pm, David Bolter <david.bol...@gmail.com> wrote:

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

> > > On Sat, Oct 18, 2008 at 2:11 PM, alexander farkas <i...@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?

planning

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;
}

On Tue, Oct 14, 2008 at 10:04 PM, David Bolter
<david.bol...@gmail.com>wrote:

> 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

> On Oct 14, 5:32 pm, Todd Parker <fg.t...@gmail.com> wrote:
> > 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.

> 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

> ----- Original Message -----
> From: "Scott González" <scott.gonza...@gmail.com>
> To: <jquery-a11y@googlegroups.com>
> Sent: Saturday, October 18, 2008 12:10 PM
> Subject: Re: High Contrast Mode and Re: New wiki pages for widget design
> planning

> 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;
> }

> On Tue, Oct 14, 2008 at 10:04 PM, David Bolter
> <david.bol...@gmail.com>wrote:

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

>> On Oct 14, 5:32 pm, Todd Parker <fg.t...@gmail.com> wrote:
>> > 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.

> 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.
> On 10/24/08, Rich Caloggero <rich_calogg...@wgbh.org> wrote:

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

> > ----- Original Message -----
> > From: "Scott González" <scott.gonza...@gmail.com>
> > To: <jquery-a11y@googlegroups.com>
> > Sent: Saturday, October 18, 2008 12:10 PM
> > Subject: Re: High Contrast Mode and Re: New wiki pages for widget design
> > planning

> > 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;
> > }

> > On Tue, Oct 14, 2008 at 10:04 PM, David Bolter
> > <david.bol...@gmail.com>wrote:

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

> >> On Oct 14, 5:32 pm, Todd Parker <fg.t...@gmail.com> wrote:
> >> > 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.

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

>> ----- Original Message -----
>> From: "Scott González" <scott.gonza...@gmail.com>
>> To: <jquery-a11y@googlegroups.com>
>> Sent: Saturday, October 18, 2008 12:10 PM
>> Subject: Re: High Contrast Mode and Re: New wiki pages for widget design
>> planning

>> 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;
>> }

>> On Tue, Oct 14, 2008 at 10:04 PM, David Bolter
>> <david.bol...@gmail.com>wrote:

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

>>> On Oct 14, 5:32 pm, Todd Parker <fg.t...@gmail.com> wrote:
>>> > 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.

> 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.
> > On 10/24/08, Rich Caloggero <rich_calogg...@wgbh.org> wrote:

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

> >> ----- Original Message -----
> >> From: "Scott González" <scott.gonza...@gmail.com>
> >> To: <jquery-a11y@googlegroups.com>
> >> Sent: Saturday, October 18, 2008 12:10 PM
> >> Subject: Re: High Contrast Mode and Re: New wiki pages for widget design
> >> planning

> >> 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;
> >> }

> >> On Tue, Oct 14, 2008 at 10:04 PM, David Bolter
> >> <david.bol...@gmail.com>wrote:

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

> >>> On Oct 14, 5:32 pm, Todd Parker <fg.t...@gmail.com> wrote:
> >>> > 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.

> 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

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