Re: [WSG] JavaScript and Accessibility
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 anyway due to the errors; where else would to send the user to?). This way users browsing with an accessibility aid like a screen reader would not see the injected errors which are a nifty feature but still be presented with them upon submission of the form and the page reload. Why I didn’t think of this earlier is beyond me. D’oh. —Pascal On 20/01/2009, at 12:57 PM, 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 won't see the glitzy JavaScript injected errors anyway. Agreed, and any decent validation is going to be done server-side validation anyway, so you're going to have to (or at least you should) implement the server-side responses in any case. - James -- James Ducker Web Developer http://www.studioj.net.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** --- Simon Pascal Klein Concept designer (w) http://klepas.org (e) kle...@klepas.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] JavaScript and Accessibility
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 validate - but who
cares if you are making them more accessible?
I think validation is still important to ensure a consistent and future-proof
experience across browsers, but ARIA is definitely needed. So seeing as ARIA
attributes are there to offer a solution to problems introduced by JavaScript,
why don't we use JavaScript to add the ARIA attributes. Using a similar idea to
my Performer script [1] we could add these using CSS:
p id=updates class=aria-live-politeThis content will be updated by an
AJAX-type script/p
A simple script could parse all elements in the DOM tree, and anything with the
class aria-live-polite add the attribute aria-live with a value of
polite. If this was done before any other JavaScript was run it would prepare
the page with ARIA attributes before it is needed, whilst keeping the code
validating. The resulting code in this example would be:
p id=updates class=aria-live-polite aria-live=politeThis content will
be updated by an AJAX-type script/p
Of course, elements with ARIA classes could be styled differently if required:
.aria-live-polite { border: 1px dotted #CCC; }
If JavaScript is not present or disabled, the ARIA attributes will not get
applied. But that won't be a problem, as no other JavaScript will be run anyway.
There are actually a lot of ARIA attribute variations so this idea may not
scale very well, but for simple use it may be a suitable answer to the ARIA /
validation problem.
Chris
[1] http://performerjs.org - add JavaScript features using just CSS classes and
standard attributes. New website and lots more features coming very soon. Get
in touch if you'd be interested in helping / testing.
This message has been scanned for malware by SurfControl plc.
www.surfcontrol.com
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
RE: [WSG] JavaScript and Accessibility
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 I'm missing something but what benefit does that bring? And validators will catch up at some point anyway. Quite apart from the satisfaction I get from those green ticks (I loves me them green ticks), I think providing a validating page to the browser is an important part of creating a web that is accessible to all. We all know the problems that certain (ahem) browser manufacturers have with a properly-validating document, but if we have these document definitions in place we should use them. Adding ARIA attributes using JavaScript is therefore part of progressive enhancement, much like using any AJAX-type features is - or at least should be. It's not ideal, I'm not pretending for one minute it is, but that's the web world we live in. Hopefully, in the fullness of time, all these measures will become unnecessary and we'll all bask in the warm glow of browsers that natively handle all the goodies which are being waved in front of our noses (not just ARIA, CSS3, HTML5 etc). But I'm not holding my breath for that day. Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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 pages no longer validate - but who cares if you are making them more accessible? I think validation is still important to ensure a consistent and future-proof experience across browsers 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 I'm missing something but what benefit does that bring? And validators will catch up at some point anyway. -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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. So do they get notified that you've injected ARIA attributes? -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] JavaScript and Accessibility
-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 attributes? The thought had crossed my mind, but unfortunately I have no reliable way to test it. If anyone wants to let us know whether this idea is a goer, I'd be very grateful. Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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 (e.g. password complexity recommendations, username not available messages) numerous accessibility issues arise. The only solution that came to mind was having a generic message (such as ‘please fill out all marked (*) fields’ or the like) that could be hidden using CSS and through JavaScript ‘unhidden’ when an error appears (though it could only be a generic error). As dandy as these automatic feedback and error messages are through JavaScript maybe a full submission and subsequent page reload is best—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. Just my 0.2¢. On 19/01/2009, at 5:52 PM, Rimantas Liubertas wrote: Isn't 'aria-required' a non-standard attribute? Sadly, yes. But there is some hope: it is possible that ARIA will be accepted in HTML5 and there is an initiative to provide validation for (X)HTML+ARIA: http://lists.w3.org/Archives/Public/wai-xtech/2008Sep/0381.html Validator.nu already has experimental support for HTML5+ARIA, and I believe (did not check) http://qa-dev.w3.org/wmvs/HEAD/ provides the same for document type HTML5. There is also a possibility to add ARIA attributes with Javascript. All the options are controversial, but that's how it is for now :( Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** --- Simon Pascal Klein Concept designer (w) http://klepas.org (e) kle...@klepas.org *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] JavaScript and Accessibility
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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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 to be done server-side validation anyway, so you're going to have to (or at least you should) implement the server-side responses in any case. - James -- James Ducker Web Developer http://www.studioj.net.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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 won't see the glitzy JavaScript injected errors anyway. Agreed, and any decent validation is going to be done server-side validation anyway, so you're going to have to (or at least you should) implement the server-side responses in any case. - James -- James Ducker Web Developer http://www.studioj.net.au -- James Ducker Web Developer http://www.studioj.net.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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. Thanks, Anthony. james.duc...@gmail.com wrote: 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_ won't see the glitzy _javascript_ injected errors anyway. Agreed, and any decent validation is going to be done server-side validation anyway, so you're going to have to (or at least you should) implement the server-side responses in any case. - James -- James Ducker Web Developer http://www.studioj.net.au ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] JavaScript and Accessibility
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 upon. On 1/20/09, Anthony Ziebell anth...@fatpublisher.com.au wrote: 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. Thanks, Anthony. james.duc...@gmail.com wrote: 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 won't see the glitzy JavaScript injected errors anyway. Agreed, and any decent validation is going to be done server-side validation anyway, so you're going to have to (or at least you should) implement the server-side responses in any case. - James -- James Ducker Web Developer http://www.studioj.net.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- James Ducker Web Developer http://www.studioj.net.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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 attributes to tags, the worst that can happen is your pages no longer validate - but who cares if you are making them more accessible? -- Chris Knowles *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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 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 validate - but who cares if you are making them more accessible? ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
Re: [WSG] JavaScript and Accessibility
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, Anthony Ziebell anth...@fatpublisher.com.au wrote: 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 reader pick up the fact that the element is now there and read out this error? Has anyone been able to cater for this requirement? Thanks, Anthony. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] JavaScript and Accessibility
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: http://dev.opera.com/articles/view/introduction-to-wai-aria/ Regards, Rimantas -- http://rimantas.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** ***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: memberh...@webstandardsgroup.org***
