Re: Problems with OTACS-2

gian@stanleymilford.com.au writes:
 > OTACS-2:
 > 
 > *  assumes the site will only be accessible using certain tools
 > 
 >    *  eg. site is accessible only once stylesheets have been rendered. 
 >       What happens if stylesheets are turned off?  Will there be a
 >       clause "...if tools are turned off the site must still be
 >       functional..."?
 >       
The principle doesn't make any such assumption; rather it requires
that the content itself (markup, text, audio/graphics, user interface
etc.) include sufficient machine-processable information to enable a
user with a disability to receive an adequate rendering, possibly with
the aid of assistive technologies and other client-side mechanisms.
 > 
 > *  
 >    is difficult to elucidate / explain.  Its premise has moved away from
 >    users and their access due to disabilities.  Appears to be appeasing
 >    developers/ content authors, when I believe WCAG's primary aim to
 >    help user groups, and our secondary aim is to make it as easy as
 >    possible for the authors.
 > 
It would be interesting to gauge reactions on this point, but I
suspect that content authors are unlikely to implement, as a foremost
priority, requirements
which they know have been made obsolete due to the availability of
client-side software to users.
 >    *  
 >    assumes that the defined *tools* render the content in an accessible
 >    format
 > 
 >    *  
 >       eg. that the tools work as intended in a variety of OS/browsers,
 >       in conjunction with ATs, other tools etc. Leads us down the garden
 >       path of leaving out or ignoring certain *unusual* or *difficult*
 >       technologies because they do not allow for these *tools*
 >       
I don't think there is any such assumption involved. One consequence
of the proposed principle, though, is that it becomes the user's
responsibility to obtain appropriate tools (or at least the
responsibility of the user's employer, educational institution,
support organisation, technical advisors etc.). In other words there
is an assumption that the user has tools which can read and process
the content format supplied by the author and produce an accessible
rendering. Conversely however, the author is required to provide the
content in formats that can be processed by the available tools,
otherwise the principle itself fails to be satisfied. Specifically, it
is the author's responsibility to provide the content in an
interoperable format.
 > 
 > *  
 >    assumes users will know how to manipulate / activate these *tools*. 
 >    Takes the onus off *the site* to be accessible, and onto *users* and
 >    *tools*
 > 
Almost every web site in existence makes that assumption, however. If
one is using an assistive technology of some kind to access the web,
then there is an assumption that one knows how to use it adequately.
 >    *  
 >       eg. the browser specification to notify the user whenever a new
 >       browser window is opened is a great idea - but rarely used,
 >       because users don't know it is there.  Therefore sites that are
 >       accessible, but "only in conjunction with certain tools" will end
 >       up mostly not being accessible, because users won't know:
Again, I think authors are less likely to take guidelines seriously if
 >       they are required, as a first priority, to accommodate
 >       inadequacies in user education and failure to take advantage
 >       of readily available technology. If the minimum set of
 >       checkpoints is to have a chance of becoming widely
 >       implemented then there needs to be a clear rationale as to
 >       why the author must satisfy the requirement and why it can't
 >       be met on the user's end by available software.
 > 
 > 
 > *  will be difficult to test
 > 
 >    *  
 >       WCAG 1.0 was hazy on how to test each checkpoint, but at least the
 >       theory behind it was obvious - users must be able to access the
 >       information.  Thus if all else failed, the developer could use
 >       common sense and test to ensure that, for example:
 > 
 >       1. 
 >          the site worked in conjunction with ATs
 >       2. 
 >          the site worked in text-only browsers
 >       3. 
 >          the site worked without plugins
 >       4. 
 >          etc etc

WCAG 2.0 provides success criteria which should obviate the need for
"common sense" application to a significant extent. One of the central
criticisms of WCAG 1.0 is that it failed to specify, with sufficient
accuracy, what was required for purposes of conformance.
 > 
 > *  sets up a category of tools that are no longer just "W3C approved"
 >    but "W3C compulsory"
There are no W3C-approved tools in any event. What it requires is not
particular tools but particular functionality on the part of the user
or the user's software. It would be better to think of the principle
in terms of functionality rather than "particular tools".
 > 
 >    WCAG 1.0 required the site work without plugins / device requirements
 >    etc.  Is OTACS-2 essentially a set of device requirements?
 > 
 >    *  
 >       eg. PDFs can be rendered "accessible" (according to Adobe).
 >       However the W3C does not approve of PDFs as the only means of
 >       content transmission because it relies on a plugin. Under OTACS-2,
 >       it appears PDFs would be accessible. Under WCAG 1.0 they are not.
The position toward which we are moving in WCAG 2.0, I think, is that
 >       the question of which formats to use is to be decided by the
 >       author. The only constraint is that there must be assistive
 >       technologies and user agents that can operate effectively
 >       with that format.
 > 
 > *  by being reliant on tools for accessibility, sets up WCAG 2.0 to very
 >    quickly become obsolete as new technologies become popular.
 > 
An interesting point here is that Wendy proposed to apply the
requirement at the abstract level rather than at the
technology-specific level so that only major advances in technology
(and not the emergence of this or that new tool or application) would
necessitate a change in the "minimum set". When we discuss
technology-specific success criteria I think there will be
"technology-specific" conformance issues that need to be addressed,
and we need a general framework in which to deal with them.
 >    *

Received on Saturday, 27 October 2001 02:12:54 UTC