RE: 10.4 Re: Checkpoints 10.4 and 10.5

Hi Phil,

This sounds like a big shift from what I understood this check point to be
originally about.  It was my impression that this was originally for the
days when there really wasn't good keyboard access in graphical browsers
so AT users had to hunt around a few pixels at a time clicking to find
edit boxes.

This sounds like a shift to addressing a situation where visual layout
doesn't afford for correct labeling perhpps?

I think folks have to be careful with default text in actual input
controls.  In places where it exists, I've seen users get into an endless
loop because they start editing that default text.

When everything works correctly, the default text is replaced as soon as
the user starts typing in the idit box but I've experienced both JAWS and
Window-Eyes users really getting into a bind where edit controls have
existing text.

I'm not saying it is a bad idea, but I for one would hope it is a
technique of last resort.

Then again from strictly a usability perspective some folks find it
helpful to have the default text there, disabled or not.


On Thu, 31 May 2001, Phill Jenkins wrote:

> Now back to the initial discussion.  When the "Checkpoint 10.4 states
>   'Until user agents handle empty controls correctly,
>   include default, place-holding characters in edit
>   boxes and text areas.'
> I believe that guidelines working group should do several things.  If I add
> the word "can" in between agents and handle, as in 'Until user agents can
> handle empty controls', I get a slightly different meaning and question in
> my mind.  By the way, most assistive technologies can handle the control.
> By "handle" I mean announce that it is a control, provide magnification
> focus, and do speak the label if there is one [see other checkpoint].  The
> question that has been discussed, is what should AT's do when the control
> is empty. So the working group needs to:
> 1. Define "correctly" for the user agents/ assistive technology developers
> - which in my opinion is a "usability"  issue.  But how are AT's supposed
> to better handle empty controls?  They can't.  They can't do any more than
> is being done; they already announce that it is a edit box, or announce
> that it has 7 select menu items, or a text area.  The usability point is to
> not leave them empty in some situations.  The checkpoint should be
> re-worded to say something like: "Include default, context explaining text
> in the input fields so that user agents can better present controls -
> priority 3".  The magnifier vendors and the screen reader vendors should be
> the ones to form a sub group to agree on example techniques of default text
> that would lead to better usability of the presentations of the controls.
> The techniques [1] currently don't address the issue.  They could start
> with the simple forms that don't need place holder text, and then show more
> complex examples [usually because of layout] where the context is only
> available visually and where place-holder text is useful.  [see this
> thread] This has to be carefully crafted and agreed to so we don't have
> some vendors off supporting the title attribute and recommending it to web
> authors, or others always requiring place-holder text, and still others
> with some other approach.
>
> [1] 11.5 techniques http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-specific
>
> Regards,
> Phill Jenkins
>

Received on Thursday, 31 May 2001 21:19:28 UTC