E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 30 (In chronological order)

From: adam solomon
Date: Tue, Feb 08 2011 3:06AM
Subject: does datepicker have to be accessible
No previous message | Next message →

Scenario: a textbox meant to have a date written in it. A button next to it
(calendar icon) which opens the datepicker to choose a date. One can enter a
date manually into the textbox, as well. Does the datepicker need to be
accessible, or is it enough that the user can manually enter a date into it
without making use of the datepicker? How should the format of the date to
be entered be communicated to a screen reader user in an unobtrusive manner?
Thanks in advance

--
adam solomon
linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
blogix <http://adam.blogix.co.il/>;

From: Jadhav, Ashitosh
Date: Tue, Feb 08 2011 3:21AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

I faced the same issue and got a better solution of inserting 3 dropdowns for Day, Month and year. The Screen Reader reads it with the labels as select Day and so on..

From: Joe Chidzik
Date: Tue, Feb 08 2011 4:30AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

I wouldn't have a problem with a date picker that wasn't accessible as long as the text input field could be used directly, as you've mentioned, to enter the date into manually. I would have a problem, however, if the only way of entering a date was via an inaccessible control.

The date format could be part of the input field label e.g.

Enter date (mm/dd/yyyy); this would let screenreader users know the correct format for entering a date.

For an example of an accessible date pickers, have a look at:
http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/#datepicker

Joe

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of adam solomon
Sent: 08 February 2011 10:03
To: WebAIM Discussion List
Subject: [WebAIM] does datepicker have to be accessible

Scenario: a textbox meant to have a date written in it. A button next to it
(calendar icon) which opens the datepicker to choose a date. One can enter a
date manually into the textbox, as well. Does the datepicker need to be
accessible, or is it enough that the user can manually enter a date into it
without making use of the datepicker? How should the format of the date to
be entered be communicated to a screen reader user in an unobtrusive manner?
Thanks in advance

--
adam solomon
linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
blogix <http://adam.blogix.co.il/>;

From: Accessibility India
Date: Tue, Feb 08 2011 6:00AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> Scenario: a textbox meant to have a date written in it. A button next to it
> (calendar icon) which opens the datepicker to choose a date. One can enter a
> date manually into the textbox, as well. Does the datepicker need to be
> accessible, or is it enough that the user can manually enter a date into it
> without making use of the datepicker? How should the format of the date to
> be entered be communicated to a screen reader user in an unobtrusive manner?
> Thanks in advance
>
> --
> adam solomon
> linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
> blogix <http://adam.blogix.co.il/>;
>

From: Accessibility India
Date: Tue, Feb 08 2011 6:12AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

sorry for the blank message.. my typo..
Yes the date picker also should be accessible. We should not provide
the users of different abilities in a separate way of interacting with
the web content. Make the calender icon as a key board focusable
event. on clicking the calender icon the user should be focus to the
layer where the calender opens.
Pic the date and by entering on the date the input field should be
updated and the focus should come back to the calender icon by closing
the calander.
Clear instruction should be given to enter the date in correct format
in the input field manually.
Thankyou
Rakesh

On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> Scenario: a textbox meant to have a date written in it. A button next to it
> (calendar icon) which opens the datepicker to choose a date. One can enter a
> date manually into the textbox, as well. Does the datepicker need to be
> accessible, or is it enough that the user can manually enter a date into it
> without making use of the datepicker? How should the format of the date to
> be entered be communicated to a screen reader user in an unobtrusive manner?
> Thanks in advance
>
> --
> adam solomon
> linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
> blogix <http://adam.blogix.co.il/>;
>

From: adam solomon
Date: Tue, Feb 08 2011 6:21AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

In many cases accessibility guidelines provide for alternative content for
disabled users. Why would this not classify as one of those instances, as
the loss here is a small amount of convenience of picking the date, and, in
fact, for a screen reader user it is probably easier typing the date rather
than navigating through a datepicker.

On Tue, Feb 8, 2011 at 3:07 PM, Accessibility India <
= EMAIL ADDRESS REMOVED = > wrote:

> sorry for the blank message.. my typo..
> Yes the date picker also should be accessible. We should not provide
> the users of different abilities in a separate way of interacting with
> the web content. Make the calender icon as a key board focusable
> event. on clicking the calender icon the user should be focus to the
> layer where the calender opens.
> Pic the date and by entering on the date the input field should be
> updated and the focus should come back to the calender icon by closing
> the calander.
> Clear instruction should be given to enter the date in correct format
> in the input field manually.
> Thankyou
> Rakesh
>
> On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> > Scenario: a textbox meant to have a date written in it. A button next to
> it
> > (calendar icon) which opens the datepicker to choose a date. One can
> enter a
> > date manually into the textbox, as well. Does the datepicker need to be
> > accessible, or is it enough that the user can manually enter a date into
> it
> > without making use of the datepicker? How should the format of the date
> to
> > be entered be communicated to a screen reader user in an unobtrusive
> manner?
> > Thanks in advance
> >
> > --
> > adam solomon
> > linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
> > blogix <http://adam.blogix.co.il/>;
> >

From: Accessibility India
Date: Tue, Feb 08 2011 6:30AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> In many cases accessibility guidelines provide for alternative content for
> disabled users. Why would this not classify as one of those instances, as
> the loss here is a small amount of convenience of picking the date, and, in
> fact, for a screen reader user it is probably easier typing the date rather
> than navigating through a datepicker.
Yes Adam, Accessibility guidelines may use alternate methods in some
instances mostly where the content may not be accessible in the
straight way. When we can make any technology accessible there is no
point in denying to make it accessible.
Yes me as a screen reader user I do agree that input the text is
simple but picking date from date picker is not complex if we are able
to make it accessible.


> On Tue, Feb 8, 2011 at 3:07 PM, Accessibility India <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> sorry for the blank message.. my typo..
>> Yes the date picker also should be accessible. We should not provide
>> the users of different abilities in a separate way of interacting with
>> the web content. Make the calender icon as a key board focusable
>> event. on clicking the calender icon the user should be focus to the
>> layer where the calender opens.
>> Pic the date and by entering on the date the input field should be
>> updated and the focus should come back to the calender icon by closing
>> the calander.
>> Clear instruction should be given to enter the date in correct format
>> in the input field manually.
>> Thankyou
>> Rakesh
>>
>> On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
>> > Scenario: a textbox meant to have a date written in it. A button next to
>> it
>> > (calendar icon) which opens the datepicker to choose a date. One can
>> enter a
>> > date manually into the textbox, as well. Does the datepicker need to be
>> > accessible, or is it enough that the user can manually enter a date into
>> it
>> > without making use of the datepicker? How should the format of the date
>> to
>> > be entered be communicated to a screen reader user in an unobtrusive
>> manner?
>> > Thanks in advance
>> >
>> > --
>> > adam solomon
>> > linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
>> > blogix <http://adam.blogix.co.il/>;
>> >

From: Susan Grossman
Date: Tue, Feb 08 2011 7:15AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

>> Scenario: a textbox meant to have a date written in it. A button next to
it
(calendar icon) which opens the datepicker to choose a date. One can enter a
date manually into the textbox, as well. Does the datepicker need to be
accessible, or is it enough that the user can manually enter a date into it
without making use of the datepicker?


--- Often the accessible date-pickers are more work than just typing it in
and is something you should consider. As long as the format is clear, as
stated by others, having a text box is just fine.

There's nothing wrong with enhancing things for a user who doesn't need AT's
as long as the main function works well for all. You can use colors the
color-blind can't see as long as the contrast is there for them....


--
*Susan R. Grossman*
= EMAIL ADDRESS REMOVED =

From: Birkir Rúnar Gunnarsson
Date: Tue, Feb 08 2011 7:36AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

I would be fine with an input edit field, but I do recommend the
solution with 3 listboxes, month, day, year (or whichever order). This
will also simplify validation on the server side of the input format.
One thing I, as a user, find annoying is when the mm/dd/yyyy is in the
label for the field, Jaws does not clearly distinguish between this
and mm/dd/yy, so I would suggest a sample format such as (please enter
your date, for instance 01/01/2000). This way the format is conveyed
unambiguously to someone who only uses speech.
If there are limits on th dates you can enter (such as a booking
system that only accepts bookings till the end of the year), please
indicate that as well.
hth
-B

On 2/8/11, Susan Grossman < = EMAIL ADDRESS REMOVED = > wrote:
>>> Scenario: a textbox meant to have a date written in it. A button next to
> it
> (calendar icon) which opens the datepicker to choose a date. One can enter a
> date manually into the textbox, as well. Does the datepicker need to be
> accessible, or is it enough that the user can manually enter a date into it
> without making use of the datepicker?
>
>
> --- Often the accessible date-pickers are more work than just typing it in
> and is something you should consider. As long as the format is clear, as
> stated by others, having a text box is just fine.
>
> There's nothing wrong with enhancing things for a user who doesn't need AT's
> as long as the main function works well for all. You can use colors the
> color-blind can't see as long as the contrast is there for them....
>
>
> --
> *Susan R. Grossman*
> = EMAIL ADDRESS REMOVED =
>

From: Mary Stores
Date: Tue, Feb 08 2011 7:42AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Hello,

If the date picker isn't accessible, to me having a text box with an
appropriate label like someone said in a previous message is fine. As a
screen reader user, I find it easier to just type in the date as long
as I know what format to put it in. It's much quicker to do it that way
than to use combo boxes to select the month, date and year. And as long
as you have an accessible alternative like that, I don't think you are
violating any guidelines.

Mary

Quoting Accessibility India < = EMAIL ADDRESS REMOVED = >:

> sorry for the blank message.. my typo..
> Yes the date picker also should be accessible. We should not provide
> the users of different abilities in a separate way of interacting with
> the web content. Make the calender icon as a key board focusable
> event. on clicking the calender icon the user should be focus to the
> layer where the calender opens.
> Pic the date and by entering on the date the input field should be
> updated and the focus should come back to the calender icon by closing
> the calander.
> Clear instruction should be given to enter the date in correct format
> in the input field manually.
> Thankyou
> Rakesh
>

From: Michael.Moore@dars.state.tx.us
Date: Tue, Feb 08 2011 7:48AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Since enter date (mm/dd/yyyy) is not very screen reader friendly since the screen reader (JFW) will say "Yi Yi" for the year. We usually do something like "two digit month, slash two digit day, slash four digit year." Then we capture whatever the user puts in, make sure that there are enough digits and reformat as necessary in the validation script. You can place the text for the formatting as the alt text for a 1px gif located within the label.

Mike Moore


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Joe Chidzik
Sent: Tuesday, February 08, 2011 5:29 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

I wouldn't have a problem with a date picker that wasn't accessible as long as the text input field could be used directly, as you've mentioned, to enter the date into manually. I would have a problem, however, if the only way of entering a date was via an inaccessible control.

The date format could be part of the input field label e.g.

Enter date (mm/dd/yyyy); this would let screenreader users know the correct format for entering a date.

For an example of an accessible date pickers, have a look at:
http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/#datepicker

Joe

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of adam solomon
Sent: 08 February 2011 10:03
To: WebAIM Discussion List
Subject: [WebAIM] does datepicker have to be accessible

Scenario: a textbox meant to have a date written in it. A button next to it
(calendar icon) which opens the datepicker to choose a date. One can enter a
date manually into the textbox, as well. Does the datepicker need to be
accessible, or is it enough that the user can manually enter a date into it
without making use of the datepicker? How should the format of the date to
be entered be communicated to a screen reader user in an unobtrusive manner?
Thanks in advance

--
adam solomon
linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
blogix <http://adam.blogix.co.il/>;

From: Birkir Rúnar Gunnarsson
Date: Tue, Feb 08 2011 7:54AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Hi Andrew

There is a pattern recognition capability, at least in the higher
versions of Jaws, and you can specify rules for how patterns are
pronounced (I am 99% sure, I use a braille display so I tend not to
use it much).
It depends on the version and the screen reader you have, whether and
how they pronounced different things such as phone numbers.
I have not come across a screen reader yet that pronounced dd/mm/yyyy
or mm/dd/yyyy distinctly enough.
But, like you said, may be this is actually one for the screen reader
manufacturers, since it is common practice and this format can hardly
be confused with anything else (the chances of dd/mm/yyyy being
anything other than a date template or placeholder are remote).
I'll jot this down and suggest it to the SR representatives at CSUN.
Thanks
-B

On 2/8/11, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir,
> This is an interesting problem - JAWS does allow you to configure the
> reading for repeated letters, but this makes reading tedious in other ways
> (e.g. when someone puts a line of periods or dashes as part of their email
> sig). The default setting also means that if my phone number is
> 123-456-0000 that you won't hear it correctly, won't it?
>
> I wonder whether screen reader vendors have considered parsing the text and
> analyzing whether there is a phone number or a common date identifier. They
> should - I doubt that many people will stop using mm/dd/yyyy since it is
> short, and also avoids confusion for people who might enter the date as
> dd/mm/yyyy....
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
>
> = EMAIL ADDRESS REMOVED =
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar
> Gunnarsson
> Sent: Tuesday, February 08, 2011 9:33 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] does datepicker have to be accessible
>
> I would be fine with an input edit field, but I do recommend the
> solution with 3 listboxes, month, day, year (or whichever order). This
> will also simplify validation on the server side of the input format.
> One thing I, as a user, find annoying is when the mm/dd/yyyy is in the
> label for the field, Jaws does not clearly distinguish between this
> and mm/dd/yy, so I would suggest a sample format such as (please enter
> your date, for instance 01/01/2000). This way the format is conveyed
> unambiguously to someone who only uses speech.
> If there are limits on th dates you can enter (such as a booking
> system that only accepts bookings till the end of the year), please
> indicate that as well.
> hth
> -B
>
> On 2/8/11, Susan Grossman < = EMAIL ADDRESS REMOVED = > wrote:
>>>> Scenario: a textbox meant to have a date written in it. A button next to
>> it
>> (calendar icon) which opens the datepicker to choose a date. One can enter
>> a
>> date manually into the textbox, as well. Does the datepicker need to be
>> accessible, or is it enough that the user can manually enter a date into
>> it
>> without making use of the datepicker?
>>
>>
>> --- Often the accessible date-pickers are more work than just typing it in
>> and is something you should consider. As long as the format is clear, as
>> stated by others, having a text box is just fine.
>>
>> There's nothing wrong with enhancing things for a user who doesn't need
>> AT's
>> as long as the main function works well for all. You can use colors the
>> color-blind can't see as long as the contrast is there for them....
>>
>>
>> --
>> *Susan R. Grossman*
>> = EMAIL ADDRESS REMOVED =
>>

From: Andrew Kirkpatrick
Date: Tue, Feb 08 2011 8:00AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Birkir,
This is an interesting problem - JAWS does allow you to configure the reading for repeated letters, but this makes reading tedious in other ways (e.g. when someone puts a line of periods or dashes as part of their email sig). The default setting also means that if my phone number is 123-456-0000 that you won't hear it correctly, won't it?

I wonder whether screen reader vendors have considered parsing the text and analyzing whether there is a phone number or a common date identifier. They should - I doubt that many people will stop using mm/dd/yyyy since it is short, and also avoids confusion for people who might enter the date as dd/mm/yyyy....

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar Gunnarsson
Sent: Tuesday, February 08, 2011 9:33 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

I would be fine with an input edit field, but I do recommend the
solution with 3 listboxes, month, day, year (or whichever order). This
will also simplify validation on the server side of the input format.
One thing I, as a user, find annoying is when the mm/dd/yyyy is in the
label for the field, Jaws does not clearly distinguish between this
and mm/dd/yy, so I would suggest a sample format such as (please enter
your date, for instance 01/01/2000). This way the format is conveyed
unambiguously to someone who only uses speech.
If there are limits on th dates you can enter (such as a booking
system that only accepts bookings till the end of the year), please
indicate that as well.
hth
-B

On 2/8/11, Susan Grossman < = EMAIL ADDRESS REMOVED = > wrote:
>>> Scenario: a textbox meant to have a date written in it. A button next to
> it
> (calendar icon) which opens the datepicker to choose a date. One can enter a
> date manually into the textbox, as well. Does the datepicker need to be
> accessible, or is it enough that the user can manually enter a date into it
> without making use of the datepicker?
>
>
> --- Often the accessible date-pickers are more work than just typing it in
> and is something you should consider. As long as the format is clear, as
> stated by others, having a text box is just fine.
>
> There's nothing wrong with enhancing things for a user who doesn't need AT's
> as long as the main function works well for all. You can use colors the
> color-blind can't see as long as the contrast is there for them....
>
>
> --
> *Susan R. Grossman*
> = EMAIL ADDRESS REMOVED =
>

From: Mary Stores
Date: Tue, Feb 08 2011 8:45AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Hello,

Birkir is correct. In JAWS 11, you can control the way JAWS speaks
numbers by adjusting the settings in the Configuration Manager. For
example, you can have JAWS read 02-08-10 as "February 8, two thousand
ten." 02-08 can be read as "February 8."

As far as numbers themselves go, you can have JAWS read 123 as "one two
three," or "one hundred twenty-three." You can set JAWS to read numbers
in pairs, and if there's an odd digit, JAWS will read that one first
and pair the rest of the numbers. You can also adjust the number
threshold, so if you want a phone number or serial number read as
single digits, you can have JAWS pronounce all the number as single
digitsIf the number has dashes in it, you can control how JAWS speaks
those numbers as well.

As far as "mm/dd/yyyy" goes, I don't see anything wrong with pressing
ctrl-left arrow to that word and then right-arrowing through to see how
the format should go. It's good enough for me if the format is
specified.

Mary

Quoting Birkir Rúnar Gunnarsson < = EMAIL ADDRESS REMOVED = >:

> Hi Andrew
>
> There is a pattern recognition capability, at least in the higher
> versions of Jaws, and you can specify rules for how patterns are
> pronounced (I am 99% sure, I use a braille display so I tend not to
> use it much).
> It depends on the version and the screen reader you have, whether and
> how they pronounced different things such as phone numbers.
> I have not come across a screen reader yet that pronounced dd/mm/yyyy
> or mm/dd/yyyy distinctly enough.
> But, like you said, may be this is actually one for the screen reader
> manufacturers, since it is common practice and this format can hardly
> be confused with anything else (the chances of dd/mm/yyyy being
> anything other than a date template or placeholder are remote).
> I'll jot this down and suggest it to the SR representatives at CSUN.
> Thanks
> -B
>
> On 2/8/11, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
>> Birkir,
>> This is an interesting problem - JAWS does allow you to configure the
>> reading for repeated letters, but this makes reading tedious in other ways
>> (e.g. when someone puts a line of periods or dashes as part of their email
>> sig). The default setting also means that if my phone number is
>> 123-456-0000 that you won't hear it correctly, won't it?
>>
>> I wonder whether screen reader vendors have considered parsing the text and
>> analyzing whether there is a phone number or a common date identifier. They
>> should - I doubt that many people will stop using mm/dd/yyyy since it is
>> short, and also avoids confusion for people who might enter the date as
>> dd/mm/yyyy....
>>
>> Thanks,
>> AWK
>>
>> Andrew Kirkpatrick
>> Group Product Manager, Accessibility
>> Adobe Systems
>>
>> = EMAIL ADDRESS REMOVED =
>> http://twitter.com/awkawk
>> http://blogs.adobe.com/accessibility
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar
>> Gunnarsson
>> Sent: Tuesday, February 08, 2011 9:33 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] does datepicker have to be accessible
>>
>> I would be fine with an input edit field, but I do recommend the
>> solution with 3 listboxes, month, day, year (or whichever order). This
>> will also simplify validation on the server side of the input format.
>> One thing I, as a user, find annoying is when the mm/dd/yyyy is in the
>> label for the field, Jaws does not clearly distinguish between this
>> and mm/dd/yy, so I would suggest a sample format such as (please enter
>> your date, for instance 01/01/2000). This way the format is conveyed
>> unambiguously to someone who only uses speech.
>> If there are limits on th dates you can enter (such as a booking
>> system that only accepts bookings till the end of the year), please
>> indicate that as well.
>> hth
>> -B
>>
>> On 2/8/11, Susan Grossman < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> Scenario: a textbox meant to have a date written in it. A button next to
>>> it
>>> (calendar icon) which opens the datepicker to choose a date. One can enter
>>> a
>>> date manually into the textbox, as well. Does the datepicker need to be
>>> accessible, or is it enough that the user can manually enter a date into
>>> it
>>> without making use of the datepicker?
>>>
>>>
>>> --- Often the accessible date-pickers are more work than just typing it in
>>> and is something you should consider. As long as the format is clear, as
>>> stated by others, having a text box is just fine.
>>>
>>> There's nothing wrong with enhancing things for a user who doesn't need
>>> AT's
>>> as long as the main function works well for all. You can use colors the
>>> color-blind can't see as long as the contrast is there for them....
>>>
>>>
>>> --
>>> *Susan R. Grossman*
>>> = EMAIL ADDRESS REMOVED =
>>>

From: Birkir Rúnar Gunnarsson
Date: Tue, Feb 08 2011 9:03AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Terrill

Not to wear too far off topic, but how did you record screen readers
reading phrases?
I need to do just that for a math reading demonstration, but my
Windows recorder does not pick up sound from my soundcard output.
So if you have an accessible light recording software I can use to
record screen reader speech, please email me, on or off-list.
Thanks
-B

On 2/8/11, Terrill Bennett < = EMAIL ADDRESS REMOVED = > wrote:
> AWK said:
>
> "I wonder whether screen reader vendors have considered parsing the
> text and analyzing whether there is a phone number or a common date
> identifier. They should - I doubt that many people will stop using
> mm/dd/yyyy since it is short, and also avoids confusion for people
> who might enter the date as dd/mm/yyyy...."
> -----------------------------------
>
> Some of how data is read is left to your choice of what voice and/or
> synthesizer you use with your screen reader. I have recorded NVDA
> using the default eSpeak (Max) vs. the SAPI 5 with both NaturalVoice
> (Crystal) and Microsoft (Mike). There are very notable differences!
>
> eSpeak Max doesn't do great job. Crystal does nicely. Mike does ok,
> if he just didn't read the MM in "MM DD YY" as "millimeters!" Mike
> even says "area code" in both phone numbers.
>
> No other settings were changed other than switching synthesizers and
> voices. Here are my recordings:
>
> http://bennett1.org/webAim/datephone/
>
> -- terrill --
>
>

From: Terrill Bennett
Date: Tue, Feb 08 2011 9:15AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Birkir,

Wish I could say I hold the magic dust, but sorry to report I'm a
sighted user with the open source Audacity doing the recording. Yes,
I've searched for an accessible, free recorder also. To date, I
haven't found one that works with NVDA.

Perhaps we will get lucky, and someone will change the topic and
supply a link to an accessible (and possibly free) recorder?

-- terrill --

At 11:04 AM 2/8/2011, you wrote:
>Terrill
>
>Not to wear too far off topic, but how did you record screen readers
>reading phrases?
>I need to do just that for a math reading demonstration, but my
>Windows recorder does not pick up sound from my soundcard output.
>So if you have an accessible light recording software I can use to
>record screen reader speech, please email me, on or off-list.
>Thanks
>-B

From: Terrill Bennett
Date: Tue, Feb 08 2011 9:21AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

AWK said:

"I wonder whether screen reader vendors have considered parsing the
text and analyzing whether there is a phone number or a common date
identifier. They should - I doubt that many people will stop using
mm/dd/yyyy since it is short, and also avoids confusion for people
who might enter the date as dd/mm/yyyy...."
-----------------------------------

Some of how data is read is left to your choice of what voice and/or
synthesizer you use with your screen reader. I have recorded NVDA
using the default eSpeak (Max) vs. the SAPI 5 with both NaturalVoice
(Crystal) and Microsoft (Mike). There are very notable differences!

eSpeak Max doesn't do great job. Crystal does nicely. Mike does ok,
if he just didn't read the MM in "MM DD YY" as "millimeters!" Mike
even says "area code" in both phone numbers.

No other settings were changed other than switching synthesizers and
voices. Here are my recordings:

http://bennett1.org/webAim/datephone/

-- terrill --

From: Claudia.Case@wellsfargo.com
Date: Tue, Feb 08 2011 12:15PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

One option I've used is the free trial version of Camtasia. Here's the URL:
http://www.techsmith.com/download/camtasia/

claudia case

-----Original Message-----
From: Terrill Bennett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, February 08, 2011 8:11 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

Birkir,

Wish I could say I hold the magic dust, but sorry to report I'm a
sighted user with the open source Audacity doing the recording. Yes,
I've searched for an accessible, free recorder also. To date, I
haven't found one that works with NVDA.

Perhaps we will get lucky, and someone will change the topic and
supply a link to an accessible (and possibly free) recorder?

-- terrill --

At 11:04 AM 2/8/2011, you wrote:
>Terrill
>
>Not to wear too far off topic, but how did you record screen readers
>reading phrases?
>I need to do just that for a math reading demonstration, but my
>Windows recorder does not pick up sound from my soundcard output.
>So if you have an accessible light recording software I can use to
>record screen reader speech, please email me, on or off-list.
>Thanks
>-B

From: Keith (mteye)
Date: Wed, Feb 09 2011 11:00AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

I use WavePad audio editor for synthesized speech recording. Here's the
download page to get it for free. I think it runs for 30 days, then locks
out a lot of the special tools. NCHS is an Australian company, and the cost
varies due to the current exchange rate, but it typically runs from $40 to
$50 or so for the paid product.

http://www.nch.com.au/wavepad/index.html

It can switch to any SAPI4 or 5 voice you have on your computer.

from
Keith H


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
Sent: Tuesday, February 08, 2011 1:10 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] does datepicker have to be accessible

One option I've used is the free trial version of Camtasia. Here's the URL:
http://www.techsmith.com/download/camtasia/

claudia case

-----Original Message-----
From: Terrill Bennett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, February 08, 2011 8:11 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

Birkir,

Wish I could say I hold the magic dust, but sorry to report I'm a
sighted user with the open source Audacity doing the recording. Yes,
I've searched for an accessible, free recorder also. To date, I
haven't found one that works with NVDA.

Perhaps we will get lucky, and someone will change the topic and
supply a link to an accessible (and possibly free) recorder?

-- terrill --

At 11:04 AM 2/8/2011, you wrote:
>Terrill
>
>Not to wear too far off topic, but how did you record screen readers
>reading phrases?
>I need to do just that for a math reading demonstration, but my
>Windows recorder does not pick up sound from my soundcard output.
>So if you have an accessible light recording software I can use to
>record screen reader speech, please email me, on or off-list.
>Thanks
>-B

From: ckrugman@sbcglobal.net
Date: Fri, Feb 11 2011 11:24PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

there are many sites where it has been made accessible and as a screen
reader I prefer using it at times or being able to have the choices. As a
screen reader I don't particularly like my choices being made for me because
someone has chosen to cut corners. When corners are cut it undermines the
whole concept and purpose of accessibility.
Chuck
----- Original Message -----
From: "Accessibility India" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, February 08, 2011 5:26 AM
Subject: Re: [WebAIM] does datepicker have to be accessible


> On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
>> In many cases accessibility guidelines provide for alternative content
>> for
>> disabled users. Why would this not classify as one of those instances, as
>> the loss here is a small amount of convenience of picking the date, and,
>> in
>> fact, for a screen reader user it is probably easier typing the date
>> rather
>> than navigating through a datepicker.
> Yes Adam, Accessibility guidelines may use alternate methods in some
> instances mostly where the content may not be accessible in the
> straight way. When we can make any technology accessible there is no
> point in denying to make it accessible.
> Yes me as a screen reader user I do agree that input the text is
> simple but picking date from date picker is not complex if we are able
> to make it accessible.
>
>
>> On Tue, Feb 8, 2011 at 3:07 PM, Accessibility India <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> sorry for the blank message.. my typo..
>>> Yes the date picker also should be accessible. We should not provide
>>> the users of different abilities in a separate way of interacting with
>>> the web content. Make the calender icon as a key board focusable
>>> event. on clicking the calender icon the user should be focus to the
>>> layer where the calender opens.
>>> Pic the date and by entering on the date the input field should be
>>> updated and the focus should come back to the calender icon by closing
>>> the calander.
>>> Clear instruction should be given to enter the date in correct format
>>> in the input field manually.
>>> Thankyou
>>> Rakesh
>>>
>>> On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
>>> > Scenario: a textbox meant to have a date written in it. A button next
>>> > to
>>> it
>>> > (calendar icon) which opens the datepicker to choose a date. One can
>>> enter a
>>> > date manually into the textbox, as well. Does the datepicker need to
>>> > be
>>> > accessible, or is it enough that the user can manually enter a date
>>> > into
>>> it
>>> > without making use of the datepicker? How should the format of the
>>> > date
>>> to
>>> > be entered be communicated to a screen reader user in an unobtrusive
>>> manner?
>>> > Thanks in advance
>>> >
>>> > --
>>> > adam solomon
>>> > linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
>>> > blogix <http://adam.blogix.co.il/>;
>>> >

From: adam solomon
Date: Sat, Feb 12 2011 12:15PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

With all due respect to the needs of those who require accessible sites, one
has to be practical. The level of accessibility on the web in general is
pretty low. I think the addition of a datepicker is one of the last things
we should be making a fuss about. Despite the fact that accessible web sites
shouldn't come at a high expense, the reality is that companies who are
implementing accessibility are spending a lot of money on it. Just to take
an example, our department contracted out a large (not gigantic) web app to
be developed. After the contract was finished, they thought about
accessibility, and the company which received the contract wanted an extra
$10,000 to make it accessible. That comes out of taxpayer money. I am all
for implementing accessibility, but at some point we have to consider the
cost, if only to avoid a situation where high costs provide ammunition to
those who would torpedo the cause altogether.

On Sat, Feb 12, 2011 at 8:24 AM, < = EMAIL ADDRESS REMOVED = > wrote:

> there are many sites where it has been made accessible and as a screen
> reader I prefer using it at times or being able to have the choices. As a
> screen reader I don't particularly like my choices being made for me
> because
> someone has chosen to cut corners. When corners are cut it undermines the
> whole concept and purpose of accessibility.
> Chuck
> ----- Original Message -----
> From: "Accessibility India" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, February 08, 2011 5:26 AM
> Subject: Re: [WebAIM] does datepicker have to be accessible
>
>
> > On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> >> In many cases accessibility guidelines provide for alternative content
> >> for
> >> disabled users. Why would this not classify as one of those instances,
> as
> >> the loss here is a small amount of convenience of picking the date, and,
> >> in
> >> fact, for a screen reader user it is probably easier typing the date
> >> rather
> >> than navigating through a datepicker.
> > Yes Adam, Accessibility guidelines may use alternate methods in some
> > instances mostly where the content may not be accessible in the
> > straight way. When we can make any technology accessible there is no
> > point in denying to make it accessible.
> > Yes me as a screen reader user I do agree that input the text is
> > simple but picking date from date picker is not complex if we are able
> > to make it accessible.
> >
> >
> >> On Tue, Feb 8, 2011 at 3:07 PM, Accessibility India <
> >> = EMAIL ADDRESS REMOVED = > wrote:
> >>
> >>> sorry for the blank message.. my typo..
> >>> Yes the date picker also should be accessible. We should not provide
> >>> the users of different abilities in a separate way of interacting with
> >>> the web content. Make the calender icon as a key board focusable
> >>> event. on clicking the calender icon the user should be focus to the
> >>> layer where the calender opens.
> >>> Pic the date and by entering on the date the input field should be
> >>> updated and the focus should come back to the calender icon by closing
> >>> the calander.
> >>> Clear instruction should be given to enter the date in correct format
> >>> in the input field manually.
> >>> Thankyou
> >>> Rakesh
> >>>
> >>> On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> >>> > Scenario: a textbox meant to have a date written in it. A button next
> >>> > to
> >>> it
> >>> > (calendar icon) which opens the datepicker to choose a date. One can
> >>> enter a
> >>> > date manually into the textbox, as well. Does the datepicker need to
> >>> > be
> >>> > accessible, or is it enough that the user can manually enter a date
> >>> > into
> >>> it
> >>> > without making use of the datepicker? How should the format of the
> >>> > date
> >>> to
> >>> > be entered be communicated to a screen reader user in an unobtrusive
> >>> manner?
> >>> > Thanks in advance
> >>> >
> >>> > --
> >>> > adam solomon
> >>> > linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
> >>> > blogix <http://adam.blogix.co.il/>;
> >>> >

From: Benjamin Hawkes-Lewis
Date: Sat, Feb 12 2011 12:39PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

On Sat, Feb 12, 2011 at 7:14 PM, adam solomon
< = EMAIL ADDRESS REMOVED = > wrote:
> With all due respect to the needs of those who require accessible sites, one
> has to be practical. The level of accessibility on the web in general is
> pretty low. I think the addition of a datepicker is one of the last things
> we should be making a fuss about. Despite the fact that accessible web sites
> shouldn't come at a high expense, the reality is that companies who are
> implementing accessibility are spending a lot of money on it. Just to take
> an example, our department contracted out a large (not gigantic) web app to
> be developed. After the contract was finished, they thought about
> accessibility, and the company which received the contract wanted an extra
> $10,000 to make it accessible. That comes out of taxpayer money. I am all
> for implementing accessibility, but at some point we have to consider the
> cost, if only to avoid a situation where high costs provide ammunition to
> those who would torpedo the cause altogether.

Your anecdote is likely an illustration of the expense of retrofitting
a quality that needs to permeate an entire system as opposed to a mere
feature, not the intrinsic cost of accessibility. It would also be
expensive to retrofit security if that had not been considered during
the design phase.

If the date picker has not been built yet, there's no good reason not
to pick an accessible implementation.

There's a usability gap if users are presented with controls they
cannot use in the DOM.

--
Benjamin Hawkes-Lewis

From: adam solomon
Date: Sat, Feb 12 2011 1:00PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

I agree that there is no good reason. But reasons are not always good. Your
observation about retrofitting is correct, but it is a reality at this point
in the game that we have to live with, albeit while trying to improve it. In
the case of the datepicker, the control development team had developed a
user control with jquery datepicker embedded. They had already packed it and
shipped to other teams by the time I found out about it. I haven't yet seen
one word on the internet about jquery ui datepicker and its accessibility
(or lack thereof). That's really where the battle should start. Open source
development has the greatest chance of implementing accessibility to the
max.

On Sat, Feb 12, 2011 at 9:36 PM, Benjamin Hawkes-Lewis <
= EMAIL ADDRESS REMOVED = > wrote:

> On Sat, Feb 12, 2011 at 7:14 PM, adam solomon
> < = EMAIL ADDRESS REMOVED = > wrote:
> > With all due respect to the needs of those who require accessible sites,
> one
> > has to be practical. The level of accessibility on the web in general is
> > pretty low. I think the addition of a datepicker is one of the last
> things
> > we should be making a fuss about. Despite the fact that accessible web
> sites
> > shouldn't come at a high expense, the reality is that companies who are
> > implementing accessibility are spending a lot of money on it. Just to
> take
> > an example, our department contracted out a large (not gigantic) web app
> to
> > be developed. After the contract was finished, they thought about
> > accessibility, and the company which received the contract wanted an
> extra
> > $10,000 to make it accessible. That comes out of taxpayer money. I am all
> > for implementing accessibility, but at some point we have to consider the
> > cost, if only to avoid a situation where high costs provide ammunition to
> > those who would torpedo the cause altogether.
>
> Your anecdote is likely an illustration of the expense of retrofitting
> a quality that needs to permeate an entire system as opposed to a mere
> feature, not the intrinsic cost of accessibility. It would also be
> expensive to retrofit security if that had not been considered during
> the design phase.
>
> If the date picker has not been built yet, there's no good reason not
> to pick an accessible implementation.
>
> There's a usability gap if users are presented with controls they
> cannot use in the DOM.
>
> --
> Benjamin Hawkes-Lewis
>

From: Webb, KerryA
Date: Sun, Feb 13 2011 2:57PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of adam solomon
> Sent: Sunday, 13 February 2011 6:14 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] does datepicker have to be accessible
>
> With all due respect to the needs of those who require accessible sites,
> one
> has to be practical. The level of accessibility on the web in general is
> pretty low. I think the addition of a datepicker is one of the last things
> we should be making a fuss about. Despite the fact that accessible web
> sites
> shouldn't come at a high expense, the reality is that companies who are
> implementing accessibility are spending a lot of money on it. Just to take
> an example, our department contracted out a large (not gigantic) web app
> to
> be developed. After the contract was finished, they thought about
> accessibility, and the company which received the contract wanted an extra
> $10,000 to make it accessible. That comes out of taxpayer money. I am all
> for implementing accessibility, but at some point we have to consider the
> cost, if only to avoid a situation where high costs provide ammunition to
> those who would torpedo the cause altogether.
>

There are a number of studies that show that incorporation of accessibility at the design stage is more economical that retrofitting.

Thanks for providing another data point.

Kerry

--
Kerry Webb
Manager
Policy Office | InTACT
Shared Services | ACT Government

-----------------------------------------------------------------------
This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
-----------------------------------------------------------------------

From: Jeevan Reddy
Date: Sun, Feb 13 2011 11:36PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Hi folks,
If you mentioned the Date format, that's enough for Screen Reader users, we
can easily type date According to that format. But what about the
Cognitive, and Motor disabled?
We should think beyond Screen Reader, and let the latest technology
enjoyable to All!
Of course there are certain Challenges involved to make new technology
universal accessible, but if we do it since from the design, it's possible
and Cost effective!
Apologies if any!!!!
Thanks anf regards,
Jeevan Reddy,
Accessibility Engineer,
Onya digital Solutions,
Bangalore, india.

On Sun, Feb 13, 2011 at 12:44 AM, adam solomon < = EMAIL ADDRESS REMOVED =
> wrote:

> With all due respect to the needs of those who require accessible sites,
> one
> has to be practical. The level of accessibility on the web in general is
> pretty low. I think the addition of a datepicker is one of the last things
> we should be making a fuss about. Despite the fact that accessible web
> sites
> shouldn't come at a high expense, the reality is that companies who are
> implementing accessibility are spending a lot of money on it. Just to take
> an example, our department contracted out a large (not gigantic) web app to
> be developed. After the contract was finished, they thought about
> accessibility, and the company which received the contract wanted an extra
> $10,000 to make it accessible. That comes out of taxpayer money. I am all
> for implementing accessibility, but at some point we have to consider the
> cost, if only to avoid a situation where high costs provide ammunition to
> those who would torpedo the cause altogether.
>
> On Sat, Feb 12, 2011 at 8:24 AM, < = EMAIL ADDRESS REMOVED = > wrote:
>
> > there are many sites where it has been made accessible and as a screen
> > reader I prefer using it at times or being able to have the choices. As a
> > screen reader I don't particularly like my choices being made for me
> > because
> > someone has chosen to cut corners. When corners are cut it undermines the
> > whole concept and purpose of accessibility.
> > Chuck
> > ----- Original Message -----
> > From: "Accessibility India" < = EMAIL ADDRESS REMOVED = >
> > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> > Sent: Tuesday, February 08, 2011 5:26 AM
> > Subject: Re: [WebAIM] does datepicker have to be accessible
> >
> >
> > > On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> > >> In many cases accessibility guidelines provide for alternative content
> > >> for
> > >> disabled users. Why would this not classify as one of those instances,
> > as
> > >> the loss here is a small amount of convenience of picking the date,
> and,
> > >> in
> > >> fact, for a screen reader user it is probably easier typing the date
> > >> rather
> > >> than navigating through a datepicker.
> > > Yes Adam, Accessibility guidelines may use alternate methods in some
> > > instances mostly where the content may not be accessible in the
> > > straight way. When we can make any technology accessible there is no
> > > point in denying to make it accessible.
> > > Yes me as a screen reader user I do agree that input the text is
> > > simple but picking date from date picker is not complex if we are able
> > > to make it accessible.
> > >
> > >
> > >> On Tue, Feb 8, 2011 at 3:07 PM, Accessibility India <
> > >> = EMAIL ADDRESS REMOVED = > wrote:
> > >>
> > >>> sorry for the blank message.. my typo..
> > >>> Yes the date picker also should be accessible. We should not provide
> > >>> the users of different abilities in a separate way of interacting
> with
> > >>> the web content. Make the calender icon as a key board focusable
> > >>> event. on clicking the calender icon the user should be focus to the
> > >>> layer where the calender opens.
> > >>> Pic the date and by entering on the date the input field should be
> > >>> updated and the focus should come back to the calender icon by
> closing
> > >>> the calander.
> > >>> Clear instruction should be given to enter the date in correct format
> > >>> in the input field manually.
> > >>> Thankyou
> > >>> Rakesh
> > >>>
> > >>> On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
> > >>> > Scenario: a textbox meant to have a date written in it. A button
> next
> > >>> > to
> > >>> it
> > >>> > (calendar icon) which opens the datepicker to choose a date. One
> can
> > >>> enter a
> > >>> > date manually into the textbox, as well. Does the datepicker need
> to
> > >>> > be
> > >>> > accessible, or is it enough that the user can manually enter a date
> > >>> > into
> > >>> it
> > >>> > without making use of the datepicker? How should the format of the
> > >>> > date
> > >>> to
> > >>> > be entered be communicated to a screen reader user in an
> unobtrusive
> > >>> manner?
> > >>> > Thanks in advance
> > >>> >
> > >>> > --
> > >>> > adam solomon
> > >>> > linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
> > >>> > blogix <http://adam.blogix.co.il/>;
> > >>> >

From: Jeevan Reddy
Date: Mon, Feb 14 2011 2:57AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

On Mon, Feb 14, 2011 at 12:06 PM, Jeevan Reddy
< = EMAIL ADDRESS REMOVED = >wrote:

> Hi folks,
> If you mentioned the Date format, that's enough for Screen Reader users, we
> can easily type date According to that format. But what about the
> Cognitive, and Motor disabled?
> We should think beyond Screen Reader, and let the latest technology
> enjoyable to All!
> Of course there are certain Challenges involved to make new technology
> universal accessible, but if we do it since from the design, it's possible
> and Cost effective!
> Apologies if any!!!!
> Thanks anf regards,
> Jeevan Reddy,
> Accessibility Engineer,
> Onya digital Solutions,
> Bangalore, india.
>
>
> On Sun, Feb 13, 2011 at 12:44 AM, adam solomon <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> With all due respect to the needs of those who require accessible sites,
>> one
>> has to be practical. The level of accessibility on the web in general is
>> pretty low. I think the addition of a datepicker is one of the last things
>> we should be making a fuss about. Despite the fact that accessible web
>> sites
>> shouldn't come at a high expense, the reality is that companies who are
>> implementing accessibility are spending a lot of money on it. Just to take
>> an example, our department contracted out a large (not gigantic) web app
>> to
>> be developed. After the contract was finished, they thought about
>> accessibility, and the company which received the contract wanted an extra
>> $10,000 to make it accessible. That comes out of taxpayer money. I am all
>> for implementing accessibility, but at some point we have to consider the
>> cost, if only to avoid a situation where high costs provide ammunition to
>> those who would torpedo the cause altogether.
>>
>> On Sat, Feb 12, 2011 at 8:24 AM, < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > there are many sites where it has been made accessible and as a screen
>> > reader I prefer using it at times or being able to have the choices. As
>> a
>> > screen reader I don't particularly like my choices being made for me
>> > because
>> > someone has chosen to cut corners. When corners are cut it undermines
>> the
>> > whole concept and purpose of accessibility.
>> > Chuck
>> > ----- Original Message -----
>> > From: "Accessibility India" < = EMAIL ADDRESS REMOVED = >
>> > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>> > Sent: Tuesday, February 08, 2011 5:26 AM
>> > Subject: Re: [WebAIM] does datepicker have to be accessible
>> >
>> >
>> > > On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
>> > >> In many cases accessibility guidelines provide for alternative
>> content
>> > >> for
>> > >> disabled users. Why would this not classify as one of those
>> instances,
>> > as
>> > >> the loss here is a small amount of convenience of picking the date,
>> and,
>> > >> in
>> > >> fact, for a screen reader user it is probably easier typing the date
>> > >> rather
>> > >> than navigating through a datepicker.
>> > > Yes Adam, Accessibility guidelines may use alternate methods in some
>> > > instances mostly where the content may not be accessible in the
>> > > straight way. When we can make any technology accessible there is no
>> > > point in denying to make it accessible.
>> > > Yes me as a screen reader user I do agree that input the text is
>> > > simple but picking date from date picker is not complex if we are able
>> > > to make it accessible.
>> > >
>> > >
>> > >> On Tue, Feb 8, 2011 at 3:07 PM, Accessibility India <
>> > >> = EMAIL ADDRESS REMOVED = > wrote:
>> > >>
>> > >>> sorry for the blank message.. my typo..
>> > >>> Yes the date picker also should be accessible. We should not provide
>> > >>> the users of different abilities in a separate way of interacting
>> with
>> > >>> the web content. Make the calender icon as a key board focusable
>> > >>> event. on clicking the calender icon the user should be focus to the
>> > >>> layer where the calender opens.
>> > >>> Pic the date and by entering on the date the input field should be
>> > >>> updated and the focus should come back to the calender icon by
>> closing
>> > >>> the calander.
>> > >>> Clear instruction should be given to enter the date in correct
>> format
>> > >>> in the input field manually.
>> > >>> Thankyou
>> > >>> Rakesh
>> > >>>
>> > >>> On 2/8/11, adam solomon < = EMAIL ADDRESS REMOVED = > wrote:
>> > >>> > Scenario: a textbox meant to have a date written in it. A button
>> next
>> > >>> > to
>> > >>> it
>> > >>> > (calendar icon) which opens the datepicker to choose a date. One
>> can
>> > >>> enter a
>> > >>> > date manually into the textbox, as well. Does the datepicker need
>> to
>> > >>> > be
>> > >>> > accessible, or is it enough that the user can manually enter a
>> date
>> > >>> > into
>> > >>> it
>> > >>> > without making use of the datepicker? How should the format of the
>> > >>> > date
>> > >>> to
>> > >>> > be entered be communicated to a screen reader user in an
>> unobtrusive
>> > >>> manner?
>> > >>> > Thanks in advance
>> > >>> >
>> > >>> > --
>> > >>> > adam solomon
>> > >>> > linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
>> > >>> > blogix <http://adam.blogix.co.il/>;
>> > >>> >

From: Hoffman, Allen
Date: Mon, Feb 14 2011 6:15AM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

Your example of thinking of accessibility afterwards is just an example
of folks not doing their jobs, not following the law, and in general
spending more money than they should have to meet the needs of the
taxpayers. Don't let the excuse that we did it wrong indicate that we
should accept expensive solutions because they now are accessible.
Smart developers can meet accessibility constraints, especially when
fully customized coding. Some products developed with COTS products
have constraints, but in general customized code should have no excuse.




-----Original Message-----
From: adam solomon [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, February 12, 2011 2:56 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

I agree that there is no good reason. But reasons are not always good.
Your
observation about retrofitting is correct, but it is a reality at this
point
in the game that we have to live with, albeit while trying to improve
it. In
the case of the datepicker, the control development team had developed a
user control with jquery datepicker embedded. They had already packed it
and
shipped to other teams by the time I found out about it. I haven't yet
seen
one word on the internet about jquery ui datepicker and its
accessibility
(or lack thereof). That's really where the battle should start. Open
source
development has the greatest chance of implementing accessibility to the
max.

On Sat, Feb 12, 2011 at 9:36 PM, Benjamin Hawkes-Lewis <
= EMAIL ADDRESS REMOVED = > wrote:

> On Sat, Feb 12, 2011 at 7:14 PM, adam solomon
> < = EMAIL ADDRESS REMOVED = > wrote:
> > With all due respect to the needs of those who require accessible
sites,
> one
> > has to be practical. The level of accessibility on the web in
general is
> > pretty low. I think the addition of a datepicker is one of the last
> things
> > we should be making a fuss about. Despite the fact that accessible
web
> sites
> > shouldn't come at a high expense, the reality is that companies who
are
> > implementing accessibility are spending a lot of money on it. Just
to
> take
> > an example, our department contracted out a large (not gigantic) web
app
> to
> > be developed. After the contract was finished, they thought about
> > accessibility, and the company which received the contract wanted an
> extra
> > $10,000 to make it accessible. That comes out of taxpayer money. I
am all
> > for implementing accessibility, but at some point we have to
consider the
> > cost, if only to avoid a situation where high costs provide
ammunition to
> > those who would torpedo the cause altogether.
>
> Your anecdote is likely an illustration of the expense of retrofitting
> a quality that needs to permeate an entire system as opposed to a mere
> feature, not the intrinsic cost of accessibility. It would also be
> expensive to retrofit security if that had not been considered during
> the design phase.
>
> If the date picker has not been built yet, there's no good reason not
> to pick an accessible implementation.
>
> There's a usability gap if users are presented with controls they
> cannot use in the DOM.
>
> --
> Benjamin Hawkes-Lewis
>

From: Jeevan Reddy
Date: Mon, Feb 14 2011 10:06PM
Subject: Re: does datepicker have to be accessible.
← Previous message | Next message →

Hello,
of course a smart developer can do wonders!, but they are
few.
you are tooooooooo!..... Intelligent, and my example doesn't relate
you.....
A smart Quality Analyst Takes care of inclusive accessibility

On Mon, Feb 14, 2011 at 6:30 PM, Hoffman, Allen < = EMAIL ADDRESS REMOVED = >wrote:

> Your example of thinking of accessibility afterwards is just an example
> of folks not doing their jobs, not following the law, and in general
> spending more money than they should have to meet the needs of the
> taxpayers. Don't let the excuse that we did it wrong indicate that we
> should accept expensive solutions because they now are accessible.
> Smart developers can meet accessibility constraints, especially when
> fully customized coding. Some products developed with COTS products
> have constraints, but in general customized code should have no excuse.
>
>
>
>
> -----Original Message-----
> From: adam solomon [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, February 12, 2011 2:56 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] does datepicker have to be accessible
>
> I agree that there is no good reason. But reasons are not always good.
> Your
> observation about retrofitting is correct, but it is a reality at this
> point
> in the game that we have to live with, albeit while trying to improve
> it. In
> the case of the datepicker, the control development team had developed a
> user control with jquery datepicker embedded. They had already packed it
> and
> shipped to other teams by the time I found out about it. I haven't yet
> seen
> one word on the internet about jquery ui datepicker and its
> accessibility
> (or lack thereof). That's really where the battle should start. Open
> source
> development has the greatest chance of implementing accessibility to the
> max.
>
> On Sat, Feb 12, 2011 at 9:36 PM, Benjamin Hawkes-Lewis <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > On Sat, Feb 12, 2011 at 7:14 PM, adam solomon
> > < = EMAIL ADDRESS REMOVED = > wrote:
> > > With all due respect to the needs of those who require accessible
> sites,
> > one
> > > has to be practical. The level of accessibility on the web in
> general is
> > > pretty low. I think the addition of a datepicker is one of the last
> > things
> > > we should be making a fuss about. Despite the fact that accessible
> web
> > sites
> > > shouldn't come at a high expense, the reality is that companies who
> are
> > > implementing accessibility are spending a lot of money on it. Just
> to
> > take
> > > an example, our department contracted out a large (not gigantic) web
> app
> > to
> > > be developed. After the contract was finished, they thought about
> > > accessibility, and the company which received the contract wanted an
> > extra
> > > $10,000 to make it accessible. That comes out of taxpayer money. I
> am all
> > > for implementing accessibility, but at some point we have to
> consider the
> > > cost, if only to avoid a situation where high costs provide
> ammunition to
> > > those who would torpedo the cause altogether.
> >
> > Your anecdote is likely an illustration of the expense of retrofitting
> > a quality that needs to permeate an entire system as opposed to a mere
> > feature, not the intrinsic cost of accessibility. It would also be
> > expensive to retrofit security if that had not been considered during
> > the design phase.
> >
> > If the date picker has not been built yet, there's no good reason not
> > to pick an accessible implementation.
> >
> > There's a usability gap if users are presented with controls they
> > cannot use in the DOM.
> >
> > --
> > Benjamin Hawkes-Lewis
> >

From: Paul.Adam@dars.state.tx.us
Date: Tue, Feb 15 2011 12:51PM
Subject: Re: does datepicker have to be accessible
← Previous message | Next message →

From working in state government for over a year I just wanted to chime in and say you are exactly right! Excellent assessment of typical situations I've seen! I think it all comes down to the contract procurements and not implementing accessibility requirements from the beginning.

Hopefully things will change soon and we don't lose momentum with all the state and federal budget cuts.

Paul Adam
Accessibility Specialist
Center for Policy and Innovation
= EMAIL ADDRESS REMOVED =


-----Original Message-----
From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, February 14, 2011 7:01 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

Your example of thinking of accessibility afterwards is just an example
of folks not doing their jobs, not following the law, and in general
spending more money than they should have to meet the needs of the
taxpayers. Don't let the excuse that we did it wrong indicate that we
should accept expensive solutions because they now are accessible.
Smart developers can meet accessibility constraints, especially when
fully customized coding. Some products developed with COTS products
have constraints, but in general customized code should have no excuse.

From: Robinson, Grant (CSS)
Date: Wed, Feb 16 2011 2:21PM
Subject: Re: does datepicker have to be accessible
← Previous message | No next message

If accessibility is only considered when the developer
gets their hands on the functional specs, or the RFP
has been written, then you are already 3/4 on the way to
failure.

Really, accessibility in an organization should be treated
Just like security or privacy. Maybe you have checklists,
Maybe you incorporate accessibility cues and examples in
Your project gating process, or maybe evan, during your
Next business architecture review.

While we often talk about code level accessibility, more
Thought and effort needs to be brought out long before
The first line of code is written or the COTS application is selected,

Cheers!
Grant

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: February 14, 2011 8:01 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

Your example of thinking of accessibility afterwards is just an example
of folks not doing their jobs, not following the law, and in general
spending more money than they should have to meet the needs of the
taxpayers. Don't let the excuse that we did it wrong indicate that we
should accept expensive solutions because they now are accessible.
Smart developers can meet accessibility constraints, especially when
fully customized coding. Some products developed with COTS products
have constraints, but in general customized code should have no excuse.




-----Original Message-----
From: adam solomon [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, February 12, 2011 2:56 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] does datepicker have to be accessible

I agree that there is no good reason. But reasons are not always good.
Your
observation about retrofitting is correct, but it is a reality at this
point
in the game that we have to live with, albeit while trying to improve
it. In
the case of the datepicker, the control development team had developed a
user control with jquery datepicker embedded. They had already packed it
and
shipped to other teams by the time I found out about it. I haven't yet
seen
one word on the internet about jquery ui datepicker and its
accessibility
(or lack thereof). That's really where the battle should start. Open
source
development has the greatest chance of implementing accessibility to the
max.

On Sat, Feb 12, 2011 at 9:36 PM, Benjamin Hawkes-Lewis <
= EMAIL ADDRESS REMOVED = > wrote:

> On Sat, Feb 12, 2011 at 7:14 PM, adam solomon
> < = EMAIL ADDRESS REMOVED = > wrote:
> > With all due respect to the needs of those who require accessible
sites,
> one
> > has to be practical. The level of accessibility on the web in
general is
> > pretty low. I think the addition of a datepicker is one of the last
> things
> > we should be making a fuss about. Despite the fact that accessible
web
> sites
> > shouldn't come at a high expense, the reality is that companies who
are
> > implementing accessibility are spending a lot of money on it. Just
to
> take
> > an example, our department contracted out a large (not gigantic) web
app
> to
> > be developed. After the contract was finished, they thought about
> > accessibility, and the company which received the contract wanted an
> extra
> > $10,000 to make it accessible. That comes out of taxpayer money. I
am all
> > for implementing accessibility, but at some point we have to
consider the
> > cost, if only to avoid a situation where high costs provide
ammunition to
> > those who would torpedo the cause altogether.
>
> Your anecdote is likely an illustration of the expense of retrofitting
> a quality that needs to permeate an entire system as opposed to a mere
> feature, not the intrinsic cost of accessibility. It would also be
> expensive to retrofit security if that had not been considered during
> the design phase.
>
> If the date picker has not been built yet, there's no good reason not
> to pick an accessible implementation.
>
> There's a usability gap if users are presented with controls they
> cannot use in the DOM.
>
> --
> Benjamin Hawkes-Lewis
>