Re: Modifications to the techniques document

see comments below at MN: (sorry to be this far behind)


At 5:26 PM 9/8/99, schwer@us.ibm.com wrote:
>Jon and Ian,
>
>I have not reviewed the entire techniques document but are attached are
>sections
>I have comments and/or new content to help fill out the techniques document. I
>will be on vacation next week so I can't answer specific questions until I get
>back but perhaps you can discuss these change and/or include them in the
>techniques document over the next week.
>
>A significant omission in the User Agent guidelines, which for now I am
>addressing in the techniques document, has to do with applets. The guidelines
>indicate that user agents should follow system conventions for accessibility.
>This extends to Java applets. What is omitted is that user agents that support
>applets or any plug-in type mechanism should also provide for native system
>conventions to load assistive technologies.
>
>Today, although you can make a Java applet accessible, you would need to load a
>plug-in from Sun (if it exists) to load and assistive technology in the Java
>Virtual Machine. Assistive technologies that exists in Java today would be the
>Java access bridge or the IBM Self Voicing Kit for Java. It does not do anyone
>any good to write follow system conventions if there is no mechanism to
>make use
>of them to provide accessibility. If you look at the attached modifications you
>will see this discussed with a reference to appendix 9 for loading an assistive
>technology in Java that should apply to Java applets since this is part of the
>delivered content.
>
>3.1.2
>
>This section is confusing. Since this section is targeted at assistive
>technologies (dependent user agents) and user agents, this should be written to
>address both groups. If either were group were to look at this it would
>not give
>them techniques for them to specifically implement.
>
>The first paragraph in this section should say "includes text and alternative
>equivalents".
>
>3.1.2 Contextual Information
>
>This should specify row and column information for table cell
>co-ordinates. This
>confuses row/column with screen pixel co-ordinates.
>
>3.1.3
>
>include this technique:
>
>A user agent should treat content language as part of contextual information.
>When the language content changes it should either be rendered in the supported
>language or notify the user that the language change. Rendering could involve
>speaking in the designated language in the case of an audio browser or screen
>reader. If the language was not supported, the language change notification
>could be spoken in the default language by a screen reader or audio browser.
>
>For browser user agents the lang attribute information should be available
>through the DOM.
>
>3.3
>
>Charle's note regarding the Java Accessibility API could be removed as
>Java does
>not have an API provision for this.
>
>
>4.1.3 Support System Conventions for loading Assistive Technologies
>
>If an operating system of application environment, such as Java, supports
>loading assistive technologies, your user agent should support it. In  the case
>of Java applets, your browser's Java Virtual Machine should support the Sun
>convention for loading an assistive technology. Writing an application to
>following the Java system conventions for accessible software does not
>allow the
>applet to be accessible if an assistive technology designed for that
>environment
>cannot be run to make the applet accessible. Appendix 9 indicates the technique
>used by an assistive technology vendor to load its software in a Java Virtual
>Machine.
>
>4.4 The Document Object Model
>
>...What the DOM can do:
>
>The Document Object Model (DOM) is a standardized tree structure representation
>of a Document that has, in part, been used as the document structure to attach
>client-side scripting languages, like JavaScript, to interact with the
>document.
>The number of new web protocols are becoming XML-based and numerous which makes
>it impossible for assistive technologies to be able to parse and support them.
>The DOM is needed to provided a standardized mechanism to enable an assistive
>technology to connect to and provide access to your browser's displayed
>document
>for a disabled user. It is therefore important that a user agent provide
>dynamic
>access to its DOM for assistive technologies. The DOM should:

MN:  I would propose UA "borrow" a more formal description for DOM
from the DOM working group documentation, or the DOM proposal itself,
and as UA, then concentrate on what DOM provides that is important for
accessibility beyond what DOM already provides any UA.


>
>- Support the W3C standards for the DOM
>- Provide methods:
>   - To acquire Document element associated script information
>   -  Navigate DOM tree elements
>   - To enable Notification of Document Changes including Notification of
>when a
>   new document is loaded into the DOM
>   - To Activate Document Elements
>   - To Provide access to alternative content
>   - To Provide contextual information provided by the DTD or script attributes
>   - To Modify the fonts for the purposes improving low vision access
>   - To highlight document elements to improve readability
>
>It is important to note that DOM is designed to be used on a server as
>well as a
>client and therefore many user interface specific information such as screen
>co-ordinate information is not relevant and not supported by the DOM
>specification.

MN:  agreed, also I don't think things like fonts and highlight are part
of the DOM.



>This should be added at the end of section 4.4:
>
>DOM level 2 adds key features that will help assistive technologies. In
>particular it a standardized event model to enable an assistive technology to
>passively monitor a document that may be changing dynamically as a result of
>JavaScript or some other mechanism. The WAI Protocols and Formats group is
>working closely with the DOM working group to add accessibility features to the
>DOM. It is important that as new DOM standards come out from the W3C come out
>that user agents update their DOM implementation to the latest standard as this
>will enable adoption of critical accessibility standards.


MN:  Based on what comes out of the DOM working group this week, I think we
could remove the part from the "The WAI Protocols and Format..... critical
accessibility standards".  Also, i'm not sure what is meant by "passive"?




>5.1.2 Alternative representations of information for images, video, applets
>
>
>Audio  based user agents providing accessible solutions for images should by
>default not provide no information about the image if no alternative text is
>provided. The reason for this is that the image will clutter the users
>view with
>unusable information adding to the confusion. In the case of an audio
>presentation nothing would be spoken for the image element. This option should
>be turned off by the assistive technology to allow the user, if desired,
>to find
>out what images were inaccessible so that the page author could be contacted to
>correct the problem.
>
>In the case of videos, an assistive technology should notify the user know that
>a video exists by default as this will likely result in the launch of a
>plug-in.
>In the case of a video it would be helpful to indicate what type of video it is
>accompanied by the associated alternative representation if it exists. If a
>plug-in exists that supports the system specific accessibility features it
>should be used in place of one that is not.
>
>In the case of applets, an assistive technology should notify the user
>know that
>an applet exists by default as this will likely result in the launch of an
>associated plug-in or browser specific Java Virtual Machine. In the case of an
>Applet the notification should include the associated alternative
>representation
>if it exists. This especially important for applet as applets typically do
>provide an application frame that would provide application title information.
>
>When an applet is loaded it should support the Java system conventions for
>loading an assistive technology. When the applet receives focus, the browser
>user agent should first notify the user about the applet as described in the
>previous paragraph and turn control over to the assistive technology that
>provides access to the Java applet.
>
>
>
>4.5 Information for Assistive Technologies
>
>The WAI Protocols and Formats group is focusing its efforts on the DOM as the
>conduit from which to extract accessibility information from and to enhance the
>accessibility of a rendered document through a user agent. It is this are
>should
>concentrate on for providing access to user agent documents.
>
>8.0 Appendix
>
>Change the Mouse Keys definition to: These allow users to move the mouse cursor
>and activate the mouse button(s) from the keyboard. The most common
>modifiers to
>activate/deactivate these keys is to type left VK_SHIFT, left VK_ALT, and
>VK_NUM_LOCK simultaneously.
>
>Add a section on Keyboard Response Group similar to Mouse Keys:
>
>Keyboard Response Group (KRG)
>
>The KRG contains three functions; RepeatKeys, SlowKeys, and BounceKeys. The KRG
>can be turned on from the keyboard with the pre-stored user default settings.
>There should also be an emergency activation scheme to turn the KRG on in some
>minimal configuration for those times or for those users who cannot operate the
>computer keyboard without a particular KRG function (e.g., SlowKeys).
>
>Note: SlowKeys and BounceKeys are mutually exclusive. In other words, if the
>acceptance delay for SlowKeys is some value other than "0", then the delay
>value
>for BounceKeys must be "0". SlowKeys and BounceKeys can both be "0", or in
>effect off, while RepeatKeys is on, or either SlowKeys or BounceKeys can be on
>with RepeatKeys.
>
>Therefore the following KRG combinations can be set by the user:
>
>RepeatKeys alone
>SlowKeys alone
>BounceKeys alone
>SlowKeys and RepeatKeys
>BounceKeys and RepeatKeys
>
>The common modifier for activation of the KRG is to press and hold the right
>VK_SHIFT key for 8 seconds (note, emergency activation when the right VK_SHIFT
>key is held for 12 or 16 seconds.


MN:   Appendix 8 for the Tech doc., was written in two parts, the first
part being more
generic (descriptions of the built-in features), and the second part being
platform
or operating system specific (e.g., Microsoft Windows, Apple Macintosh, etc.)

I would not propose the changes Rich suggested above, to the generic
section, since
Rich's changes are "platform specific".  For example,  VK_SHIFT, left
VK_ALT, and
VK_NUM_LOCK,  is not the three key sequence used on the Apple Macintosh for
MouseKeys, and thus would just confuse people as part of a generic
description.

If we'd like to be more technical in the second part, under each operating
system, then
that might be a way to handle this specific information.  However, I do not
feel this
level of information (e.g., virtual keys, etc.) is necessary in the techniques
document, and would rather see a URL or link to the appropriate platform or
operating system pages, which I suspect is where a developer would be more
inclined to
look in the first place.

mark

Received on Monday, 20 September 1999 11:42:48 UTC