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

some comments on text version of aug 9 guidelines draft

From: David Poehlman <poehlman@clark.net>
Date: Tue, 10 Aug 1999 12:24:04 -0400
Message-ID: <37B05224.1EE447A1@clark.net>
To: draft@clark.net, WAI User Agent Working Group <w3c-wai-ua@w3.org>
I've attached a document containing comments and commented portions of
the aug 9 draft <text version> of the ua guidelines for archiving and
review.  I have several designations just after the *dp* that
indicates my comments.  <lang> is a language comment>, <proof> catches
what may be a slip up in typing or composition, <question> and there
are lots of these seeks clarification either in the document or from
others as to how the commented portion should be understood.  <slant>
concerns my take on the slant on the current document and how that
might change or could change to make it more reflective and palatable
under certain circumstances, and I think the last is <comment general>
there is only one of these and it will be easy to understand.
Thanks! 
-- 
Hands-On Technolog(eye)s
Touching The Internet:
mailto:poehlman@clark.net
Voice: 301.949.7599
ftp://ftp.clark.net/pub/poehlman
http://poehlman.clark.net
Dynamic Solutions Inc.
Best of service
for your small business
network needs!
http://www.dnsolutions.com

---sig off---
   
Abstract

   This document provides guidelines to user agent manufacturers for
   making their products more accessible to people with disabilities and
   for increasing usability for all users. This document emphasizes the
   accessibility of interoperability between two important classes of
   user agents - graphical desktop browsers and dependent assistive
   technologies (screen readers, screen magnifiers, braille displays, and
   voice input software). However, it is meant to be applicable to user
   agents in general, including text and voice browsers, multimedia
   players, and plug-ins.
   *dp* <lang> I propose we change manufacturers to either developpers or manufacturers / developpers or manufacturers and or developpers or some permutation there of? This being as some will develop for manufacturers and some will develop for other reasons.  If a manufacturer, of course, it is the primary responsibility of the manufacturer to put the stamp of approval on the product.
   
   1. Introduction

   For those unfamiliar with accessibility issues pertaining to user
   agent design, consider that many users may be using documents in
   contexts very different from your own:
     * They may not be able to see, hear, move, or may not be able to
       process some types of information easily or at all.
     * They may have difficulty reading or comprehending text.
     * They may not have or be able to use a keyboard or mouse.
     * They may have a text-only screen, a small screen, or a slow
       Internet connection.
     * They may not speak or understand fluently the language in which
       the document is written.
     * They may be in a situation where their eyes, ears, or hands are
       busy or interfered with (e.g., driving to work, working in a loud
       environment, etc.).
   *dp* <lang> the use of the word document above fits well with the wcad, but since this is the ua document, shouldn't the word application be here instead?  Or even better, user agent sans browser?
    
   The guidelines in this document are designed to help developers
   understand and thereby reduce accessibility barriers that impede
   access to the Web. The associated Techniques Document
   ([UA-TECHNIQUES]) provides practical solutions based on existing and
   upcoming technologies. Though developers may believe that implementing
   accessibility features in their products is difficult or of limited
   use, considering accessibility during the design phase of a product
   leads to more flexible, manageable, and extensible software.
   *dp* <slant> earlier in the document, we tallk about hands busy and eyes busy, so I propose that we change the above and similar wording to reflect a more positive move  integrating features that make access more universal?  I have taken a stab at this below: 

   The guidelines in this document are designed to help developers
   understand and thereby impliment solutions which broaden accessibility  
   to the Web. The associated Techniques Document
   ([UA-TECHNIQUES]) provides practical solutions based on existing and
   upcoming technologies. Though developers may believe that implementing
   accessibility features in their products is difficult or of limited
   use, considering accessibility during the design phase of a product
   leads to more flexible, manageable, and extensible software.

   these guidelines include information relevant to a wide class of user
   agents: graphical desktop browsers, screen readers, speech
   synthesizers, multimedia players, text browsers, voice browsers,
   plug-ins, etc., with a particular focus on two classes of user agents:
    1. Graphical desktop browsers
    2. Dependent user agents, which rely on other user agents for input
       and/or output. Dependent user agents include:
          + screen magnifiers, which are used by people with visual
            impairment to enlarge and change colors on the screen to
            improve readability of text and images.
          + screen readers, which are used by people who are blind or
            with reading disabilities to read textual information through
            speech or braille displays.
          + alternative keyboards, which are used by people with movement
            impairments to simulate the keyboard.
          + alternative pointing devices, which are used by people with
            movement impairments to simulate mouse pointing and button
            activations.
      *dp* <lang> in the document's opening , we discuss dependant assistive technology, should not the nomenclature be more consistant? 
       
   3.3 Describe product features known to promote accessibility in a
          section of the product documentation. [Priority 2]
          Techniques for checkpoint 3.3
          *dp* <lang> a note here about action description though we may not want to be this specific.  I propose we add something here about writing the documentation so that it is clearly designed in an approach that is device independant such as not using click here or press enter here unless alternatives are also specified.
  Guideline 4. Allow the user to configure the user agent
  
   Next guideline: 5 | Previous guideline: 3 | Go to contents 
   
    Subhead here.
    
   Individuals with disabilities have a wide range of functional
   capabilities and so they must be able to configure the user agent to
   meet their particular requirements. Users must be able to configure
   rendering, mouse, keyboard, user interface control position, etc. to
   facilitate their daily use of the software.
   *dp*<slant> see above comments for a slant on this but perhaps the words web users instead of individuals with disabilities could be used.  One of the problems with <selling> accessibility is that it has the smack of catering to a particular clas or classes of individuals.
   Refer also to guideline 2. Refer also to checkpoint 9.10.
        
  Guideline 5. Allow the user to turn off features that may reduce
  accessibility
  
   Next guideline: 6 | Previous guideline: 4 | Go to contents 
   
    Subhead here.
    
   Some rendering behavior may make the user agent unusable or may
   obscure information. For instance, people with photosensitive epilepsy
   must be able to turn off flashing within certain ranges, otherwise the
   flashing may trigger a seizure. Users who require specific color
   contrasts or who have low vision need to be able to turn off
   background images if those images interfere with their ability to read
   text. Dynamically changing web content or opening windows can be a
   problem for people using some types of dependent user agents and may
   be disorienting to users with cognitive disabilities.
   *dp* <clarification> also, flashing causes my screenreader to repeat the flashed material every time it flashes.
   User agents are only expected to provide this control for content or
   user interface controls that it recognizes. Please also refer to
   guideline 6 and guideline 4.
   
   5.1 Allow the user to turn on and off rendering of images.
          [Priority 1]
          Techniques for checkpoint 5.1
          
   5.2 Allow the user to turn on and off rendering of background images.
          [Priority 1]
          Techniques for checkpoint 5.2
          
   5.3 Allow the user to turn on and off rendering of video. [Priority 1]
          Techniques for checkpoint 5.3
          *dp* <question> what is the justification for this?
   
5.4 Allow the user to turn on and off rendering of sound. [Priority 1]
          Techniques for checkpoint 5.4
          
   5.5 Allow the user to turn on and off rendering of captions.
          [Priority 1]
          Techniques for checkpoint 5.5
          
   5.6 Allow the user to turn on and off animated or blinking text.
          [Priority 1]
          Note. This is particularly important for users with screen
          readers.
*dp* <note> this makes my earlier point.

          Techniques for checkpoint 5.6
          
   5.7 Allow the user to turn on and off animations and blinking images.
          [Priority 1]
          Techniques for checkpoint 5.7
          
   5.8 Allow the user to turn on and off support for scripts and applets.
          [Priority 1]
          Note. This is particularly important for scripts that cause the
          screen to flicker, since people with photosensitive epilepsy
          can have seizures triggered by flickering or flashing in the 4
          to 59 flashes per second (Hertz) range.
          Techniques for checkpoint 5.8
          
   5.9 Allow the user to turn on and off support for user style sheets.
          [Priority 1]
          Techniques for checkpoint 5.9
          
   5.10 Allow the user to turn on and off support for author style
          sheets. [Priority 1]
          Techniques for checkpoint 5.10
          
   5.11 Allow the user to turn on and off support for spawned windows.
          [Priority 1]
          Techniques for checkpoint 5.11
          *dp* <question>  What happens if a window is not spawned and that action predicates something that must be done by the user such as filling a form?
   
5.12 Allow the user to turn on and off rendering of frames.
          [Priority 2]
          Techniques for checkpoint 5.12
*dp* <question> similar to above?          
   5.13 Allow the user to turn on and off author-specified page forwards
          that occur after a time delay and without user intervention.
          [Priority 3]
          For example, when turned off, offer a static link to the target
          resource instead.
          Techniques for checkpoint 5.13
          *dp* <question> is this not a wcad issue with regard to what is rendered or can the ua make this call?

 5.14 Allow the user to turn on and off automatic page refresh.
          [Priority 3]
          For example, when turned off, allow the user to refresh the
          page manually instead (through the user interface).
          Techniques for checkpoint 5.14
          
  Guideline 6. Ensure user control over document styles
  
   Next guideline: 7 | Previous guideline: 5 | Go to contents 
   
    Ensure that the user has control over the colors, fonts and other stylistic
    aspects of a document and can author styles and user agent default styles.
    
   In order to access a document, some users may require that it be
   rendered in a manner other than what the author intended. Users with
   visual impairments, including color blindness, may be insensitive to
   certain colors and may not be able to perceive author-specified or
   user agent default color combinations. Users with reduced visual
   acuity, including people who are older, may require larger fonts than
   user agent defaults or those specified by the author. Users who are
   blind may require audio or tactile rendering. Users who are deaf may
   require captions for audio files.
   
   User agents must therefore allow the user to control:
     * The document's style (e.g., fonts, colors, aural parameters, etc.)
     * The document's formatting: whether the document is presented
       textually, graphically, linearly, aurally, for tactile use, or
       some combination of these.
     * The document's content. This means whether primary content or
       alternative representations of content or both are rendered.
     * The user interface. Since authors may make changes to the user
       interface through scripting (e.g., by spawning new windows,
       causing dialog boxes to appear, etc.), users must be able to
       override changes that make the user agent or document
       inaccessible.
       
   Otherwise, users who are blind, have low vision, color deficiencies,
   some types of learning disabilities, or any user who cannot or has
   chosen not to view the primary representation of information will not
   know content of the information on the page.
   *dp* <lang> insert the word "the" above?

  Guideline 7. Ensure user access to document content
  
   Next guideline: 8 | Previous guideline: 6 | Go to contents 
   
    Ensure that users have access to primary as well as author-supplied
    alternative representations of content (descriptions of images, captions
    for video or audio, etc.)
    
   Otherwise, some users cannot perceive the primary content due to a
   disability or a technological limitation (e.g., browser configured not
   to display images).
   
   The primary or alternative content may be rendered to the user though
   character, graphic, audio, speech, or braille devices. The differing
   characteristics of these devices mean that user requirements and
   capabilities will vary.
   *dp* <proof> though above should be through.
   
For example, speech is a temporal medium. Speech output based browsers
	   must convey sub-structures of text content like paragraphs, sentences,
   words and the spelling of individual words to the user as certain
   words or phrases may not be properly converted from their original
   text to their correct speech pronunciation. By conveying
   sub-structures of text, user agents allow users to replay and even
   spell words and phrases until the user understands the content and
   context. Speech-based user agents must use auditory nuances -
   including pitch, articulation model, volume, and orientation - to
   convey meaning the way fonts, spacing, and borders do in graphical
   media. For example, a user agent might speak the word "header" before
   the text content of a header or "item 1.4" before a list item to
   convey context. Speech-based user agents must also heed
   author-specified markup that indicates changes in natural languages,
   and should render appropriately for supported languages.
*dp*<lang> the word link before a link is a good example of this.
        
  *dp* <comment general> I like 9.

  Guideline 10. Notify the user of document and view changes
  
   Next guideline: 11 | Previous guideline: 9 | Go to contents 
   
    It is important to alert users, in an output device-independent fashion,
    when important events occur during a browsing session.
    
   To avoid confusion that the effects of scripts may cause, users should
   be notified when scripts are executed (or be able to disable scripts
   entirely). This is also important for security reasons; users should
   be able to decide whether to allow scripts to execute on their
   machines.
   
   10.1 Provide information about document and view changes (to the user
          and through programming interfaces). [Priority 1]
          For example, inform the users when a script causes a popup menu
          to appear.
          Techniques for checkpoint 10.1
*dp* <proof> should not users be user? or drop the word the in the users and just leave users?
          
   10.2 Ensure that when the selection or focus changes, it is in the
          viewport after the change. [Priority 2]
          Techniques for checkpoint 10.2
          
   10.3 Allow the user to configure the user agent for notification of
          certain types of document changes only. [Priority 3]
          Techniques for checkpoint 10.3
          *dp* <Lang>  This is unsettling to me.  I feel it should be differently put because it doesn't convey exactly what is meant or what I percieve it to mean.  I'd like this to allow me to have the opportunity to pick one or several from a list of things I want to be notified about? It has something to do with the word only.   
   
10.4 When loading a document, make available what portion of the
          document has loaded, whether loading has stalled, and when the
          user may begin to browse. [Priority 3]
          Techniques for checkpoint 10.4
          
   10.5 Make available what portion of the document the user has viewed.
          [Priority 3]
          Note. Depending on how the user has been browsing, the
          percentage of document viewed may be calculated according to
          focus position, selection position, or viewport position.
          Techniques for checkpoint 10.5
          
   10.6 Allow the user to request to be prompted before a form is
          submitted. [Priority 3]
          Techniques for checkpoint 10.6
---end of commented portions of document---
Received on Tuesday, 10 August 1999 12:53:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:23 UTC