Last Call review of User Agent Accessibility Guidelines 1.0

W3C Working Draft-November-1999

 

Prepared by:

Richard Premack, interNext

richardp@inter-next.net

1-888-576-8932 (USA) 1-727-578-1059 (Int'l)

 

 

The following is our response to an invitation by Jon Gunderson, Chair -- W3C WAI User Agent Working Group to review and provide comment on the " User Agent Accessibility Guidelines 1.0 - W3C Working Draft-November-1999".

 

As a developer of telephone-based web browsing and autonomous agent technologies, we have particular interest in this area and the above referenced document as it relates to accessible design requirements from both the end-user (user interface) and software system (system interface) development perspective.

 

Beyond the technical dimensions of web accessibility, we have discovered through our own independent research, that there are legal ramifications to providing accessible technologies as well, which heretofore, we have not seen or heard discussed within the WAI communication channels we have been party to. Therefore, we believe we may have something new to offer in this regard and hope that the Working Group will find this information (which was obtained at considerable expense to our organization) useful.

 

We are honored and pleased to provide feedback on such an important and we believe, historic document that will serve as a blueprint for User-Agent accessibility as we move forward into the next millenium. Thank you for the opportunity to be of assistance in this important endeavor.

 

Sincerely,

 

Richard A. Premack

interNext - creators of Tel-Web

 

 

1.0 Review Methodology

 

No prior research into the prerequisite activity, public discussions or prior document versions was attempted. This was intentional to provide a "fresh" perspective on the final draft document as it exists today without the prejudicial influences of the document's history entering into the review process.

 

1.1 Conventions

 

The review will roughly follow the document's Table of Contents with regard to heading descriptions and section numbering. Section headings will be bracketed "[]" and review comments will be found beneath these headings.

 

For example:

 

[Abstract]

… comments about the abstract …

 

1.2 Criteria

 

The following criteria were used in reviewing the document (in no particular order):

 

  1. Appropriateness of Priorities
  2. Clarity
  3. Completeness
  4. Feasibility
  5. Legal Considerations

 

2.0 General Comments

 

2.1 Legal Considerations

 

As mentioned previously, beyond the technical aspects of providing accessible technologies described herein, our organization has discovered that there are serious legal ramifications and responsibilities with respect to rendering web content written by web authors on behalf web users.

 

It would seem prudent that any standards organization engaged in developing and promoting guidelines for development of these technologies, must take into account the potential legal outcomes associated with the implementation of these same guidelines by user-agent developers.

 

Unfortunately we now live in a very litigious society, and we have already seen a precedent set by the AOL lawsuit with respect to accessibility litigation on the content-author (server) side of the equation.

 

On the client-side, we have the user-agent tasked with rendering web content in the manner in which the web author intended while at the same time providing accessibility to those that need it. As user-agent developers we are caught in the middle between the user's needs and the web content author's intellectual property rights. Could a user-agent developer be sued as a result of making their product "Triple-A" or even "A" compliant?

 

Although I am not an attorney (and am not attempting to practice as one), after reviewing the Guidelines, I would say that this is a possibility. This is based upon the advice we have received from our legal counsel and given the current (outdated) Copyright Act which has not been updated and amended to take into account the Internet and the evolving "e-society", much less web accessibility.

 

I am not trying to alarm anybody and I hope I am wrong. However, please consider the following:

 

The use of copyrighted material is controlled entirely by the copyright holder, except in certain specific cases where the copyright has expired or the use of the material is considered "fair use" which must meet

certain strict guidelines, among them: non-commercial use. The web-content author is the copyright holder.

 

Strictly speaking, if you convert copyrighted material from one format to another or omit or add anything it may be considered infringement if the copyright holder expressly forbids it. You will see this prohibition on many web sites (usually under the "copyright notice" link).

 

Per section 106(4) of the U.S. Copyright Act, the copyright holder has the exclusive right "to perform the copyrighted work publicly". Also that "Ownership, possession or any other attachment to or relationship with a copy of a copyrighted work (including obtaining access to it through a computer network or other service) does not entitle one to exercise any of the exclusive rights of the copyright owner (e.g., to reproduce it or to perform it publicly)."

 

This includes altering the work in any way. Most websites have a statement to this effect under a "copyright" or "terms of use" link that reads something like this: "No material from XYZ Company or any Web site owned, operated, licensed or controlled by XYZ Company may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way .... Modification of the

materials .... is a violation of XYZ Company's copyright and other proprietary rights."

 

This also relates to the placement of the links within the context of the document instead of presenting all of them before or after speaking the page text. Actually, it would be easier to do this (place them first or

last) then how we do it now (in context) which is not a trivial programming task. I have noted that some other developers have not gone to the lengths we have to conform to copyright law and do in fact present links out of context.

 

Perhaps, we're being too paranoid here - attorneys can help make you that way, but we felt better safe than sorry.

 

An interesting court case was MAI Systems vs. Peak where the decision in that case held that if information is loaded into RAM, it is then "fixed in a tangible medium" (ref. 17 U.S.C. 102), and therefore an unlawful copy has been made. On the other side, some courts have held that browser functions are too remote or ephemeral to constitute a copy.

 

Personally, I find the Peak decision hard to understand. If moving data into RAM is unlawful, we'd better stop using modems, telephones, etc. because just about every communications device these days has a CPU that loads either digital data or digitized analog data into RAM, even if only very briefly.

 

Regardless, this case, unless challenged (and overturned?), opens the door to litigation in which the plaintiff claims that user-agents that alter content or render it in an unexpected or different way from that which was intended by the author is in effect altering and/or re-publishing their work without their

permission.

 

Some content providers even prohibit their content from being exhibited in frames, let alone converted to speech and possibly altered further by a user-agent.

 

For example: What if we inhibit blinking or animated text as suggested in Checkpoint 3.5 and this text comprises a copyright notice, or more commonly, an advertising "banner" that an advertiser paid a web author many dollars to display?

 

 

On the plus side, some "expert advisors" to our counsel have answered our questions in the following way:

 

  1. Are there licensing or copyright problems with using Text-To-Speech to provide Internet access via the telephone since some of the content is modified to make the speech synthesis more effective and content may be further modified so that the user may skip portions of web pages and get directly to sections of interest?
  2.  

    '… Minor modifications to the [web] text to make it more understandable is a closer

    call, but I would argue that there are de minimus and therefore not an infringement.'

     

    'I think a strong fair use argument would also apply. The fact that it is a commercial use and that the entire content is copied would lean against the fair use, but the fact that it does not diminish the value of the work and does not take market share away, would tilt the scales in favor of the client. Although not a slam dunk, the public policy argument of giving access to this new form of communications to the sight impaired and others would weigh heavily in favor of a fair use finding.'

     

    'Who would want to incur the adverse publicity of suing the client and being branded someone trying to prevent access to important information to the blind?'

     

  3. Some content providers display notices that prohibit anyone to "publish, retransmit, redistribute, or otherwise reproduce any XYZ company information in any format to anyone." Are these claims valid/enforceable? Does this apply in our case? There are already "audio browsers" on the market today. Wouldn't they be affected also?
  4.  

    'Those notices are probably not enforceable without some affirmative assent on the part of the user …. … Web browsers, ISPs, etc. cache content to provide quicker access. Browsers reproduce the content, etc. What those notices are primarily aimed at is someone who would steal the html code, of Java applet and use it on their own site, or print out the content and publish it in paper form, or some other competitive endeavor. Your client is not competing with the content providers. Instead, it is allowing these providers to get to an audience they have previously been unable to get to.'

     

     

  5. Is a blind person who uses a "talking PC or browser" to listen to a book published in text format only, or is the maker of such a device, liable for copyright infringement? Some of these devices include spell checkers and other software that may change or otherwise enhance the conversion from text to speech. Is this considered copyright infringement?

 

'Again, there is no copy made -- on the ephemeral sounds coming out of the speaker. But even if there is, as indicated, there is an implied license to use the materials for their intended use. Whether the user uses its eyes or ears to "read" the text is the intended use.'

 

'Since there are large amounts of public domain materials online, and many copyright owners who would be pleased to have their content made available to the sight-impaired, with or without explicit permission, it can be argued that the client's technology has a substantial non-infringing use, like the VCR machines in the Universal Studios v. Sony (Betamax) case a decade ago, and therefore, it is not infringing. Of course, this argument depends on whether the user or your client chooses the content to be "read" by the

browsers. If it is the client, then it is a more difficult argument to make.'

 

Based upon the foregoing discussion, I would highly recommend that the draft document also be reviewed by W3C legal counsel or an attorney well-versed in web content copyright law to determine if there might in fact be a conflict between providing accessible functionality in user-agents and the rights of web content authors.

 

 

 

 

3.0 Specific Comments

 

[Abstract]

 

Our product/service is a fully integrated web browser / assistive technology wherein the user interface is always DTMF (touch-tones). We do not provide a separate or "detachable" browser user-agent so many of the checkpoints related to alternate device APIs do not apply to our product.

 

The abstract, in an effort to define/distinguish between "user-agents" and "assistive technologies" cites several examples in each category. However, the glossary definition seems to imply that both components are (necessarily?) part of the user-agent. This may be a nit to some, but the two sections do seem a little inconsistent with each other.

 

[1.1 Principles of Accessible Design]

[Ensure that the user interface is accessible]

 

Typo in first sentence "ouptut".

 

We applaud the statement regarding user interfaces: "… user interfaces must be intuitive, simple, and tested." We have noted that some user-agent developers have sacrificed simplicity and intuitiveness from a user's perspective for some obscure functionalities and almost a pathological adherence to the browser paradigm at the expense of ease of use.

 

[Help orient the user.]

 

"The 'back' functionality is a valuable 'undo' tool for returning to a known state" -- yes, we agree and have implemented this feature.

 

[Checkpoint 1.3]

 

Be careful that when converting/rendering one content object as another the object's original characteristics are maintained.

 

[Checkpoint 2.8]

 

What about so-called "proximal text" that may be used to describe a link when no ALT text is available? This is text that occurs immediately after or before the HREF tag. In this case of either unspecified ALT text or specified null ALT text we would use proximal text to describe the link if available.

 

[Checkpoint 2.9]

 

The changing from a supported natural language to an unsupported language could be very disorienting to a user and therefore the user "should" (Priority 1) be notified.

 

[Checkpoints 3.5 & 3.6]

 

As mentioned previously, inhibiting blinking or animated text (or images) as suggested in this checkpoint could have the effect of inhibiting a copyright notice, or more commonly, a paid advertising "banner".

 

[Checkpoint 3.8]

 

The ability to turn on and off [foreground] images "should" (Priority 1) be provided and is at least as important as checkpoint 3.1.

 

[Checkpoint 4.1]

 

While Checkpoints 4.2 - 4.4 address important controls for site impaired (low-vision) users, it is unclear to me that font family plays a Priority 1 role in ensuring readability. I would recommend Priority 2, although I understand the tendency to want to group font type and size together.

 

[Checkpoint 4.13]

 

Normal audio playback controls are important and should have the same priority (Priority 1) as playback controls on Text-To-Speech (checkpoints 4.14 & 4.15). Certainly these controls would be considered more important than say, changing the gender of Text-To-Speech output.

 

[Checkpoint 5.1]

 

This checkpoint is much too vague to be useful to a developer without further elaboration. What are "accessible APIs" as opposed to standard APIs? Which "other technologies" are being referenced? This checkpoint deserves a more complete explanation in view of the fact that it is fundamental to other checkpoints involving APIs and carries a Priority 1 rank.

 

[Checkpoints 5.4 & 5.5]

 

The more I read checkpoints 5.4 and 5.5 the less difference I can discern between them. If Checkpoint 5.5 was embellished slightly to clarify that Checkpoint 5.5 is a superset of Checkpoint 5.4, this would improve the clarity of both checkpoints.

 

[Checkpoints 6.1 & 6.1]

Again, the distinction between these two checkpoints, besides their priority, is barely discernable from the description. Both call for implementation of applicable accessibility features except that one enumerates the specifications.

 

[Guideline 7. Provide navigation mechanisms]

 

"So that users of serial devices are not required to view an entire page or presentation to find information, user agents should provide more direct navigation mechanisms"

 

The statement above has definite legal implications that should be apparent from the previous discussion of copyright law. It is important to remember that when viewing a page visually, almost all of the information is presented to the user instantaneously through their eyes. In this case, the use of direct navigation mechanisms does not prevent the user from processing the other information contained within the page since that information has already been viewed. In contrast, direct navigation features on a page presented serially, such as through Text-To-Speech conversion may cause entire sections of content to be missed and "context may be lost".

 

[Checkpoint 7.5]

 

Navigating just among active elements seems at least as important as navigating through the elements of a table (Checkpoint 7.3).

 

[Checkpoint 8.8]

 

This checkpoint appears to be a fundamental mechanism and deserving of at least a Priority 3 ranking.

 

 

[Checkpoint 8.9]

 

Software re-usability and backwards compatibility are important features to provide and "should" be

provided.

 

[Missing Checkpoint 10.X ?]

 

It seems there should be a checkpoint in this section describing a feature similar to the "Favorites" folder implemented in some browsers whereby previously visited links may be stored, named, categorized and retrieved with a single keystroke or a single voice command.

 

-end-