W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

Re: Browser and Technology Support [Was: Re: [w3c-wai-gl] <none

From: Wendy A Chisholm <wendy@w3.org>
Date: Tue, 25 Sep 2001 12:54:32 -0400
Message-Id: <4.2.0.58.20010925123624.00a75f00@localhost>
To: "Jim Ley" <jim@e-media.co.uk>, "Matt May" <mcmay@yahoo.com>, <w3c-wai-gl@w3.org>
Cc: cynthia_shelly@hotmail.com, dhipke@microsoft.com, po@trace.wisc.edu

>No, I question if it should be allowed to be used as the sole method of
>bringing accessibility, both on practical grounds of it not being
>possible, and on desirability grounds, of it being dangerous.  I
>acknowledge and know it can bring enhancements, but don't see it being
>necessary.

ok. fine.

>Your example above, is not an example of why I see client-side validation
>being valuable, in any case that makes no difference to the accessibility
>of a page, it's purely an enhancement, or were you suggesting that a
>server should accept whatever it is sent? - I hope a little thought will
>remove that notion.

no, i was not suggesting a server should accept whatever it is sent.

> > There are many good cases that e-commerce sites build for using
>scripting.
>
>Please make them?  If we look at a popular e-commerce site, say
>http://www.tesco.com , we see they throw their extensive scripting and
>make an accessible site without any http://www.tesco.com/access/
>Scripting can bring usability and acccessibility enhancements.

I did. Security and user experience. Both of which do not create 
accessibility issues - if done correctly.

>These are part of the User Agent domain, indeed if we include this as
>Alan Flavell has already noted in the thread, I've created lots of such
>methods.

Yes, these are UA issues.  However, the examples I gave were used as 
stop-gap measures <em>before</em> UAs did these type of things.

>    Equally your table page obviously
>wasn't authored to appropriate standards, if it was using non-tabular
>data in a tabular form, the page could've been authored in a way such
>that the script enhancement wasn't necessary.  So the author was at
>fault.

No, the page was authored with appropriate standards.  It was using data in 
a data table.  To more easily read the data, the user was able to read by 
row or column - since these are the appropriate groupings of data.  This is 
how tables are read - comparing data between cells.

Please keep in mind that this was created <em>before</em> user agents or 
assistive technologies provided this functionality.  Let me emphasize my 
point: I used this example to show that client-side scripts had been used 
to help make content more accessible due to inadequacies in the UA/AT. It 
was not to show that client-side scripting should be done <em>instead</em> 
of UA/AT support.

>I'm very surprised that you have the impression that I believe script can
>be made, or would be desirable to have it go away, I am a javascripter by
>profession, I author the comp.lang.javascript FAQ, I do a lot to promote
>javascript use, and to push the boundaries of what can be done, and this
>is one reason why I believe I can comment on this. I've given examples of
>accessible scripting

Then, as I alluded in my previous message, I misunderstood your intent.

  I just have not been
>convinced by any arguments that say javascript could or should be
>necessary for accessibility of HTML pages (SVG, SMIL perhaps, there the
>more interactive nature could make a difference.)

OK. I understand now.  I agree.  Sorry for the confusion.

>On a more constructive note,  Later today/tomorrow I'll  likely posting
>an early Alpha release of an automatic script tester, which provides some
>suggestions based on the script that is used on the page.

cool. I look forward to that.

Now...how did we get onto this tangent from gregg's original message?
http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/1048.html

Scenario A: until user agents - blech.
Scenario B: yes, technology-specific implementation info should be at the 
technology level.
Scenario C: no, technology-specific support info should not be incorporated 
in the Guideline level of the doc.

In regards to the first two not being normative and therefore not making it 
to the developer.  I disagree. I thought we had agreed (as recently as 2 
weeks ago) that technology-specific checkpoints were to be 
normative?  Giving us 2 layers of normative info??

This is where Al's suggestion to scrap Guidelines and preserve and expand 
upon success criteria comes in.
http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/1052.html

--wendy
--
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
/--
Received on Tuesday, 25 September 2001 12:52:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:14 GMT