W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2000

RE: Are Small Text buttons level 2 compliant

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 27 Sep 2000 10:34:01 -0400 (EDT)
To: "Leonard R. Kasday" <kasday@acm.org>
cc: WAI GL <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.21.0009271024160.14964-100000@tux.w3.org>
I think that there is a market requirement to be able to have fairly reliable
presentation of content. If there wasn't, I don't think we would have such a
profusion of techniques and methods, some of them really quite expensive and
difficult, used to provide it on a web that hasn't really been built to
support it.
 
(By reliable I mean won't change in the majority of browsers used by the
majority of people, where the term majority is being misused to mean
perceived majority)

There is an accessibility need to be able to read content.

I think these two constraints are going to stay with us, and we have to work
out how to make as much intersection as possible. 

It is worth clarifying that in some cases a presentation will need to be
changed, for example because a person who can't distinguish red from green
may not be able to distinguish the company logo from the background unless
they make a change to the presentation. But there is inherent value in (good)
presentation design, and branding promotes easy recognition which can be
valuable to people with certain types of disability. This applies as much to
the use of a little house icon to mean a home page as it does to the use of a
large yellow "m" to mean hamburgers in soft buns.

Charles McCN

On Wed, 27 Sep 2000, Leonard R. Kasday wrote:

  Another factor is how important a particular stylistic effect is, if it can 
  only be obtained with an image (which for the present, means bitmaps or 
  compressed versions thereof... in the future, like charles says, SVG gives 
  more flexibility)
  
  There's a discussion on this under the title "[WW] Use of Textual Graphics 
  on Web Pages" which was on the er list, but which I asked to be moved to 
  WAI-IG.  The title change came after I asked for opinions from web 
  designers and Kynn took the question to a designers list.. and got some 
  very helpful feedback.
  
  My personal opinion is that we need to distinguish between sites that are 
  fundamentally informational (e.g. a posting of zoning regulations on a 
  township web site) vs. those that are fundamentally artistic.  There's also 
  the category of commercial sites in which integrated text and graphics play 
  a strong branding role.   I realize this can all be very subjective.  On 
  the other hand, the law is full of subjective criteria.
  
  Like I say, I trying to put the discussion on the WAI-IG list.  Lets see 
  what comes up there.  I'll report back with my own take on it if you-all 
  would like.
  
  This may eventually be best put into the techniques document or some other 
  note.  I think will be hard to make crisp guidelines out of  this aspect of it.
  
  Len
  
  At 09:45 AM 9/27/00 -0400, Charles McCathieNevile wrote:
  >Note: ER and UA are not on the distribution list of this email except by
  >bcc, so will not get replies...
  >
  >I think there are two axes in what Len is saying here.
  >
  >One is whether there is a barrier of some kind, and the other is how big a
  >barrier there is. In WCAG terms this translates to whether we need a
  >checkpoint to deal with a problem, and what priority should be given to the
  >checkpoint.
  >
  >For the first, I think Len has identified a number of reasons why text is
  >better than images. To complicate that a little, there is now a markup
  >language called SVG, in which text (real text) can be presented using amazing
  >font effects. These things will most likely, in the immediate future, be
  >served as images, included in html documents with an img or object
  >element. How do they fit into the requirement.
  >
  >There is an alternative - to use  namespaces to combine several XML
  >types. This approach is being taken by Amaya to include MathML, XHTML, and
  >SVG (in the development version - release expected soon) in the one document,
  >so it will be using an appropriate markup language to present the content,
  >will have proper equivalent content, etc...
  >
  >As to priority: I guess it turns on what the difficulty presented is. There
  >is an ongoing (and necessary in my opinion) discussion on how to define what
  >we require of users, that is important input to this decision. The difference
  >between a P1 checkpoint and a P3 checkpoint is quite significant, but so is
  >the difference between a P3 checkpooint and no checkpoint at all.
  >
  >Charles McCN
  >
  >On Wed, 27 Sep 2000, Leonard R. Kasday wrote:
  >
  >   Some people are saying that it's OK to have small text in an image because
  >   the user can use a screen magnifier.
  >
  >   However, it's better to use HTML text, and let the user control the size,
  >   font, and color of the text directly, instead of using images text and a
  >   magnifier.  It's not just preference, convenience or even cost.  HTML text
  >   is a better accommodation for low vision, and has additional advantages
  >   when the user has motor or cognitive disabilities.
  >
  >   Note that this lets people who need small text to use it, while letting
  >   other folks enlarge the text.
  >
  >   I addressed this earlier, but unfortunately this discussion has gotten
  >   spread among so many lists that not everyone in the current discussion saw
  >   my answer [1] Here's the problem with screen magnifiers compared to 
  > HTML text.
  >
  >   1. When you use a screen magifier, you have to scoll left and right in
  >   addition to up and down, because  the screen expands into a virtual space
  >   larger than your screen.  If the screen itself has a scrollbar, you're
  >   using two scrolling mechanisms.  This significanttly adds difficulty in
  >   terms of keystrokes and in terms of "knowing where you are".  It's a
  >   signficant problem for anyone, and is even more of a difficulty for 
  > someone
  >   who has a motor or cognitive impairment.
  >
  >   On the other hand, if you design a page right, when you have real text and
  >   let the user enlarge fonts, the text simply wraps at the right margin and
  >   you don't run into this problem.  All you have to deal with is the 
  > vertical
  >   scrollbar on the regular window.
  >
  >   2. With a screen magnifier and image text, user is no longer able to
  >   control the font. Some fonts are better than others.   With HTML text, the
  >   user can control the fonts.
  >
  >   3. Some people with low vision need reverse contrast. If the buttons are
  >   already reverse contrast, then if they reverse the whole screen to read
  >   other body text, the buttons get normal contrast. So they have to keep
  >   flipping the contrast depending on where they are.
  >
  >   4. Similarly, if all you can do is an overall screen color map, you can't
  >   get all the text, buttons and body, to have optimal color.
  >
  >   Bottom line: HTML text is not mere pandering to preference, vanity,
  >   convenience, or even cost:  it's a superior accommodation.
  >
  >
  >   Len
  >
  >   [1]  http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Sep/0111.html
  >
  >   At 05:45 PM 9/26/00 -0700, Anne Pemberton wrote:
  >   >At 01:28 PM 9/26/00 -0400, Poehlman, David wrote:
  >   > >I explained this in the message.  what I disagree with is that the 
  > text can
  >   > >be small.  some people have low enough vision that they need larger 
  > text but
  >   > >not use assistives to achieve it.
  >   >
  >   >Isn't this like saying some people need glasses but are too vain to wear
  >   >them?  The advantage of the small text and small buttons is that these
  >   >elements can be present on a page without taking up space needed to 
  > present
  >   >the meat of the page on the opening screen.
  >   >
  >   >                                         Anne
  >   >Anne L. Pemberton
  >   >http://www.pen.k12.va.us/Pav/Academy1
  >   >http://www.erols.com/stevepem/Homeschooling
  >   >apembert@crosslink.net
  >   >Enabling Support Foundation
  >   >http://www.enabling.org
  >
  >   --
  >   Leonard R. Kasday, Ph.D.
  >   Institute on Disabilities/UAP and Dept. of Electrical Engineering at 
  > Temple
  >   University
  >   (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
  >   http://astro.temple.edu/~kasday         mailto:kasday@acm.org
  >
  >   Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
  >   http://www.w3.org/WAI/ER/IG/
  >
  >   The WAVE web page accessibility evaluation assistant:
  >   http://www.temple.edu/inst_disabilities/piat/wave/
  >
  >
  >--
  >Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
  >W3C Web Accessibility Initiative                      http://www.w3.org/WAI
  >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  >September - November 2000:
  >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, 
  >France
  
  --
  Leonard R. Kasday, Ph.D.
  Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
  University
  (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
  http://astro.temple.edu/~kasday         mailto:kasday@acm.org
  
  Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
  http://www.w3.org/WAI/ER/IG/
  
  The WAVE web page accessibility evaluation assistant: 
  http://www.temple.edu/inst_disabilities/piat/wave/
  

-- 
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
September - November 2000: 
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Wednesday, 27 September 2000 10:34:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:06 GMT