I found that some of these elements take quite some time to
integrate. Creating high-contrast CSS can take up to a day (or more
if you're new to it), non-Javascript states usually more than an
hour because you also have to edit the script.
By non-Javascript states do you mean that the
I thought a bit more about this and I realised perhaps a better option
would be to display the JS-injected messages and errors that a screen
reader could not read but upon submission of the form, reload the page
and provide all the messages and errors again (the form could not be
completed
From: Chris Knowles
I wouldn't be waiting for ARIA to get out of draft before using it :) It
has pretty good support in browsers already so get stuck in. And because
essentially all you are doing with ARIA is adding attributes to tags,
the worst that can happen is your pages no longer
From: Chris Knowles
yes, so you still run your code through the validator and make sure it
only fails on the ARIA attributes - that way you save yourself a whole
lot of trouble. I don't really understand inserting attributes with
javascript just so you get a tick from the validator? Maybe
Chris Taylor wrote:
From: Chris Knowles
I wouldn't be waiting for ARIA to get out of draft before using it :) It
has pretty good support in browsers already so get stuck in. And because
essentially all you are doing with ARIA is adding attributes to tags,
the worst that can happen is your
Chris Taylor wrote:
Adding ARIA attributes using JavaScript is therefore part of progressive
enhancement
does that actually work? My understanding is that one problem ARIA
addresses is that when javascript alters the DOM, assistive technologies
don't necessarily get notified of the changes.
-Original Message-
From: Chris Knowles
does that actually work? My understanding is that one problem ARIA
addresses is that when javascript alters the DOM, assistive technologies
don't necessarily get notified of the changes. So do they get notified
that you've injected ARIA
If there were further communication between the user and server
between submission of the form that would entail a page reload then a
screen user shouldn’t have an issue, whereas if JavaScript would run
in the background and inject errors or suggestions as it thinks the
user makes them
There were a couple of articles on SitePoint (if I recall correctly) six
months ago or so, that covered this, in a fairly positive light.
I'm afraid I'm not in a position to chase after them right now; perhaps
someone else does have the time?
Mike
after all it's impossible to tell those users using an accessibility aid like
a screen reader
from those who do not, and hey, the growing number of users who purposefully
disable
JavaScript won't see the glitzy JavaScript injected errors anyway.
Agreed, and any decent validation is going
Hmm, I made a typo. Coffee time.
On 1/20/09, james.duc...@gmail.com james.duc...@gmail.com wrote:
after all it's impossible to tell those users using an accessibility aid
like a screen reader
from those who do not, and hey, the growing number of users who
purposefully disable
JavaScript
Server side validation is of course a must...
however, if the visually impaired visitor has _javascript_ turned on and
these error elements are created, they won't exactly get to the server
side validation now, will they? ARIA looks good, looking forward to it
getting out of draft status.
Sorry, I was a bit vague. I'm saying do all validation server-side. If
you're looking for a quick and dirty solution to the element injection
issues when screen readers are being used, you can try setting focus
back to the new element's parent, though shifting focus is a practice
often frowned
Anthony Ziebell wrote:
ARIA looks good, looking forward to it getting out of draft status.
I wouldn't be waiting for ARIA to get out of draft before using it :) It
has pretty good support in browsers already so get stuck in. And because
essentially all you are doing with ARIA is adding
My only concern with a draft is that things change...
Chris Knowles wrote:
Anthony Ziebell wrote:
ARIA looks good, looking forward to it getting out of draft status.
I wouldn't be waiting for ARIA to get out of draft before using it :) It
has pretty good support in
Hey group,
Does anyone have any ideas on standards based form validation, which is
non-obtrusive, however remains accessible?
Reason I ask, is that some form validations inject an element say under
a form input, explaining the error. Now, without any alerts, how would
a blind person / screen
I'll confess my ignorance on this issue, but how do screen readers
handle DHTML type injection of content into the DOM?
Without using alerts, you could add the warning into the actual
document. But how does a screen reader know the document has changed?
L.
On Mon, Jan 19, 2009 at 4:30 PM,
Without using alerts, you could add the warning into the actual
document. But how does a screen reader know the document has changed?
For starters: http://dev.opera.com/articles/view/introduction-to-wai-aria/
Regards,
Rimantas
--
http://rimantas.com/
Isn't 'aria-required' a non-standard attribute?
Rimantas Liubertas wrote:
Without using alerts, you could add the warning into the actual
document. But how does a screen reader know the document has changed?
For starters:
19 matches
Mail list logo
