further thoughts on auto-complete (left-over from f2f)

aloha, all!

whilst we must examine the accessibility of auto-complete mechanisms,
and define precisely what is needed to control an auto-complete 
mechanism, we must not forget that auto-complete was originally 
implemented as an accessibility aid to those using alternate input,
those with cognitive processing issues, etc., and that any deconstruction
of auto-complete mechanisms, must stress the importance of auto-complete
mechanisms to accessibility and usability...

the important thing is that the state and properties of the auto-complete
implementation should be:

a) available as implemented

b) available as customized by the end user (each feature of the 
   auto-complete MUST be configurable, or at least toggle-able 
   [refer also to Note 1, below] 

c) programmatically available to an AT

d) completely disabled

point C, above, requires that there be an "intermediary" step between 
an auto-complete prompt (or multiple prompts generated by a single 
control) and its execution -- AT users will want to inspect the 
auto-complete mechanism in order to:

1. ascertain the range of options available to the user through the 
   implementation;

2. ascertain what has been entered into the auto-complete field and what
   is generated/being generated by the mechanism as a prompt or suggested 
   ending

3. ascertain how the range of actions available to the user are invoked or
   rejected/ignored

this should be outlined so as to make it clear that a native solution 
needs to be available; "doing more" would entail supporting ARIA states 
and properties but it must be remembered that ARIA is author-dependent, 
and should not be used as an excuse for a UA to slough responsibility for 
controlling auto-complete (or any other mechanism) exclusively onto the 
document author or a framework such as ARIA, especially since ARIA, as 
currently specified, has no effect on a UA save for enabling interaction
with ATs, providing bindings where none are programmatically indicated, 
and providing contextual information about the control/widget to the user
via an AT

implementing ARIA support, would, of course, be a good thing in and of 
itself, but the ARIA support for an interactive control (or potentially
interactive control) must also include support for ARIA's politeness 
levels


i hope i've expressed myself clearly -- this hasn't been a week conducive 
to coherent thought

gregory.

[Note 1] what was once the worst out-of-the-box implementation of an 
auto-complete mechanism, that of SeaMonkey, has markedly improved in 
subsequent releases -- the options offered the end user by SeaMonkey
make a good starting point for auto-complete control implementation -- 
note that (a) the convention "[ ]" is used to indicate a checkbox, and 
(b) the default setting is: "Location Bar Autocomplete" and all of its
sub-properties enabled:

"Location Bar AutoComplete"

[ ] Automatically complete text typed into the Location Bar
[Advanced Button]

activating the "Advanced" button generates an "Autocomplete Preferences"
property sheet, which offers the following options:

Autocomplete Preferences
 [ ] Autocomplete best match as you type
 [ ] Show list of matching results
 [ ] Show internet search engine
 [ ] Match only websites you've typed previously


more information is available at:
http://www.seamonkey-project.org/releases/seamonkey1.1.6/

---------------------------------------------------------------------
A conclusion is simply the place where someone got tired of thinking.
                                                      -- Arthur Bloc
---------------------------------------------------------------------
   Gregory J. Rosmaita - oedipus@hicom.net AND gregory@ubats.org
        Camera Obscura: http://www.hicom.net/~oedipus/
---------------------------------------------------------------------

Received on Wednesday, 14 November 2007 22:05:18 UTC