W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2001

Re: Rough comparison of UAAG 1.0 and section 508 requirements for software applications

From: Jon Gunderson <jongund@uiuc.edu>
Date: Mon, 02 Apr 2001 09:35:07 -0500
Message-Id: <4.3.1.2.20010402093230.024b3f08@staff.uiuc.edu>
To: Ian Jacobs <ij@w3.org>
Cc: w3c-wai-ua@w3.org
Thanks for the comparison Ian.  Doesn't our use of "text equivalent" in 
checkpoint 1.3 basically require that the text must be useful as in part of 
satisfying (e) of 508?

Jon


At 06:29 PM 3/30/2001 -0500, you wrote:
>Hello,
>
>Below I (roughly and rapidly) compare the user agent requirements of
>section 508 [1] with those of UAAG 1.0 (the 23 March draft [2]).  I
>think that our requirements are very similar in most cases, though
>expressed differently. Two differences stand out:
>
>1) We don't have a requirement to turn off blinking/flashing in the
>UI. I note that we have explicitly chosen *not* to include this
>requirement for the user interface. We discussed whether our content
>requirements should be extended to the user interface in general, and
>decided against this. [I don't have the URI handy for the decision
>but could track it down.]
>
>2) We don't have a requirement for consistency among images used
>    in the UI (though I think that checkpoint 7.3 probably covers
>    that).
>
>Please note the following:
>
>  a) This is not a definitive analysis.
>  b) I'm not proposing any changes to UAAG 1.0.
>  c) I don't think we should include this type of comparison in
>     UAAG 1.0 because this is just one country's regulation.
>
>  - Ian
>
>[1] http://www.access-board.gov/sec508/508standards.htm
>     Refer to " 1194.21 Software applications and operating systems"
>[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0555
>
>--
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>
>===================
>
><508>
>(a) When software is designed to run on a system that has a keyboard,
>product functions shall be executable from a keyboard where the
>function itself or the result of performing a function can be
>discerned textually.
></508>
>
><UAAG>
>1.1 Ensure that the user can operate the user agent fully through
>keyboard input alone. [Priority 1] Both content and user
>agent.
>
>Comment: We *always* require keyboard support.
></UAAG>
>
>===================
>
><508>
>(b) Applications shall not disrupt or disable activated features of
>other products that are identified as accessibility features, where
>those features are developed and documented according to industry
>standards. Applications also shall not disrupt or disable activated
>features of any operating system that are identified as accessibility
>features where the application programming interface for those
>accessibility features has been documented by the manufacturer of the
>operating system and is available to the product developer.
></508>
>
><UAAG>
>7.1 Follow operating environment conventions that benefit
>accessibility when implementing the selection, content focus, and user
>interface focus. [Priority 1]
>
>7.2 Ensure that default input configurations do not interfere with
>operating environment accessibility conventions. [Priority 1]
>
>7.3 Follow operating environment conventions that benefit
>accessibility. In particular, follow conventions that benefit
>accessibility for user interface design, keyboard configuration,
>product installation, and documentation.
>
>7.4 Follow operating environment conventions to indicate the input
>configuration. [Priority 2]
></UAAG>
>
>===================
>
><508>
>(c) A well-defined on-screen indication of the current focus shall be
>provided that moves among interactive interface elements as the input
>focus changes. The focus shall be programmatically exposed so that
>assistive technology can track focus and focus changes.
><508>
>
><UAAG>
>10.6 Provide a mechanism for highlighting the selection and content
>focus. Allow the user to configure the highlight styles. The highlight
>mechanism must not rely on color alone. For graphical viewports, if
>the highlight mechanism involves colors or text decorations, allow the
>user to choose from among the full range of colors or text decorations
>supported by the operating environment. [Priority 1]
>
>6.5 Using standard APIs, provide programmatic alert of changes to
>content, user interface controls, selection, content focus, and user
>interface focus. [Priority 1]
></UAAG>
>
>===================
>
><508>
>(d) Sufficient information about a user interface element including
>the identity, operation and state of the element shall be available to
>assistive technology. When an image represents a program element, the
>information conveyed by the image must also be available in text.
></508>
>
><UAAG>
>6.4 Provide programmatic read and write access to user agent user
>interface controls. [Priority 1]
>
>1.2 Ensure that every message (e.g., prompt, alert, notification,
>etc.) that is a non-text element and is part of the user agent user
>interface has a text equivalent. [Priority 1]
></UAAG>
>
>===================
>
><508>
>(e) When bitmap images are used to identify controls, status
>indicators, or other programmatic elements, the meaning assigned to
>those images shall be consistent throughout an application's
>performance.
></508>
>
><UAAG>
>
>Comment: No corresponding requirement. However, consistency in the UI
>is probably covered by checkpoint 7.3:
>
>7.3 Follow operating environment conventions that benefit
>accessibility. In particular, follow conventions that benefit
>accessibility for user interface design, keyboard configuration,
>product installation, and documentation. [Priority 2]
></UAAG>
>===================
>
><508>
>(f) Textual information shall be provided through operating system
>functions for displaying text. The minimum information that shall be
>made available is text content, text input caret location, and text
>attributes.
></508>
>
><UAAG>
>6.6 Implement standard accessibility APIs (e.g., of the operating
>environment). Where these APIs do not enable the user agent to satisfy
>the requirements of this document, use the standard input and output
>APIs of the operating environment. [Priority 1]
>
>6.8 For an API implemented to satisfy requirements of this document,
>support the character encodings required for that API. [Priority 1]
>
>Comment: UAAG doesn't have any requirements related to a text input
>caret. Access to all (text) content is covered by checkpoints in
>Guideline 2.
></UAAG>
>
>
>===================
>
><508>
>(g) Applications shall not override user selected contrast and color
>selections and other individual display attributes.
></508>
>
><UAAG>
>Comment: The checkpoints of Guideline 4 require configuration and
>control
>of color, text size, playback rates, some audio characteristics,
>and some speech characteristics. UAAG does not include a general
>requirement that user preferences override all author preferences
>or user agent defaults.
></UAAG>
>
>===================
>
><508>
>(h) When animation is displayed, the information shall be displayable
>in at least one non-animated presentation mode at the option of the
>user.
></508>
>
><UAAG>
>Comment: This is an interesting one because it sounds like an authoring
>requirement to me. Our checkpoints for control of animation
>(including video, animated images, and animated text) are:
>3.2, 3.3, 4.4, 4.5, 4.7, and 4.8.
></UAAG>
>
>===================
>
><508>
>(i) Color coding shall not be used as the only means of conveying
>information, indicating an action, prompting a response, or
>distinguishing a visual element.
></508>
>
><UAAG>
>10.2 Ensure that all of the default highlight styles for the
>selection, content focus, enabled elements, recently visited links,
>and fee links (1) do not rely on color alone, and (2) differ from each
>other, and not by color alone. [Priority 1]
>
>10.6 Provide a mechanism for highlighting the selection and content
>focus. Allow the user to configure the highlight styles. The highlight
>mechanism must not rely on color alone. For graphical viewports, if
>the highlight mechanism involves colors or text decorations, allow the
>user to choose from among the full range of colors or text decorations
>supported by the operating environment. [Priority 1]
>
>10.7 Provide a mechanism for highlighting the viewport with the
>current focus. For graphical viewports, the default highlight
>mechanism must not rely on color alone. [Priority 1]
>
>Comment: I also expect checkpoint 7.3 will cover other user
>interface elements:
>
>7.3 Follow operating environment conventions that benefit
>accessibility. In particular, follow conventions that benefit
>accessibility for user interface design, keyboard configuration,
>product installation, and documentation.
></UAAG>
>
>===================
>
><508>
>(j) When a product permits a user to adjust color and contrast
>settings, a variety of color selections capable of producing a range
>of contrast levels shall be provided.
></508>
>
><UAAG>
>Comment: All of our color requirements refer to "the full range
>of colors supported by the operating environment."
></UAAG>
>
>===================
>
><508>
>(k) Software shall not use flashing or blinking text, objects, or
>other elements having a flash or blink frequency greater than 2 Hz and
>lower than 55 Hz.
></508>
>
><UAAG>
>3.3 Allow configuration to render animated or blinking text as
>motionless, unblinking text. [Priority 1]
>
>Comment: We have explicitly chosen *not* to include this
>requirement for the user interface. We discussed whether our
>content requirements should be extended to the user interface
>in general, and decided against this.
></UAAG>
>
>===================
>
><508>
>(l) When electronic forms are used, the form shall allow people using
>assistive technology to access the information, field elements, and
>functionality required for completion and submission of the form,
>including all directions and cues.
></508>
>
><UAAG>
>2.1 For all format specifications that the user agent implements, make
>content available through the rendering processes described by those
>specifications. [Priority 1]
>
>Comment: Checkpoint 2.3 is also relevant.
>
>5.4 Allow configuration to prompt the user to confirm (or cancel) any
>form submission that is not caused by an explicit user request to
>activate a form submit control.
></UAAG>
>
>--
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua
Received on Monday, 2 April 2001 10:32:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:49 GMT