W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2007

autocomplete: ARIA Request for Input from DHTML Subteam

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Tue, 7 Aug 2007 01:38:48 -0400
To: wai-xtech@w3.org, wai-liaison@w3.org
Cc: DHTML_ACCESSIBILITY@LISTSERV.AOL.COM, Thomas.Wlodkowski@corp.aol.com, Donald.Evans@corp.aol.com
Message-Id: <20070807052304.M68767@hicom.net>

at monday's ARIA working group teleconference, i was asked to carry a 
query to the DHTML Subteam (or whatever the heck we're called) about 
autocomplete -- strategies, methods of exposition, implementations, 
and any information any of you (individually, collectively, universally)
have any data on user experience with auto-complete in all its various 
manifestations:

    * inline auto-complete

    * exposition of small bits of text to help/prompt user

    * combo box (or pseudo-combo box-like widget) uses a drop down 
      menu offering a choice of possible completions (as in the 
      drop down menu on many GUI browser's location bar)

as always, additional manifestation scenarios and use-cases are 
welcome...

in specific, here are some questions the ARIA Subteam would like 
discussed on XTech this week, in preparation for the next DHTML call, 
at which we request that these issues are addressed:

    * what are the (possible or implemented) mixed modes of 
      auto-complete mechanisms, such as inline auto-complete 
      exposing small bits of possible text as the user types, 
      while a drop down menu presents larger blocks of possible 
      text?

    * can you provide the user the ability to query the mixed mode 
      autocomplete widget by making the following options for 
      autocomplete available:

            1) autocomplete=true
            2) autocomplete=dropdown 
            3) autocomplete=textinput
            4) autocomplete=none

    * how does the user learn which of the four states is available?

    * if we accept the premise that anything that assists the user is a 
      hint, if a user can see the hint and/or the range of hints, that 
      user can simply pick whichever option serves that user best; but, 
      if the user can't see, how can the hints or the range of hints be 
      communicated to a non-visual user, aurally or tactilely?  what is 
      needed to endow the user of assistive technology with the ability 
      to query the assistive technology to ascertain the range of 
      possibilities available to the user in an autocomplete widget?

    * is there a standardized practice or a defined best practice for 
      the scenario outlined in the previous bullet point?  would anyone 
      care to propose one, or research whether one exists, and post the
      results and/or proposal to wai-xtech@w3.org? 

    * is the operating system's default escape key available to stop 
      autocomplete? what about providing the user with the option to 
      redefine/define the key used to stop autocomplete?  what about 
      speech input users, or those who use an on-screen keyboard?

    * is there a design standard for drop-down menus which is 
      universally followed?  would the expected mechanism for a mixed
      mode auto-complete enable the following:

           1. when encountering an editable combo-box, announce 
              to the user "blank text edit box with autocomplete" 
              -- when the user types, the screen reader echoes 
              the key (if that user option is turned on), issues 
              a user alert, pauses for a second, then (either 
              automatically or on user query) ennumerate choices, 
              dropdown a menu which the user navigates using the 
              arrow keys to scroll between options to choice, and
              then press enter.

           2. for an inline auto-complete, the screen reader could
              say the whole suggested word or ask the user, "did 
              you mean wordX"?  as soon as user input pauses, 
              auto-complete can try and complete word for them

for more information and context, consult the minutes of the 6 august 
2007 ARIA Subteam's teleconference, which are archived in 
member-confidential space at:

<http://lists.w3.org/Archives/Member/w3c-wai-pf/2007JulSep/0134.html>
or
<http://www.w3.org/2007/08/06-pf-minutes>

if you have access to member-confidential w3c space, the original post 
which sparked this query is archived at:

<http://lists.w3.org/Archives/Member/w3c-wai-pf/2007JulSep/0112.html>

thanks,
gregory.
PS: don't forget there's a DHTML meeting this friday, 10 august,
with DonE, i believe, chairing (or will tom be back?)
-------------------------------------------------------------
SELF-EVIDENT, adj.  Evident to one's self and to nobody else.
                    -- Ambrose Bierce, The Devil's Dictionary
-------------------------------------------------------------
    Gregory J. Rosmaita: oedipus@hicom.net
         Camera Obscura: http://www.hicom.net/~oedipus/
Oedipus' Online Complex: http://my.opera.com/oedipus
-------------------------------------------------------------
Received on Tuesday, 7 August 2007 05:39:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:43 GMT