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

Re: Documenting assumptions + an issues list for the Requirements document.

From: <pjenkins@us.ibm.com>
Date: Thu, 15 Jun 2000 14:31:49 -0400
To: W3c-wai-gl@w3c.org
Message-ID: <852568FF.0065CB6E.00@d54mta03.raleigh.ibm.com>

Wendy said:
> Onto the issue you raise:
> Documenting the assumptions we make about assistive technology
> seems to fall under the category of requirement 2 "Ensure that the
> conformance requirements are clear."  It seems to me that making the
> minimal requirements clear means we have incorporated our knowledge of
> specific user agents/assistive technology into technology-specific tests
> that will be developed to help authors determine if they have met the
> minimal conformance requirements.

O.K. I agree with documenting our knowledge of specific users agents and
assistive technology.

> Are there undocumented assumptions in WCAG 1.0 or are they undocumented
> facts?  I think there are undocumented facts, such as "which browsers
> support which aspects of the various technologies?"  The answers to this
> question are not assumptions.  My sense is that since these are not
> documented and there are ambiguities in some of the statements, people
> made assumptions to fill in the gaps.  I think the goal with 2.0 is to be
> less ambiguous to prevent the assumptions.

O.K., but how do we deal with evolving technology in the user agents and
assistive technology (AT) - and - "minimal conformance requirements" ?  To
make the advancement of new technologies and formats viable - we should be
supporting guidelines & checkpoints that establish the "accessibility
standards" for the new technology/format - as opposed to requiring a
duplicate alternative format such as <NOSCRIPT> or <NOFRAMES> when someone
has either turned off Scripts or dislikes them, or doesn't have the browser
that supports them, or doesn't have the available AT..  We have the "until
user agents" clause [something I did not like] in the current 1.0
guidelines to encourage authors to make a temporary difference knowing that
things were getting better.  But my original idea of a "requirements
document" was not a list of requirements for the next version of WCAG
[which is a good idea however], but a list of minimum requirements for user
agents and assistive technology.  In other words I want to draw a crisper
line as to where the author's responsibilities ends and the assistive
technology's responsibility begins.  Let me explain with JavaScript as an
example, quoting some from a previous thread.  Newer level screen readers
working with newer level browsers provide good access to pages with
JavaScript.  Home Page Reader's development is working to provide access to
interactive content by supporting JavaScript; so should other/all browser
and assistive technology vendors.  In my opinion it would be counter
productive to "set a minimum requirement" that all pages that use
JavaScript should also provide a non-JavaScript alternative because not all
browsers support it yet.  That would be like requiring all GUI applications
to also provide a non-gui version because old DOS screen readers couldn't
handle them.  I am sure we may have all felt that way a decade ago when
GUIs were invented and screen readers where just being invented, but we
have made great strides in providing access to GUI applications.  So why
would we require all web sites to provide a non-JavaScript alternative by
documenting a minimum requirement that doesn't include a JavaScript capable
browser?  It would be less expensive and better to document a minimum
requirement that assistive technologies support JavaScript.  There are
still things to do to make JavaScript accessible, and those are the
guidelines and checkpoints we should be setting a standard for.  JavaScript
was invented to solve some real problems that could not be handled in HTML
alone, just as GUI's were invented to solve problems in old DOS command
line interfaces.  In some cases it may be impossible to provide the same
level of functionality using HTML without JavaScript - hence what we really
want is "accessible JavaScript".

Another example, Jason note:
> For example, we made an explicit decision (which I
> consider to be entirely justified) that if an access problem results from
> a shortcoming in user agent [PJ: or assistive technology]
> and can be remedied by means
> of a repair tool which has been or will soon become freely available,
> the guidelines should not recommend that the author take steps, in the
> design of the content, to circumvent the problem. This was applied to
> checkpoint 5.3, but similar reasoning was also employed in other cases.

The consensus on how this similar reasoning was applied is covered [in my
opinion] in the requirements for 2.0

So as we document the facts, I want to make sure we don't prevent the
advancement of new technologies and formats. The PF working group has the
charter to ensure new technologies and formats are capable of being
accessible, and our GL charter is to provide guidelines and checkpoints for
the technologies and formats.  Government bodies can then point to the
accessibility standards for regulations without restricting growth and
development.  When the GL working group makes assumptions that because a
format or technology is not freely available everywhere, but which is
accessible on some platforms + browsers + assistive technologies
combination, that it still requires a priority checkpoint is when growth
and development is restricted.

As Jason also wrote:
> The concept of undue hardship is relevant in the courtroom (or in a
> tribunal hearing), but not in the guidelines.

He was referring to the author, but I believe it also applies to the user
agent and assistive technology assumptions/requirements, whether they are
translated and available in various countries, and also applies to whether
new technology development should insure it is capable of being accessible.

Sorry for being long winded, but I was just trying to provide some opinion
and direction on how we resolve Wendy's observation:
> My sense is that since these are not documented and there are ambiguities
> in some of the statements, people have
> made assumptions to fill in the gaps.

and as Charles previously [1] wrote:
> There are several issues arising here:
> 1. What is the baseline capability that we are aiming at?
> This has been identified by the group already as something taht needs to
> specified in a revision of the guidelines.
> 2. Should the guidelines be written based on what is "reasonable effort"
> This has been discussed before, over the last couple of years. I would
> suggest that the status quo - that the checkpoints are described in terms
> user needs, rather than what is seen as relatively feasible, since that
> changes extremely rapidly, ...

And as I tried to explain above, we need to be careful how we document the
minimum capabilities of the assistive technology, because the "user needs"
make some assumption in those capabilities.

Phill Jenkins
Received on Thursday, 15 June 2000 14:35:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:32 UTC