- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Thu, 5 Apr 2007 13:53:05 +0100
- To: "Jon Gunderson" <jongund@uiuc.edu>
- Cc: wai-xtech@w3.org, wai-xtech-request@w3.org
- Message-ID: <55687cf80704050553j42b2e486j19ed2441b8d97cc7@mail.gmail.com>
There are a few issues to take into account inregards to use of the status bar: *Situations where the status bar is hidden, such as scripted windows. * Undermines the implicit relationship (contiguity) between a link text and an associated title text. * Screen magnifier users will often not have the status bar in view. stefan said: "is a interesting proposal (but what to do with veeery long tooltips, won't they be truncated?). " In firefox/mozilla the title text longer than 75 characters is truncated. On 30/03/07, Jon Gunderson <jongund@uiuc.edu> wrote: > > I suggest that the title content appear in the status bar when keyboard > focus moves to an item with a "tooltop" title. Make the browser could have > a default stylesheet options to identify items with tooltip with an icon > beofre or after the link. > > Jon > > > ---- Original message ---- > >Date: Fri, 30 Mar 2007 08:46:56 +0100 > >From: "Steven Faulkner" <faulkner.steve@gmail.com> > >Subject: RE:: Thoughts about tooltips > >To: wai-xtech@w3.org, wai-xtech-request@w3.org > > > > Hi Becky, > > a comment on Stefan's assertion: > > <stefan> > > >FIRST STATEMENT: Originally title attribute is > > designed to host tooltip > > >strings. > > >It should solely remain for this purpose and > > explecitely designated by > > >W3C for this. > > </stefan> > > > > The original documentation of title attribute > > display (HTML 2.0 specification - > > http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.7.3 > > ) is not prescriptive about how the title attribute > > is designed to be displayed: > > > > "suggests a title for the destination resource > > --- advisory only. The TITLE attribute may be > > used: > > * for display prior to accessing the > > destination resource, for example, as a > > margin note or on a small box while the > > mouse is over the anchor, or while the > > document is being loaded; > > * for resources that do not include a title, > > such as graphics, plain text and Gopher > > menus, for use as a window title. " > > > > It only suggests a number of possible display > > scenarios. > > > > The HTML 4.01 specification does not prescribe > > how title attribute content is to be conveyed > > to the user > > > > "Values of the title attribute may be rendered > > by user agents in a variety of ways. For > > instance, visual browsers frequently display > > the title as a "tool tip" (a short message that > > appears when the pointing device pauses over an > > object). Audio user agents may speak the title > > information in a similar context. " > > [http://www.w3.org/TR/html401/struct/global.html#adef-title] > > > > But it does clarify its intended function in > > relation to accessibility: > > > > 2.3.2 Accessibility > > > > "As the Web community grows and its members > > diversify in their abilities and skills, it is > > crucial that the underlying technologies be > > appropriate to their specific needs. HTML has > > been designed to make Web pages more accessible > > to those with physical limitations. HTML 4 > > developments inspired by concerns for > > accessibility include:" > > > > "Support for the TITLE and lang attributes on > > all elements." > > [http://www.w3.org/TR/html401/intro/intro.html#h-2.3.2 > > ] > > > > > > > > So i suggest that: > > * The title attribute is not solely "designed > > to host tooltip strings" and has not been > > "explecitely designated by W3C for this." > > * The function of the title attribute and its > > common visual display characteristics (as a > > tooltip) are being incorrectly conflated in > > this discussion. > > Becky wrote: > > > > "I don't want to make tooltips visible onfocus > > because I think that would be > > annoying to both keyboard and screen reader > > users." > > > > In Windows 'tooltips' are displayed on focus. > > (example: navigating through the start menu > > shows tootips on items where present) > > > > For screen reader users some indication that > > advisory information is available needs to be > > provided, as it would be impratical to expect > > users to query each focusable element to find > > out whether it has a "tootip" or not. It has > > been suggested that for screen reader users and > > sound such as a "beep" could indicate the > > presence of advisory information, but i would > > suggest that the repeated sound of a beep would > > be more annoying than actually hearing the > > title attribute content after the focused > > element content is announced. > > > > The same applies for keyboard users, if no > > indication that content is displayed, how are > > they to know that they need to use a keystroke > > to display the advisory information? > > > > Having a user agent preference to show/announce > > title attribute information on focus would be a > > possible method. > > > > > > > > On 29/03/07, Becky Gibson > > <Becky_Gibson@notesdev.ibm.com > wrote: > > > > parts of original mails copied below. > > > > <stefan> > > >FIRST STATEMENT: Originally title attribute > > is designed to host tooltip > > >strings. > > >It should solely remain for this purpose and > > explecitely designated by > > >W3C for this. > > </stefan> > > > > Yes, but the browser doesn't make these > > keyboard accessible and we need > > that support today. Also, people want to be > > able to create rich text > > tooltips. > > > > <stefan> > > >SECOND STATEMENT: I don't want to have > > describedBy to be used for the > > >tooltip BY ANY MEANS. > > </stefan>(more details in original response) > > > > Well, I don't feel that strongly but can > > understand Stefan's concerns. > > > > <becky original post> > > visual indicator that a tooltip is available > > Tooltips could be given the ARIA role of > > alert so a screen reader will > > speak the alert when it is made visible or > > Tooltip can be implemented > > via > > the described by property on the trigger > > element. > > </becky> > > > > <stefan> > > NOOOOOOOOOOO, MUST BE SCREEN READER > > CONFIGURABLE IF TOOLTIP SPOPKEN ON > > FOCUS OR NOT > > </stefan> > > > > I understand Stefan's concern that the > > browser and screen reader should > > make the title attribute accessible, but > > there is currently not a > > mechanism to do this. People want to create > > tooltips today that are > > keyboard accessible and may include > > rich/formatted text. Given that, my > > question still remains? How should these > > tooltips be made accessible? > > > > My current feel is to create some keyboard > > command like up ctrl-up arrow > > or shift-up arrow but I have to try and find > > some combination that has the > > least conflicts with assistive technology. > > This would be a "discoverable" > > tooltip - there may be no visual indicator > > that a tooI exists. I don't > > want to make tooltips visible onfocus because > > I think that would be > > annoying to both keyboard and screen reader > > users. I need to implement > > something for dojo tooltips and dojo > > tooltip-dialogs (these allow other > > focusable elements within them). So feedback > > from more folks on the > > preferred mechanism to make tooltips > > accessible to keyboard and screen > > reader users would be appreciated. See the > > thread for more details [1] > > > > thanks, > > -becky > > > > [1] > > http://lists.w3.org/Archives/Public/wai-xtech/2007Feb/0033.html > > > > Becky Gibson > > Web Accessibility Architect > > > > IBM Emerging Internet Technologies > > 5 Technology Park Drive > > Westford, MA 01886 > > Voice: 978 399-6101; t/l 333-6101 > > Email: gibsonb@us.ibm.com > > > > -- > > with regards > > > > Steve Faulkner > > Technical Director - TPG Europe > > Director - Web Accessibility Tools Consortium > > > > www.paciellogroup.com | www.wat-c.org > > > > -- > > with regards > > > > Steve Faulkner > > Technical Director - TPG Europe > > Director - Web Accessibility Tools Consortium > > > > www.paciellogroup.com | www.wat-c.org > > > Jon Gunderson, Ph.D. > Director of IT Accessibility Services > Campus Information Technologies and Educational Services (CITES) > and > Coordinator of Assistive Communication and Information Technology > Disability Resources and Education Services (DRES) > > Voice: (217) 244-5870 > Fax: (217) 333-0248 > Cell: (217) 714-6313 > > E-mail: jongund@uiuc.edu > > WWW: http://cita.rehab.uiuc.edu/ > WWW: https://netfiles.uiuc.edu/jongund/www/ > > > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org
Received on Thursday, 5 April 2007 12:53:22 UTC