Geoff Deering wrote:
How do you know what device configuration is receiving your design? Because if you do not, and cannot be absolutely sure your design is not clashing with this principle, you cannot *ensure* you have succeeded.
But that is true of pretty much any element and situation where you're applying style. And that's why we have separation of content and presentation: if the presentation does present a problem to the user, the user agent should provide the user with a simple way of overriding, or completely ignoring, the styles suggested by the designer.
Unless you know for sure how users have configured their interface you are swimming in the sea of uncertainty. [...] If accuracy of communicating [...] is a primary principle to your design philosophy,
> you cannot be
sure you have not interfered with this process
With my intentional omissions (not trying to misquote you, just making it generic), I'd say this applies to any styling, not just the specific case of form elements.
just as long as designers are aware that there is an issue here, and if they choose to do so, then there is no guarantee that their design may not clash against this functional convention. Just as long as they are implementing their design without ignorance, then I feel I've contributed all I want too. That's my issue. Once this is raised, and they realised that such recommendations, no matter how well intentioned (as the above), will not save them from the possibility that their design may clash somewhere, then they can make their own decisions empowered by knowledge, not hedged in ignorance.
That's cool by me. Sorry, I was under the impression you were advocating an almost draconian "don't use styling on form elements, ever" *rule*.
And if we are trying to future proof, who knows what wonders of usability research will lead to designing the next generation interfaces for operating systems. Then you have to go back and correct your styles to address this.
In future, I'd hope user agents were more helpful in offering specific settings (which are easily available, not hidden under 3 hierarchies of menus and options dialogs etc) to override and/or set styling. Like user styles, but without the need to be a propellerhead CSS wrangler to create/implement one.
It's just raising the issue. If designers what to go ahead and do that in full knowledge, that is their decision. I just feel it is important to discuss the issues, and not misled them into feeling there is any way around this. Nothing I have seen so far offers a solution to style input controls in this manner and be free of concerns of clashing with conveying interface state.
I'm almost tempted to drop in a "don't use colour alone to convey information" here...careful styling plus some additional indication that a control is read-only (an addition to the control's label, or a graphical element like a closed padlock or big X in front of it, whatever) may be an possible additional piece of visual information. Again, considerations that any designer worth her salt would at least take into consideration (not saying that's the solution, mind...just throwing another idea into the mix here).
I know many people feel that about the WAI GL, but I have never felt that. People complain about the WAI police and the lengthy drawn out debate that goes on there, but I mostly see a lot of people concerned *not* to write recommendations that restrict design.
Fair enough...I'm probably thinking of some of the more radical (and possibly most vocal and entrenched) elements here.
... geez... that's my rant for the day... please forgive:-)
It's good stuff, as always :) P -- Patrick H. Lauke __________________________________________________________ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __________________________________________________________ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __________________________________________________________ ****************************************************** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ******************************************************
