On 11/17/05, Patrick H. Lauke [EMAIL PROTECTED] wrote:
Linking back to my philosophical question at the beginning: is web
development a subset of software development, or is it - for lack of a
better term - the development of an experience. A related point from
that: should web applications
On 11/18/05 2:16 AM James Bennett [EMAIL PROTECTED] sent this out:
I think part of the problem here is that
Great read. Thanks.
You have many valid thoughts, and you express them well. :-)
Rick Faaberg
**
The discussion list for
Rick Faaberg
On 11/18/05 2:16 AM James Bennett [EMAIL PROTECTED]
sent this out:
I think part of the problem here is that
You have many valid thoughts, and you express them well. :-)
So what, most of the ramblings of Geoff and I posted were invalid
and badly expressed? ;)
Nah, just
On 11/18/05, Patrick Lauke [EMAIL PROTECTED] wrote:
Rick Faaberg You have many valid thoughts, and you express them well. :-)So what, most of the ramblings of Geoff and I posted were invalidand badly expressed? ;)
Yes, please validate your next ramble with one of the W3C's online tools please :pI
Herrod, Lisa wrote:
for the record, I'm still following the thread.
this isn't even close to finished.
I think it's best if I take a time out and write a thorough article. If
it is a topic worthy of more discussion, I think that is the best way to
serve that purpose.
James Bennett wrote:
On 11/17/05, Patrick H. Lauke [EMAIL PROTECTED] wrote:
Linking back to my philosophical question at the beginning: is web
development a subset of software development, or is it - for lack of a
better term - the development of an experience. A related point from
that:
Geoff Deering
Okay, so if this was implemented in user agents, what would be your
educated estimate of percentage of users who would configure this and
therefore avoid this problem of interpreting the incorrect
state of form
controls?
I'd estimate it to be roughly the same as the
Patrick Lauke wrote:
Geoff Deering
Okay, so if this was implemented in user agents, what would be your
educated estimate of percentage of users who would configure this and
therefore avoid this problem of interpreting the incorrect
state of form
controls?
I'd estimate it to
Geoff Deering
I'd estimate it to be roughly the same as the percentage of
users that have reconfigured their OS to use different
default colours which would make them get confused by
*judiciously* styled form controls.
And what percentage of users that access those web pages would you
Patrick Lauke wrote:
Geoff Deering
I'd estimate it to be roughly the same as the percentage of
users that have reconfigured their OS to use different
default colours which would make them get confused by
*judiciously* styled form controls.
And what percentage of
Geoff Deering wrote:
It's not a philosophical difference here, it amazes me that this is the
perspective you draw, because it's clearly a difference of understanding
and interpreting the impact of standard interface design elements when
they clash with interface design conventions for
for the record, I'm still following the thread.
this isn't even close to finished.
-Original Message-
From: Geoff Deering
To: wsg@webstandardsgroup.org
Sent: 11/18/05 12:54 PM
Subject: Re: [WSG] Accessibility: Default placeholders
Patrick Lauke wrote:
Geoff Deering
Geoff Deering
Secondly, by this recommendation you are actually addressing the flip
side of the problem I am trying to address.
The case you are addressing here is
1) A recommendation of how to deal with styles that may
conflict with a
form element that is in an activated state.
2)
Patrick Lauke wrote:
Geoff Deering
Secondly, by this recommendation you are actually addressing the flip
side of the problem I am trying to address.
The case you are addressing here is
1) A recommendation of how to deal with styles that may
conflict with a
form element that is in
Geoff Deering wrote:
No, I don't feel we are. This recommendation does not address the
problems raised by this specific issue, according to my understanding.
So I would very much appreciate if you could explain in thorough
technical detail and functionality how this works and how it
Patrick H. Lauke wrote:
Geoff Deering wrote:
No, I don't feel we are. This recommendation does not address the
problems raised by this specific issue, according to my understanding.
So I would very much appreciate if you could explain in thorough
technical detail and functionality how
Andy Kirkwood, Motive wrote:
Hi Kevin,
Nice example, top marks ;).
Sometimes these discussions can get a little abstract and one (real world)
example can help make the discussion less murky.
Geoff, I understand your pain with regard to traditional (print) designers and
the often rocky
Geoff Deering
The problem is that web designers are now implementing designs that
convey meaning to form controls, that they are not intending
to imply in their design,
Which, again, is a sign of a bad designer, and a problem that should be solved
by educating the designer, not simply
Patrick Lauke wrote:
Geoff Deering
The problem is that web designers are now implementing designs that
convey meaning to form controls, that they are not intending
to imply in their design,
Which, again, is a sign of a bad designer, and a problem that should be solved by
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
Patrick H. Lauke wrote:
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
Geoff Deering wrote:
This also leads to another problem, in that if users configure their
operating system to a custom scheme, unwittingly the web designer may be
indicating to the user that a field may be read only even if it is not
grey. How does the designer know whether to use grey or
Patrick Lauke wrote:
Geoff Deering wrote:
With all due respects this is the way default graphical user interface
on operating systems are designed to function.
From page 158 of The Windows Interface Guidelines for Software Design;
But we're talking about the
Hassan Schroeder wrote:
Geoff Deering wrote:
This also leads to another problem, in that if users configure their
operating system to a custom scheme, unwittingly the web designer may be
indicating to the user that a field may be read only even if it is not
grey. How does the designer
Geoff Deering wrote:
So I cannot see how your argument applies, to me, it doesn't stand up.
A designer should not implement a design element where their design
falsely indicates to the user that the form control is in another state
than it is actually in. This is misrepresentation of state.
Patrick H. Lauke wrote:
Geoff Deering wrote:
So I cannot see how your argument applies, to me, it doesn't stand
up. A designer should not implement a design element where their
design falsely indicates to the user that the form control is in
another state than it is actually in. This is
Geoff Deering wrote:
You find these types of web environments mostly on intranets. For a lot
of people in large organisations, these are primary interfaces they have
to work with. To neglect to address this issue correctly could easily
impact the integrity of data because the interface is
Patrick H. Lauke said:
But is the solution to make a sweeping don't style inputs
recommendation, or to actually educate the designers not to just make
arbitrary decision, but decisions firmly based on usability (including
expected behaviour/presentation of state)?
Yes, this is indeed the
Hi Geoff,
(To pick up on Patrick's point.) Have you come across a scenario on a
website where it seems appropriate to use an input element to
indicate that an option exists but cannot be edited by the user?
Perhaps it's preferable to show such content as text rather than as
an input?
could
be useful to someone.
Cheers,
Rebecca
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Kirkwood,
Motive
Sent: Tuesday, 15 November 2005 5:20 p.m.
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Accessibility: Default placeholders
Hi Geoff
On 15/11/05 3:20 PM, Andy Kirkwood, Motive [EMAIL PROTECTED] wrote:
Hi Geoff,
(To pick up on Patrick's point.) Have you come across a scenario on a
website where it seems appropriate to use an input element to
indicate that an option exists but cannot be edited by the user?
Perhaps it's
Patrick H. Lauke wrote:
Geoff Deering wrote:
You find these types of web environments mostly on intranets. For a
lot of people in large organisations, these are primary interfaces
they have to work with. To neglect to address this issue correctly
could easily impact the integrity of data
Hi Rebecca,
For example, if you wanted to show that a field was editable content (within
the whole application), but not on the particular screen you are on right now
(especially if the user knew that by clicking on edit or some other option
they would be able to edit those particular fields.)
Terrence Wood wrote:
Patrick H. Lauke said:
But is the solution to make a sweeping don't style inputs
recommendation, or to actually educate the designers not to just make
arbitrary decision, but decisions firmly based on usability (including
expected behaviour/presentation of state)?
Andy Kirkwood, Motive wrote:
Hi Geoff,
(To pick up on Patrick's point.) Have you come across a scenario on a
website where it seems appropriate to use an input element to
indicate that an option exists but cannot be edited by the user?
Yes I can (domain registrars). In various states
Rebecca Cox wrote:
Could be useful depending on the context.
For example, if you wanted to show that a field was editable content (within the whole application), but not on the particular screen you are on right now (especially if the user knew that by clicking on edit or some other option
Kevin Futter wrote:
On 15/11/05 3:20 PM, Andy Kirkwood, Motive [EMAIL PROTECTED] wrote:
Hi Geoff,
(To pick up on Patrick's point.) Have you come across a scenario on a
website where it seems appropriate to use an input element to
indicate that an option exists but cannot be edited by the
Hi Kevin,
Nice example, top marks ;).
Sometimes these discussions can get a little abstract and one (real world)
example can help make the discussion less murky.
Geoff, I understand your pain with regard to traditional (print) designers and
the often rocky transition to screen-based design.
On Mon, 14 Nov 2005 08:31:21 +0800, Bert Doorn wrote:
Have we reached (or largely reached) the until user agents stage
yet? What implications is ignoring this guideline likely to have
(other than not getting tick marks from various automated tools),
given I use properly coded labels and
Bert Doorn wrote:
Is it really necessary for accessibility to include default
place-holding characters in edit boxes and text areas per WCAG 1.0
Checkpoint 10.4? Is that an obsolete guideline?
Personally, I'd say it is an obsolete guideline indeed. However, I
recently heard on the WAI IG
On 14/11/2005, at 11:31 AM, Bert Doorn wrote:
Is it really necessary for accessibility to include default
place-holding characters in edit boxes and text areas per WCAG 1.0
Checkpoint 10.4? Is that an obsolete guideline?
...
Have we reached (or largely reached) the until user agents stage
@webstandardsgroup.org
Subject: Re: [WSG] Accessibility: Default placeholders
Leaving it there can be a problem. I have seen a demonstration (at a
Melbourne WSG meeting, no less) where the agent placed the cursor at
the end of the place-holding text without reading it. There is a real
danger that the user
Lea de Groot wrote:
I am reliably informed we have reached that point and that including
default text now causes more problems than it solves.
However I do not have many references to back this up -
Possibly worth adding to this empirical evidence: I spoke to Shawn
Lawton Henry of the
Patrick H. Lauke wrote:
Bert Doorn wrote:
Is it really necessary for accessibility to include default
place-holding characters in edit boxes and text areas per WCAG 1.0
Checkpoint 10.4? Is that an obsolete guideline?
Personally, I'd say it is an obsolete guideline indeed. However, I
Jonathan O'Donnell wrote:
Leaving it there can be a problem. I have seen a demonstration (at a
Melbourne WSG meeting, no less) where the agent placed the cursor at
the end of the place-holding text without reading it. There is a real
danger that the user will enter text without knowing
Herrod, Lisa wrote:
I ran a usability evaluation last week where some (few) of the form elements
had place-holding text and others didn't.
This caused problems as you might expect as users scanned over those fields
thinking that as they were already populated, they were therefore optional.
Of
Yes this is an interesting point. And it differs from visually highlighting
a field once the user has encountered a form validation error. For example,
a user misses or incorrectly fills out a mandatory field and when the form
is re-presented, those fields are visually highlighted with a
On 11/14/05, Geoff Deering wrote:
Why can't the braille software detect an empty form element and inform
the user it requires data? Is this an authoring tool problem or a
problem with the way standards are prescribed?
Agreed, Geoff. We really do need to know more. We'll need to add this to
the
G'day
Thanks for all the replies, you've confirmed my suspicions. It's
unfortunate that online accessibility/quality checking tools
still insist on this (especially when you have a client who likes
to see a mass of ticks with every tool you throw at his site).
I have the same concerns
Herrod, Lisa wrote:
Yes this is an interesting point. And it differs from visually highlighting
a field once the user has encountered a form validation error. For example,
a user misses or incorrectly fills out a mandatory field and when the form
is re-presented, those fields are visually
On 14/11/2005, at 1:02 PM, Bert Doorn wrote:
...
I might settle on adding value= (space) - shouldn't be hard to
change my scripts to strip leading spaces when checking if a field has
been completed.
...
Hi Bert
I would have thought that you would want to make your scripts check for
Derek Featherstone wrote:
On 11/14/05, Geoff Deering wrote:
Why can't the braille software detect an empty form element and inform
the user it requires data? Is this an authoring tool problem or a
problem with the way standards are prescribed?
Agreed, Geoff. We really do need to
Bert Doorn wrote:
Geoff, I know exactly what you mean with the greyed out fields. Came
across it myself only yesterday - a form where all inputs had a grey
background. It wasn't until I clicked in one of them that I realised
the field was not disabled.
Yes, someone please, who writes for
G'day
I would have thought that you would want to make your scripts check for
leading _and trailing_ spaces. Mouse users will often click into the
start of a field. When they enter text, they will end up with a
trailing space.
Although I tend to click somewhere in the middle (rather than
Geoff Deering wrote:
*Another* thing I see that is happening in design a lot lately is that
input fields are in greyed background by design, not function. What
this is telling the user is that that field is *read only*. That is the
standard way operating systems manage read only data, and
Patrick H. Lauke wrote:
Geoff Deering wrote:
*Another* thing I see that is happening in design a lot lately is
that input fields are in greyed background by design, not function.
What this is telling the user is that that field is *read only*.
That is the standard way operating systems
On 11/14/05, Geoff Deering wrote:
Mandatory data fields, Required data, fields that require correct data
after validation should all be grouped together with a
*fieldsetlegend*. This informs all users of the requirements of that
data.
Indeed - one of my favourite techniques:
Geoff Deering wrote:
I think it is quite simple, don't use any scale of grey at all. Grey is
reserved for meaning *read only*.
With all due respect, that sounds a tad too draconian for my
tastes...and it's exactly the kind of talk that will make web
*designers* simply stop listening to
On 14 Nov 2005, at 12:22 pm, Geoff Deering wrote:
*Another* thing I see that is happening in design a lot lately is
that input fields are in greyed background by design, not function.
What this is telling the user is that that field is *read only*.
That is the standard way operating
Patrick H. Lauke said:
I think it is quite simple, don't use any scale of grey at all. Grey is
reserved for meaning *read only*.
With all due respect, that sounds a tad too draconian for my
tastes...It needs to be evaluated on a case by case basis.
Ah, well, if you (royal you) really *must*
Derek Featherstone wrote:
Agreed. Putting them after *visually* and leaving them before in source
order, and as part of the label can be really useful - its semantically
meaningful, can be emphasized (using label em /em/label) as
shown in the second example on that page is useful. You
Philippe Wittenbergh said:
This makes kind of good argument for *not* styling form inputs at all,
and leave it to the OS. On most of my OS X browsers, disabled form
fields are not really greyed out, but rather use opacity reduction to
indicate read-only.
A quick test of unstyled input
Geoff Deering wrote:
Mandatory data fields, Required data, fields that require correct data
after validation should all be grouped together with a
*fieldsetlegend*. This informs all users of the requirements of that
data. Leave fields that do not meet this criteria outside this group,
Patrick H. Lauke wrote:
Geoff Deering wrote:
I think it is quite simple, don't use any scale of grey at all. Grey
is reserved for meaning *read only*.
With all due respect, that sounds a tad too draconian for my
tastes...and it's exactly the kind of talk that will make web
*designers*
Philippe Wittenbergh wrote:
This makes kind of good argument for *not* styling form inputs at all,
and leave it to the OS. On most of my OS X browsers, disabled form
fields are not really greyed out, but rather use opacity reduction to
indicate read-only.
Philippe
---
I agree with this
Terrence Wood wrote:
Philippe Wittenbergh said:
This makes kind of good argument for *not* styling form inputs at all,
and leave it to the OS. On most of my OS X browsers, disabled form
fields are not really greyed out, but rather use opacity reduction to
indicate read-only.
A quick
Graham Cook wrote:
Geoff Deering wrote:
Mandatory data fields, Required data, fields that require correct data
after validation should all be grouped together with a
*fieldsetlegend*. This informs all users of the requirements of that
data. Leave fields that do not meet this criteria outside
At lot of work went into the Telstra standards, it's a shame they never
utilised the knowledge within Rob Pedlow's Research team, because those
set of standards, that have been in use for almost half a decade, are
full of holes and misunderstandings.
The latest standards were published in
68 matches
Mail list logo
