- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Wed, 14 Nov 2007 22:05:10 +0000
- To: w3c-wai-ua@w3.org
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