Comments inline:
On 27/01/2009, at 7:33 AM, Jessica Enders wrote:
Hi Pascal
In the JavaScript/Accessibility/form validation discussion you
mention "the growing number of users who purposefully disable
JavaScript". I'm always curious just how many people this is.
Do you, or does anyone else, have any statistics on this? Is there a
reason you describe it as a "growing number"?
Any information greatly appreciated.
No, I don’t have access to any statistics on the matter. I want to
clarify that my comment does not address the growing number of new
Internet users who most likely will have JavaScript turned on or the
majority of users in a holistic sense. I don’t think the users that
disable JS are a majority but I definitely think they are on the rise
as many security experts are recommending JS to be disabled by default.
Whether or not JS-disabled users are a statistic worth noting should
not be in question here. I think Anthony Ziebell puts it best:
“JavaScript should be implemented only to supplement / layer existing
functionality. Your site should operate just fine without it… There
are always exceptions to this rule however you shouldn’t let
JavaScript dictate how you code.”
Kind regards.
—Pascal
Cheers
Jessica Enders
Principal
Formulate Information Design
----------------------------------------
http://formulate.com.au
----------------------------------------
Phone: (02) 6116 8765
Fax: (02) 8456 5916
PO Box 5108
Braddon ACT 2612
----------------------------------------
On 19/01/2009, at 11:14 PM, Simon Pascal Klein wrote:
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
*******************************************************************
---
Simon Pascal Klein
Graphic & Web Designer
Web: http://klepas.org
E-mai: kle...@klepas.org
Twitter: @klepas; http://twitter.com/klepas
Kaffee und Kuchen.
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*******************************************************************
