Re: Part 2 Labels

I just finished running through some test material put up by Freedom
Scientific.  This is set up to demonstrate their implementation of the user
agent accessibility guidelines, in JAWS 4.5.  I use Window-Eyes, HPR and
Lynx instead of JAWS, but I think this is an  instructive test suite:

http://www.freedomscientific.com/HTML_challenge/html_challenge.html

Lynx and HPR can render the lists properly; Window-Eyes can only do it
while MSAA is turned off.  Similarly, Access keys and the dynamic HTML test
can only be done with W-E while MSAA is turned off.

It's really up to the screen reader developers to decide how much
information to expose while MSAA is in use.  And if you read through the
material from any screen reader/talking browser designer, you will find an
astounding number of hotkeys which a person might want to use, if they
could remember them all.  In JAWS, as was once the case in Window-Eyes, you
have to be careful what mode you're in.  Alphanumeric keys will be used for
typing when the virtual cursor is turned off, then they will invoke a host
of navigation functions while virtual cursor (MSAA) is turned on.  

We live in interesting times!

At 01:18 PM 10/2/02 -0700, you wrote:
>
>Oh, I should also add, Microsoft could really improve MSAA and the
>browser in general.  A majority of those who use screen readers use
>Internet Explorer, because it works overall better than say Netscape.
>
>Internet Explorer will not allow for access keys, nor does MSAA send
>information to the screen reader about field sets (according to GW
>Micro), for example.
>
> From a users standpoint, I find it extremely disappointing the browser
>developers, screen reader developers, and the website designing people
>cannot seem to agree to, and actually follow, guidelines.  W3C has done
>a pretty good job at writing the guidelines, its just everyone else who
>pick and choose what they want to implement.
>
>>From a designers standpoint, I also find it frustrating when I follow
>WAI guidelines, but they don't work because the screen readers and
>browsers don't go a long with their end of the "bargain"  It's a bit
>strange to have to violate the WAI guidelines to make the website
>accessible.  That just doesn't make sense.  <puzzled look>
>
>I really would like to be able to design a website which is screen
>reader friendly and look good visually too.  Why can't these two things
>work together?  I would think it could be quite possible.  Why should a
>designer have to sacrifice "looks" for accessibility and usability?
>
>As someone who is blind, I use the Internet everyday.  The Internet is
>probably one of the neatest inventions.  As an example, in a lot of
>cases, I no longer have to depend on a reader to help me with research
>papers for school.  I can go onto the Internet, type in a few keywords
>on my favorite search engine, and like magic, there it is!  When at
>least the minimum accessibility techniques are implemented by website
>designers, I can at least get what I'm looking for, all be it stressful
>to have to listen to a bazillion links on a navigation bar, for example.
>
>
>I know I am preaching to the choir, so I'll get off my soapbox.  I truly
>appreciate everything you are all doing to improve access for people
>like me.
>
>Warmly,
>Hy
>
>-----Original Message-----
>From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
>Behalf Of Charles McCathieNevile
>Sent: Wednesday, October 02, 2002 12:28 PM
>To: Hy Cohen
>Cc: w3c-wai-ig@w3.org
>Subject: RE: LABEL Tag Question
>
>
>
>Hy wrote to me:
>
>I think you are misunderstanding something.  Window-Eyes users will not
>get the title if there is a label.  The label takes priority.  Only if
>there is not a label will Window-Eyes read the title.
>
>And he was right - I had misunderstood. So I think you need to go with
>including the extra information in the label. sigh. (If there is a title
>on the label element does it get any better?)
>
>Also, is it really Window-Eyes' fault, or is it something in MSAA, or is
>it just an interaction between the two that is underspecified?
>
>Cheers
>
>Chaals
>
>On Wed, 2 Oct 2002, Charles McCathieNevile wrote:
>
>>
>>well, it sounds like you have a few possibilities:
>>
>>1 You can remove the content of the label element (which is what that
>>most
>>  people will get) and put it in the title element (which screen-reader
>users
>>  will get.
>>
>>This strikes me as an extremely bad idea. People with low vision whose
>>browser settings distort the layout will not be able to associate a
>>label with a control any more, except by guessing. It is also
>>instructing people to avoid doing things according to the agreed
>>standard - generally a bad idea if you rely on systems being designed
>>to use content developed to a standard.
>>
>>2 You make the labels have more in them than you might otherwise, and
>>not
>>  have a title, so Window-Eyes users get what everyone else does.
>>
>>This seems workable in general, but not the most aesthetically pleasing
>
>>approach.
>>
>>3 You can use labels, with titles to carry more substantial information
>
>>that
>>  is to some extent redundant - Window-Eyes users will get that by
>default
>>
>>This seems like the best compromise to me.
>>
>>4 You can use labels, with titles only carrying supplemental
>>information,
>>  which means Window-eyes users only get the supplemental information
>until
>>  they are able to read the content of labels in a new version.
>>
>>This would be fine if people were more fussy about not using software
>>that has bugs in it, but in the real world that still seems an
>>impossible demand. The software is getting better, but there is a way
>>to go. (Not talking about any product, just about all the software I
>>have ever used).
>>
>>Cheers
>>
>>Chaals
>>
>>On Wed, 2 Oct 2002, Hy Cohen wrote:
>>
>>>
>>>True, however, I know Window-Eyes, which is  a fairly common screen
>>>reader, will not tell you the TITLE if there is a LABEL.  It would be
>>>odd to put the instructions for the field in every LABEL.  The TITLE
>>>is much more appropriate place, but to force Window-Eyes to read the
>>>TITLE I cannot use a LABEL.  As long as the TITLE will work at meeting
>
>>>the WAI guidelines as a sub for LABEL, then that is fine.  I'm just
>>>trying to meet WAI guidelines but still make the Window-Eyes read all
>>>the important info without having to switch MSAA mode on and off.  As
>>>a screen reader user myself, I know how annoying that is.  <smile>
>>>
>>>Warmly,
>>>Hy
>>>
>>>-----Original Message-----
>>>From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org] On
>>>Behalf Of Charles McCathieNevile
>>>Sent: Wednesday, October 02, 2002 9:22 AM
>>>To: Phill Jenkins
>>>Cc: w3c-wai-ig@w3.org
>>>Subject: Re: LABEL Tag Question
>>>
>>>
>>>
>>>It is true that the title is something that might be a tooltip. The
>>>point is that title is extra information users might not get (or might
>
>>>not ask for). The label will be presented to everyone. So repeating
>>>information from the label in the title seems an odd thing to do -
>>>that should be additional, supplementary information.
>>>
>>>Chaals
>>>
>>>On Wed, 2 Oct 2002, Phill Jenkins wrote:
>>>
>>>>>> title="Please enter the minimum required age for
>>>>>> this activity, or leave blank for no minimum age."> <label
>>>>>
>>>>>This is an abuse of title.  title is *not* a tool-tip.  It is
>>>>>grammatically a noun, not an imperative.
>>>>
>>>>Actually, the title attribute is rendered as a tool tip in most
>>>>graphical browsers, and more importantly, is described as such in the
>
>>>>HTML spec.
>>>>
>>>>See http://www.w3.org/TR/html401/struct/global.html#adef-title
>>>>
>>>><quote>
>>>>... offers advisory information about the element ... may annotate
>>>>... 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. For example, setting the attribute
>>>>on
>>>
>>>>a link allows user agents (visual and non-visual) to tell users about
>
>>>>the nature of the linked
>>>>resource:
>>>><end quote>
>>>>
>>>>Regards,
>>>>Phill Jenkins,  IBM Research Division - Accessibility Center
>>>>
>>>>
>>>
>>>--
>>>Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409
>
>>>134 136 SWAD-E http://www.w3.org/2001/sw/Europe ------------ WAI
>>>http://www.w3.org/WAI  21 Mitchell street, FOOTSCRAY Vic 3011,
>>>Australia
>>>fax(fr): +33 4 92 38 78 22  W3C, 2004 Route des Lucioles, 06902 Sophia
>>>Antipolis Cedex, France
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>--
>Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409
>134 136 SWAD-E http://www.w3.org/2001/sw/Europe ------------ WAI
>http://www.w3.org/WAI  21 Mitchell street, FOOTSCRAY Vic 3011, Australia
>fax(fr): +33 4 92 38 78 22  W3C, 2004 Route des Lucioles, 06902 Sophia
>Antipolis Cedex, France
>
>
>
>
>
>
>
Braille is the solution to the digital divide.
Lloyd Rasmussen, Senior Staff Engineer
National Library Service f/t Blind and Physically Handicapped
Library of Congress    (202) 707-0535  <lras@loc.gov>
<http://www.loc.gov/nls>
HOME:  <lras@sprynet.com>       <http://lras.home.sprynet.com>

Received on Wednesday, 2 October 2002 16:39:44 UTC