WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: does datepicker have to be accessible.

for

From: Jeevan Reddy
Date: Feb 14, 2011 10:06PM

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