Modifications to the techniques document

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:

- 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.

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.


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.

Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.", Frost

Received on Wednesday, 8 September 1999 18:26:54 UTC