Re: Accessible road maps

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