RE: Are Small Text buttons level 2 compliant

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/

Received on Wednesday, 27 September 2000 10:18:25 UTC