WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: does datepicker have to be accessible

for

From: Robinson, Grant (CSS)
Date: Feb 16, 2011 2:21PM

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 REMOVED>
[mailto: <EMAIL 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 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
>