JAWS reads legends in 'virtual cursor mode' and in 'forms mode' but it reads them differently in the two modes.
In 'virtual cursor mode', which is the normal mode of operation for websites and PDFs, it will simply read the legend when it reaches that element. It does not announce the element type so it is indistinguishable from paragraph text. In 'forms mode' the legend is read before the label for each form control in the fieldset. If there are no form controls in the fieldset it will not get read at all. JAWS also does not handle definition lists at all well, which is one reason I oppose their use unless there is a very good reason for using them. Another reason is that although JAWS announces the start of a definition list, I have yet to meet a user who knows what one is. Unfortunately even the most recent version of JAWS does not announce the start of a new list item (i.e. a <dt> element), whereas it does announce each <li> in ordered or unordered lists. Worse still, it does not tell the user how many <dd> elements there are for each list item. The result is that the user cannot make any sense of the content because it is simply one piece of content after another with no indication of the structure. By contrast, a data table containing the same data is far easier to understand and to navigate because JAWS can read the row and column headers for a cell and can navigate both vertically and horizontally, which it cannot do with a definition list. >From memory, Lucien's example would be read as: staff details Definition list of two items email [EMAIL PROTECTED] Phone 12345678 That is actually quite understandable even though JAWS cannot use any of the semantic structure that has been provided, but that may not be the case depending on the content. Of course one could argue that JAWS should handle definition lists better, and I would agree. I still say that the use of the fieldset it entirely wrong and that apart from the visual effect it provides no semantic value to any user agent. Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Gleitzman Sent: 06 June 2007 04:26 To: wsg@webstandardsgroup.org Subject: Re: [WSG] What does Semantic mean? Lucien Stals wrote: > I suspect that the following code... > > <fieldset><legend>staff details</legend> <dl> > <dt>email</dt><dd>[EMAIL PROTECTED]</dd> > <dt>phone</dt><dd>12345678</dd> > </dl> > </fieldset> > > Is perfectly valid, semantic markup which a screen reader would render > just fine. Logical, no doubt of it. But see Steve Green's post which said, "JAWS ... can only enter 'forms mode' when a form control has focus." Does that mean that JAWS won't read the contents of the <legend> element because it's not in 'forms mode'? And if not, how important is it for clarification of what follows that the legend be read? If the answer to that is 'not', or 'optional', there's not much point in including it - is there? > But can I point out, Ben, that at no time did anyone ever suggest > placing form elements in the middle of general content. I'm not sure > where you got that one from. I understood Ben to be referring to the <fieldset> element itself. But if a <fieldset> is a form element, and is used out of context of a form and its controls, then it *is* "...a form element cropping up in the middle of general content..." - isn't it? Don't you just love circular arguments? Whoops, discussions? N PS Before anyone gets bent out of shape by minimal quotes from previous posts changing their context or meaning, can I respectfully remind them that the previous posts and threads are always there for refererence? ___________________________ omnivision. websight. http://www.omnivision.com.au/ ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ******************************************************************* ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
