Re: Accessible road maps

Hi Kerstin,

  No, I am not telling anyone not to do something or to do anything. I
agree with you on artificially limiting features.  I am just after a
reason on why we need scripting.  I am after this, because this thread
started a debate on whether or not to recommend using scripts as it is
currently not recommended.  I am after an answer of whether it is NEEDED
or simply wanted.  Did I say that we couldnt have it if it were simply
wanted?  I dont remember saying that.  But I do think we need to get our
ducks in a row on what is NEEDED to solve what problems and what is NICE
TO HAVE to solve other problems and what DOESNT WORK AKA INACCESSIBLE. 
Given a multitude of sightings, sources and examples that we can
conclusively state and not biasly state,  others can take that input and
modify the these techniques to solve their problems with accessiblity.

As for partial page refreshing, have you tested it with cognitively
impaired users?  What about Senior Citizens or new users of the web?  Do
they become confused when the page partially refreshes?

-Steve


Kerstin Goldsmith said:
> Hey, there.
>
> OK, just a quick response.  We are not talking about amateurish uses of
> scripting here - these are exceptionally talented web applications
> developers who are using scripting in very creative ways.  It's not our
> place to tell them HOW to do their job - it's only our job to tell them
> HOW TO DO IT ACCESSIBLY.  These guys are using scripting to make the
> lives of people with and without disabilities easier.  One example is
> partial-page refresh, which is done with scripting and forms submittal.
>  Blind users, at least, who have tested it agree that our partial-page
> refresh actually makes their lives easier - they don't lose focus, and
> their screen readers work well with it. Other customers, without
> disabilities, agree that partial page refresh rocks.
>
> Again, I think your focus is way off here.  We should not be in the
> business of telling people what to use, but to tell them how to use /all
>  /their choices accessibly.  From there, they will make the right choice
>  according to the myriad of other requirements that come into play for
> their products/sites in addition to accessibility.
>
> Cheers,
> -Kerstin
>
> p.s.   Using your analogy, I think you are the one trying to say,
> "because I told you so."  In other words, you are the one being the
> dominating parental figure by telling people simply "not to eat any
> candy at all!" instead of educating them about what over-indulgence in
> sugar can do to the body, appetite, energy, etc.. and giving them the
> choice of informed moderation (just to take the analogy a little
> further).
>
>
> Steven Dale wrote:
>
>>First let me say I am not trying to put scripting back in the box nor
>> am I supporting the use of scripting.
>>
>>But I think, and it is only my opinion, that having neat little tricks
>> and gizmos just because they are cool went out with the nineties web.
>> I think we need to think about what is needed and why it is needed in
>> order to be mentioned in the guidelines.  If, something can be done in
>> an equal way that is more accessible than the alternative, that should
>> be pointed out and strongly urged as in techniques.  However, if we
>> want to encourage scripting just because it already exists, there is an
>> amaturish sense of using features because they are there.  There is
>> also the credibility issue where we push for new and keeping existing
>> features of HTML with no REAL need.
>>
>>As for accessibility technology, a problem we are facing now is the
>> overly complex user agents.  Where we are having to make complex UAs in
>> order to solve accessibility problems of features that are not
>> necessary.  And then you have the very limited UAs of Cell Phones and
>> PDAs.  What about them?  Mind you that these devices dont have the
>> memory available to casually bloat software UAs.  Keep in mind too, the
>> multitude of disabilities that can impact the user in many areas such
>> as Sight, Audio, Motor, and Cognitive skills.
>>
>>I believe if you want business to buy into accessibility and developers
>> to write accessible UAs then you need to better define what parts of
>> (X)HTML need to used, which parts are optional, but accessible, and
>> which parts are not accessible.  When documenting this, one needs to be
>> scientific with examples and sources.  Merely stating that since it has
>> been done this way in the past is not acceptable.  I bet you never
>> liked it when your mother told you "because I am the mother" when
>> explaining why something is the way it is.  Why should you expect
>> businesses to buy into that?
>>
>>-Steve
>>
>>
>>
>>Kerstin Goldsmith said:
>>
>>
>>>I am not sure that this question is really relevant.  I think a more
>>> important question is "should we be restricting people's choices of
>>> different technologies in the name of accessibility when those
>>>technologies can be used to create accessible interfaces."  It's not
>>> our
>>> job to ask people to prove that they HAVE to do something one way
>>> over
>>>another.  It's our job to realistically look at all technologies out
>>> there that people WILL use, and come up with ways for them to use them
>>> accessibly.  Pandora's box is open, we are not going to be able to put
>>> scripting back and shut the lid - so we better help people understand
>>> the choices they have in HOW they implement scripting.
>>>
>>>My three cents.
>>>-Kerstin
>>>
>>>-Kerstin
>>>
>>>Steven Dale wrote:
>>>
>>>
>>>
>>>>This is all a nice argument for the sake of debate.
>>>>
>>>>But my question still has not been answered,
>>>>why do we NEED client side scripting.  Can someone give me an example
>>>> that requires Client Side Scripting while remains accessible when the
>>>> scripting is used?
>>>>
>>>>-Steve
>>>>
>>>>Phill Jenkins said:
>>>>
>>>>
>>>>
>>>>
>>>>>Matt wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>So, what do we do? Banish scripting from the Web? Certainly not. We
>>>>>> may
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>David responded:
>>>>><clip>
>>>>>Remember that HTML and thus the web were created in deliberate
>>>>> rejection of more sophisticated tools...
>>>>>
>>>>>Phill replies:
>>>>>I view HTML's purpose a little differently and I believe it has
>>>>> evolved.
>>>>>For example, events such as onClick, onKeyPress, etc are actually
>>>>> part
>>>>>of  the HTML spec [see note 1].  I had thought they were part of the
>>>>> JavaScript spec but they are not!
>>>>>
>>>>>David continued with:
>>>>>Most web sites nowadays are computer programs, not documents, and
>>>>> attempt to override the viewing tool's user interface.
>>>>>
>>>>>Phill replies:
>>>>>That is exactly Matt's point.  You seem to be supporting his
>>>>> argument. Many WAI individuals have focused on "banning"
>>>>> interactivity of web sites  created from events and scripting that
>>>>> now we are late coming up with  better techniques and specs to solve
>>>>> the problems.  Same thing happened  over a decade ago when command
>>>>> line PC DOS
>>>>>applications were replaced with  Window GUI's.
>>>>>
>>>>>Regards,
>>>>>Phill Jenkins
>>>>>
>>>>>[Note 1] HTML 4 spec on Events
>>>>>http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.3
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>

Received on Tuesday, 1 June 2004 18:41:16 UTC