Thank you Sandra for the tute. Good stuff.
I would also like thank everyone for their assistance. I have a good handle
on things. I was a bit confused by the JS aspect. The language in the actual
specs is a bit hazy.
Again, thanx!
G!
On Fri, Feb 20, 2009 at 7:43 PM, Sandra Clark wrote:
>
>
y does not support ARIA at this time, although I understand that there
> are plans to do so in a future release.
>
> -Original Message-
> From: Judah McAuley [mailto:ju...@wiredotter.com]
> Sent: Friday, February 20, 2009 11:31 PM
> To: cf-talk
> Subject: Re: (sot) C
Auley [mailto:ju...@wiredotter.com]
Sent: Friday, February 20, 2009 11:31 PM
To: cf-talk
Subject: Re: (sot) CF and Section 508 compliance & a 508 compliant date/time
picker
I'd also recommend looking at the ARIA (accessible rich internet
applications) initiative through the W3C:
http://www.w3.o
I'd also recommend looking at the ARIA (accessible rich internet
applications) initiative through the W3C:
http://www.w3.org/WAI/PF/aria-practices/
You should also check out actual screen readers as modern screen
readers do interact with javascript to some extent and that should be
taken into acc
A good tutorial to start with would be
http://jimthatcher.com/webcourse1.htm
Basically, your site has to work with Javascript turned off. Check things
by using just the keyboard, I've audited sites with date widgets where yes,
the text could be entered manually, but the keyboard hit the date p
> If we have time we will roll our own, prolly using spry as long as it
> doesn't conflict with the Dynarch widget like said it could/would.
You can work around that by disabling Spry's date hints for
date-validated text fields.
--
s. isaac dealey ^ new epoch
isn't it time for a change?
>> I'm curious, what are the current torch and pitchfork arguments against
using CFFORM?
No reason for me to bring it up other than to avoid having the post
derailed. I have seen it brought up a few times tends though not as bad as
evaluate(). I have been using CF form for years with out a proble
> >>Any date-picker should be fine, provided that the widget is used to
> populate a text field that can also be manually entered.
>
> Thanx Ike,
> So if I understand correctly, if I have a date/time widgets that can can be
> used as (or considered to be) a convenience or an adjunct, but not the
>>Any date-picker should be fine, provided that the widget is used to
populate a text field that can also be manually entered.
Thanx Ike,
So if I understand correctly, if I have a date/time widgets that can can be
used as (or considered to be) a convenience or an adjunct, but not the
primary and/
Gerald,
There are web developers and programmers who make it part of their life work
to make sure everything that is created by them is Section 508 compatible.
Frankly, it is the right thing to do.
Being under 'crunch', I feel for you. Unless you are editing a site that
was already compliant,
> Also.. Does anyone know of any 508 compliant date/time pickers? Those
> are going to be the only JS widgets that may be an issue.
Any date-picker should be fine, provided that the widget is used to
populate a text field that can also be manually entered. I integrated
the Dynarch widget into the
Gerald Guido wrote:
> using CFForm will be an issue. Yes I know... we shouldn't use CFForm etc..
> but it is uber-crunch time and that is what our code generator spits out.
I'm curious, what are the current torch and pitchfork arguments against
using CFFORM? In the past it was terrible and I st
12 matches
Mail list logo
