Re: Add partial sight/low vision to face to face agenda [was Are accessibility guidelines defined for the blind?

I disagree with this suggestion.  I believe the points that are being 
discussed are a WCAG issue not a tool issue.  Now is the prime time to take 
these issues to the WCAG working group as they have begun thinking about 
revising the guidelines - particularly to address cognitive and learning 
disabilities and to generalize the checkpoints so that they are less HTML 
specific.

Also, I don't believe enough credit is being given to what WCAG already 
addresses in regards to low vision.

Here are some excerpts from WCAG 1.0:

Content developers must consider these different situations during page 
design. While there are several situations to consider, each accessible 
design choice generally benefits several disability groups at once and the 
Web community as a whole. For example, by using style sheets to control 
font styles and eliminating the FONT element, HTML authors will have more 
control over their pages, make those pages more accessible to people with 
low vision, and by sharing the style sheets, will often shorten page 
download times for all users.

Content developers must consider these different situations during page 
design. While there are several situations to consider, each accessible 
design choice generally benefits several disability groups at once and the 
Web community as a whole. For example, by using style sheets to control 
font styles and eliminating the FONT element, HTML authors will have more 
control over their pages, make those pages more accessible to people with 
low vision, and by sharing the style sheets, will often shorten page 
download times for all users.

(from the rationale of Guideline 1)
This guideline emphasizes the importance of providing text equivalents of 
non-text content (images, pre-recorded audio, video). The power of text 
equivalents lies in their capacity to be rendered in ways that are 
accessible to people from various disability groups using a variety of 
technologies. Text can be readily output to speech synthesizers and braille 
displays, and can be presented visually (in a variety of sizes) on computer 
displays and paper. Synthesized speech is critical for individuals who are 
blind and for many people with the reading difficulties that often 
accompany cognitive disabilities, learning disabilities, and deafness. 
Braille is essential for individuals who are both deaf and blind, as well 
as many individuals whose only sensory disability is blindness. Text 
displayed visually benefits users who are deaf as well as the majority of 
Web users.

Related Checkpoints:
2.1 Ensure that all information conveyed with color is also available 
without color, for example from context or markup. [Priority 1]

2.2 Ensure that foreground and background color combinations provide 
sufficient contrast when viewed by someone having color deficits or when 
viewed on a black and white screen. [Priority 2 for images, Priority 3 for 
text].

3.1 When an appropriate markup language exists, use markup rather than 
images to convey information. [Priority 2]
For example, use MathML to mark up mathematical equations, and style sheets 
to format text and control layout. Also, avoid using images to represent 
text -- use text and style sheets instead. Refer also to guideline 6 and 
guideline 11.

WAC note: if markup is used rather than images, text can be displayed 
however the user chooses.  the user can choose size, color, and font.

3.3 Use style sheets to control layout and presentation. [Priority 2]
For example, use the CSS 'font' property instead of the HTML FONT element 
to control font styles.

WAC note: Again, this is giving control to the users.

3.4 Use relative rather than absolute units in markup language attribute 
values and style sheet property values. [Priority 2]
For example, in CSS, use 'em' or percentage lengths rather than 'pt' or 
'cm', which are absolute units. If absolute units are used, validate that 
the rendered content is usable (refer to the section on validation).

WAC note: this gets at the issue that Len mentioned.  If relative units are 
used, when the font is increased the layout should adjust so that there is 
not overlap.

--wendy

At 09:36 AM 5/2/00 , Leonard R. Kasday wrote:
>I'd  suggest we add a discussion of partial sight/low vision to the face 
>to face agenda to follow up on the points made by Peter.
>
>How about planning on an hour's worth after lunch on Thursday?  We would 
>of course to either omit things now in that slot or move them and omit others.
>
>Len
>
>
>At 09:36 AM 5/2/00 +0200, Peter Verhoeven wrote:
>>Hi,
>>
>>This is not the first time that I bring up this point, but because I got
>>less responce here a new try.
>>
>>The WAI often mentions numbers of people that having problems accessing
>>web pages of the Internet. I often read the number 10 million. Are those
>>10 million people blind? No, they are not blind at all. A lot of them
>>are sight impaired which is not the same.
>>In the "quick tips" I read only tips to make web pages accessible to
>>blind, or maybe to make web pages accessible by using Lynx? If I check
>>web pages with real accessibility problems for sight impaired with
>>Bobby, it tells me Congratulations your web page is Bobby Appoved. I
>>only need to do some manual checking, but all these checkpoints have
>>nothing to do with things like universal design and color contrast.
>>
>>A growing number of web pages are designed "system dependent" that
>>means, that if I don't have a special display resolution or font size
>>setting a lot of information on the web pages is outside my screen and
>>the only way to access is to track on bars.
>>Some web designers don't like trackbars and disable them, so it becomes
>>realy impossible to get some information on the page. But the page is
>>Bobby approved (Congratulations!).
>>
>>In the statistics from visitors to my web site The Screen Magnifiers
>>Homepage at http://www.magnifiers.org I see that 25% of my visitors have
>>a display resolution of 640x480. We as sight impaired use this
>>resolution often because the the text on hte screen is much lagere than
>>in a higher resolution and setting a high resolution means that you need
>>a more powerful system with more memory to let a screen magnifier
>>performs well.
>>
>>A lot of these problems occurs in table and frames constructions and
>>personaly I know it is often difficult to solve these problems also if
>>you specified a table width of 640. If an image inside the table is
>>larger than 640 or a word in a cell is larger the width of the table
>>increases. A lot of web designers don't want to use percentages for
>>defining table widh, because the lines of text becomes so long if
>>someone has set a high display resolution. The problem "long line" seems
>>to have a higher priority than "horizontal scrollbars".
>>
>>In my opinion a lot of these problems could be solved by the makers of
>>browsers.
>>In my opinion more attention is needed for accessibility problems that
>>partially sighted have?
>>
>>Regards Peter Verhoeven
>
>--
>Leonard R. Kasday, Ph.D.
>Institute on Disabilities/UAP, and
>Department of Electrical Engineering
>Temple University
>423 Ritter Annex, Philadelphia, PA 19122
>
>kasday@acm.org
>http://astro.temple.edu/~kasday
>
>(215) 204-2247 (voice)
>(800) 750-7428 (TTY)

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Wednesday, 3 May 2000 08:00:55 UTC