Henny note: Overall the proposal to allow unscripted client-server
interaction thereby taking the onerous off the page author and into
the browser is a huge benefit to accessibility. This means that
validating forms, checking input and so on will be customized across
sites with no reliance on JavaScript. Designers will not have to build
form validation from the ground up each time and users can enjoy some
consistency, less breakage and so on.
HTML section: 4.10 Forms
url: http://dev.w3.org/html5/spec/forms.html#forms
issues:
1. Form validation
Under form validation there is no stipulation that validation errors
should be stylable by the page author using CSS and are currently only
available as per how the UA styles them unless the page author knows
JavaScript. This I see as an issue if browsers simply implement an
arbitrary styling that some users find hard to read. As such there
needs to be scope for validation errors to be stylable (without
relying on JavaScript) or browser implementations to be as readable /
accessible as possible (the latter being pretty subjective).
My other fear is that if forms validation can not be styled without
JavaScript page authors may skip using HTML5 webform validation as it
messes up their design. We then get to a situation where we have
developers refusing to adopt webforms in HTML5 in favour of their own
styled forms which potentially could be inaccessble. Users in turn
miss out.
Anecdotally I know of a web designer who works predominantly with
users with cognitive problems and wont use webforms if they can't
easily be styled without JavaScript.
Proposal for change: require that all error validation be stylable by
the page author without relying on JavaScript. Not sure if this is in
scope of HTML5 or is under UAAG. I'm told this is not so easy for a UA
to do and that if we want to make the default error messages
styleable, we would need to approach the CSSWG with the problem and
have them find a solution to make them styleable. Apparently it could
possibly work if they provided some sort of pseudo-element.
UAWG related issue/concern: Do we have a UAAG guideline to enforce
this / should it be covered in HTML5? Is it the case that UAAG can
only say that the messages themselves need to be accessible, but can't
say anything about making them author-styleable?
2. Date pickers
Date pickers should be both keyboard accessible and able to be
magnified in the browser. I think this is beyond the scope of HTML5
itself and covered in UAAG but mention it just to clarify.
Proposal for change:
UAWG related issue/concern: This should be covered in UAAG for
keyboard accessibility I'm guessing.
Cheers, Henny
--
Henny Swan
Web Evangelist
Member of W3C Web Accessibility Initiative Education and Outreach Group
www.opera.com/developer
Personal blog: www.iheni.com
Stay up to date with the Web Standards Curriculum www.opera.com/wsc