WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: does datepicker have to be accessible

for

From: adam solomon
Date: Feb 12, 2011 1:00PM

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

> On Sat, Feb 12, 2011 at 7:14 PM, adam solomon
> < <EMAIL 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
>