- From: David Poehlman <poehlman1@comcast.net>
- Date: Fri, 30 May 2003 08:08:28 -0400
- To: "'w3c-wai-ig list'" <w3c-wai-ig@w3.org>
The bit of code that follows does not work for me in jaws 4.51 with ie6 on xp home with all updates and patches and the settings that matter at factory defaults. I have included the explanatory material for reference. "Figure 8.4 Image button with equivalent alt text The BUTTON element is a container that allows both images and text on a button. Images must have alt text as we discussed in Section 2. The following is an example. <BUTTON name="submit" type="submit"> <STRONG>Go</STRONG> <IMG src="nextarrow.gif" border="0" alt="Next page"> </BUTTON> Go Next page When the text carries the message of the button there is no need to also have alternative text on the image. In the example above, alt="next page" is used so the text on the button for assistive technology would be "go next page." When a button has focus, assistive technology knows to announce the content of that button including alternative text on images." ----- Original Message ----- From: "Jim Thatcher" <jim@jimthatcher.com> To: "'Mirabella, Mathew J'" <Mathew.Mirabella@team.telstra.com>; "'w3c-wai-ig list'" <w3c-wai-ig@w3.org> Sent: Thursday, May 29, 2003 10:22 PM Subject: RE: labels for form controls that don't have labels. Hi Mirabella, The answer (see http://jimthatcher.com/webcourse8.htm#webcourse8.6) is the title attribute on the input element. The only (good) reason for using the title element on a form control is when other information, like position (zip+4, telephone number, or a table) is telling a sighted user what to enter. JAWS, Window-Eyes and HPR will speak the title attribute of a form control. Jim 508 Web Accessibility Tutorial http://jimthatcher.com/webcourse1.htm. "Constructing Accessible Web Sites:" http://jimthatcher.com/news.htm -----Original Message----- From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On Behalf Of Mirabella, Mathew J Sent: Tuesday, May 27, 2003 10:49 PM To: w3c-wai-ig list Subject: labels for form controls that don't have labels. All. Thanks all for the discussion on the css instead of JavaScript issue. I have another issue for discussion... I am trying to find a way to make form controls accessible to screen reader users where the form control is one that ordinarily does not have an on-screen label, and cannot have one due to design constraints. Some examples are: 1. a checkbox that relates to an entire table row in a data table, the checking of which relates to the selection of a particular set of data in the table. i.e. the checkbox is the leftmost cell on the row, but the row consists of data that comes under the column headings such as date, phone number, time, cost, etc. Also other examples may be a set of radio buttons, one per row. One solution is to put label element tags around the whole row and use appropriate for and id attributes. But the reading of an entire row may be confusing to some users. 2. A series of edit fields designed to take parts of a phone number. I.e. country code, area code and number are separate, but the only on-screen label is the one for the entire set. One solution is to use invisible text labels (see below). 3. a series of form controls in different cells of the same row of a table where the table is a data table, but certain values need to be altered or set on submitting the form. One solution is to code the label around the form field itself or else a particular cell that best represents it. However, for all these examples, it is difficult to use label elements for each form control including a text label where there is no logical room for one on the screen. I have looked at the following solutions: 1. use visibility: hidden or display: none; for a span that covers the contents of the label , thus allowing a descriptive label to be included but not appearing on the screen. Some z-index and positioning styles may be required here as well. . However, new screen readers such as jaws 4.5x are now treating invisible text properly and not reading it. 2. Using title attributes for the input elements and not having labels at all. but this violates the guidelines. 3. Including label, but only to surround the form control itself, but not to include any real other label element content. Rather, include title attributes on both the label and input element as required. This seems the best solution at the moment. But it still does not involve label content and the behaviour may be somewhat dubious with some screen readers. Any other notes or ideas or discussion is welcome. Regards. Mat.
Received on Friday, 30 May 2003 08:10:36 UTC