Re: Problems with OTACS-2

Gian,

         I hope you are feeling better. You sounded rough on the phone 
yesterday. Since I like the OTACS-2 plan, I'll offer comments to your 
concerns, but Wendy may want to correct my comments.

At 12:43 PM 10/26/01 +1000, gian@stanleymilford.com.au wrote:
>Hi,
>
>After thinking long and hard I have come up with the following list of
>problems I see with OTACS-2.  If anyone can explain them away to my
>satisfaction then I am happy to withdraw my objections.  Please let me
>know if I have not been clear enough in the following explanations.
>
>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..."?

I think the intent is to organize the priorities by who is responsible for 
what. If someone has stylesheets, why would they turn them off ?  Seems 
like this would be similar to not using a browser and expecting the 
Internet to come in without. Myself, I don't use (or set) stylesheets 
because I prefer to see what the author has provided.  If your example had 
been to not use plug-ins, I can almost understand, but since most plug-ins 
are free for the downloading, I am just as mystified why such tools aren't 
considered part and parcel to the browser (and I understand that some 
browsers, such as NN provide plug-ins with the browser). Perhaps I'm not 
seeing the big picture, but if I want to see a page, and it requires a free 
plug-in, I would not complain about the site if I chose not to download the 
free stuff.

         The other side of the coin is that in the case of Dyslexia, it is 
presumed that the user should have a speech reader which is NOT free, and 
not provided by good site authors who generally tend to put a link to 
download the plug-in when their pages need it. If those who are, by their 
disability unable to easily get and use a speech reader, required to do so 
before their needs are considered important, how much greater is the 
responsibility of non-cognitively disabled users to download tools they 
need for pages.


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

The guidelines aren't changing, just the priorities. My first hope was the 
priorities would be based on user groups and the largest groups would be 
insured accommodation by the minimum priorities. Wendy's plan to separate 
the priorities between those that only the author can do, and those which 
can be accomplished by tools seems to me to accomplish what I'd hoped for 
even tho it comes from a different angle.

>    *
>       eg. what is the theory behind this (as explained to a business
>       manager)?  WCAG 1.0 at least had a the beginnings of "do this
>       because otherwise group x will not be able to access a, b and c on
>       your web site".  OTACS-2 is moving one step away from this, it is
>       essentially saying "do this because otherwise the tool y group x
>       is using will not render a, b and c correctly".  And what about
>       "do this because otherwise if group x doesn't use tool y, a, b and
>       c will be unavailable"

The example for this is in Guidelines 3.3 - Write clearly and simply. But 
it has been said that it isn't testable or normative, and those who can't 
read can use a speech reader. Most folks with cognitive and learning 
disabilities are NOT using speech readers. Speech readers are not as 
readily available as updates to IE, free plug-ins, and other tools, but 
users who can't read are expected to use them. This doesn't seem right in 
light of the life-styles of such folks .... who are usually underemployed 
or work at minimum wage.

*
>    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 would think that tools which do not work with ATs would be addressed in 
the minimum set rather than the later set.  The minimum needs to insure 
that ATs are accommodated. Perhaps we need to identify the tools that do 
not work with specific ATs and set about updating the tools so they can be 
so used.


>*
>    assumes users will know how to manipulate / activate these *tools*.
>    Takes the onus off *the site* to be accessible, and onto *users* and
>    *tools*
>
>    *
>       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:
>1.
>          What tools to manipulate / activate
>       2.
>          How to manipulate / activate certain tools to get desired
>          results.
>

In advocating for the needs of the cognitively (etc) disabled, I've been 
told over and over that users have responsibilities. And perhaps we have 
some responsibilities as well, to provide places for users to learn how to 
use the tools they have at their fingertips. Can you imagine the difficulty 
of enforcing driving laws, such as using "turn signals" if drivers weren't 
required to learn where the turn signal switch is in the car they are 
driving? Again, cognitively disabled users, who have greater reason to "not 
know" because their means of learning is curtained by their disability, are 
apparently not excused from finding speech readers, even tho I found it 
difficult to do so myself.



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

The serious flaw was the failure to insure that the site would work if the 
text was "greeked out" by the user's disability.  I wasn't in the etc etc.

>*  will be difficult to sell
>
>    *
>       it is difficult to encapsulate. WCAG 1.0 had "access for all
>       users", OTACS-2 seems to have "access through particular tools". I
>       believe the secret to selling accessibility is convincing people
>       of the need. By moving away from users with disabilities I think
>       the guidelines begin to appear bureacratic in the least and biased
>       in the extreme.

WCAG 1.0 promised "access for all users" but left out the largest group of 
disabled users, as well as the many non-disabled users all of whom 
need/prefer/want images instead of text. OTACS-2 looks at the needs of ALL 
disabled, and identifies those which can be met by authors and which can be 
met by user tools. The OTACS-2 looks at the responsibility to meet the 
guidelines, and puts the onus on the author to meet needs only the author 
can do, and identifies those which can be met by other means. Not 
bureaucratic, just an orderly division of responsibilities....
Only an author can write the text so that it is easily understood, only an 
author can decide which illustrations apply to the text ... no tool can do 
either. Nor can a tool create an alt tag that both describes what it is, 
and fulfills (hopefully, fulfills it's function) ...

>*  sets up a category of tools that are no longer just "W3C approved"
>    but "W3C compulsory"
>
>    *
>       eg. tools without which accessibility is not possible.  If people
>       feel they have to use certain tools to get the required
>       accessibility compliance they may decide not to bother at all. An
>       example is Lotus Notes as a CMS for web sites and the coding of
>       tables. It is quite difficult to provide a table summary for
>       tables in Lotus Notes, however a content author authoring in this
>       tool would know that and ensure that the table summary is provided
>       somewhere and that the table occurs in context. However, under
>       OTACS-2, for example, a Table summary would have to be coded
>       compulsorily, this content author could then say, "well it can't
>       be done in this tool and this is the tool I have to work with".
>       OTACS-2 does not appear to allow for the content author to provide
>       alternatives dependent on the tool they are using.

On this one we agree! This sums up my feeling about the use of a speech 
reader to meet all the needs of those who don't read well for whatever 
reason. Illustrations are better by far, than an auditory rendition of the 
text! We need to encourage authors to illustrate, not just depend on speech 
readers ....

>
>    *  don't want to have to make people become *experts* in a variety of
>       tools.

I've spent the week training my 14 classes of 2nd graders to use a 5-step 
login for online tests that the county just bought .... Most classes 
required 15-20 minutes to go through all the steps, classes that were noisy 
and inattentive sometimes required the full 25 minutes just to get through 
the logins and some kids never answered the first test question!  Even the 
kids who got through the login could not read the all-text menus that 
followed, and they had to get through four of them to get to the first test 
question. [the pure reality of this week, is that from 12:30-3:00 each day, 
I've been hoofing it back and forth in a U-shaped lab (thank goodness there 
are no stations in the middle!) to a constant cat-catcaphony of "Mrs. P", 
"Mrs. P", "Mrs P" as each child hit their limit and needed me to point out 
the next step ... early in he week, I tried demonstrating the whole 
sequence, but couldn't keep the kids' attention. They had to sit at their 
computers, with me talking loud on each step, the going around the room, 
individualizing the instructions, to get the kid's through - and that after 
spending a week preparing the necklaces with all the login stuff printed, 
ready to wear to the lab, and hook under the keyboard to copy from 
...Whew!] ...

Again, I tend to agree that we don't want to require too much training or 
adults who could use the Internet will not be able to do so by taking the 
machine out of the box from the big brown truck ... But, I think that the 
OTACS-2 promises this better by asking the author to take responsibility 
for what can't be done otherwise. The user has the choice of using the 
tools or not, but the stuff that can't be done by tools is taken care of.

>*
>    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 Adobe plug-in, unlike a Speech Reader, is free and easily downloaded 
and installed. If Adobe works with all ATs, why not expect the user to have 
it? Is this not so everywhere? Are we being to US-Centric?

>*  by being reliant on tools for accessibility, sets up WCAG 2.0 to very
>    quickly become obsolete as new technologies become popular.

The WCAG 2.0 will become WCAG 2002, WCAG 2003, etc.... it will become a 
flexible and fluid as the web. The web is evolving. Standards cannot last 
... All that can last is the philosophy ... and having checkpoints 
dedicated to users, and priorities based on who/what can meet the needs, 
seems evolvable to me.

>    *
>       I don't think it's really possible for WCAG 2.0 to be written with
>       future technologies in mind. Who knew Netscape would reinvent the
>       wheel with Netscape 6.0?   : )

I gave up on Netscape when our MACs were replaced by NT workstations two 
years ago, but the only good thing I've heard is that the plug-ins come 
with Netscape 6.0 .... but the old Netscapes that run on our old equipment 
are horrid! Getting sound to work on both NN and IE is a hassle!


>I welcome your comments.

I think I gave you an outpouring. Thanks for plowing through my thoughts 
.... I started out from a "sort by biggest user group", but when I saw how 
Wendy separated the guidelines, I felt it was the best way to provide for 
users in the most efficient manner. And, I think "minimum" should be 
efficient. Yes, there is much for the author to do, but it is only the 
things that can be done ONLY by the author ... those that CAN be done by 
tools are in the next step ....

         Get Well!

                                 Anne



Anne Pemberton
apembert@erols.com

http://www.erols.com/stevepem
http://www.geocities.com/apembert45

Received on Friday, 26 October 2001 21:45:36 UTC