W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2005

Re: HTML Techniques16.1, 10.6 baseline Discussion

From: Roberto Scano - IWA/HWG <rscano@iwa-italy.org>
Date: Wed, 13 Apr 2005 10:35:15 +0200
Message-ID: <003c01c54003$b9be8e80$0200a8c0@iwars>
To: "David MacDonald" <befree@magma.ca>, <w3c-wai-gl@w3.org>


----- Original Message ----- 
From: "David MacDonald" <befree@magma.ca>
To: <w3c-wai-gl@w3.org>
Sent: Wednesday, April 13, 2005 4:33 AM
Subject: HTML Techniques16.1, 10.6 baseline Discussion



Task:
Use noscript when using script.

For Baseline that requires text only (lynx) There needs to be a purely 
text
alternative. (Not NoScript)

For a baseline that requires HTML, CSS (not JavaScript) there should a
noScript

For a Baseline that supports Javascript, There should still be redundant
links (for menus) and text alternatives.

Roberto:
I partially disagree with this solution.
We need to remember that we are defining accessibility for existing 
specifications.

<cite 
url="http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.3.1">
The NOSCRIPT element allows authors to provide alternate content when a 
script is not executed. The content of a NOSCRIPT element should only be 
rendered by a script-aware user agent in the following cases:
  a.. The user agent is configured not to evaluate scripts.
  b.. The user agent doesn't support a scripting language invoked by a 
SCRIPT element earlier in the document.
User agents that do not support client-side scripts must render this 
element's contents.

In the following example, a user agent that executes the SCRIPT will 
include some dynamically created data in the document. If the user agent 
doesn't support scripts, the user may still retrieve the data through a 
link.

<SCRIPT type="text/tcl">
 ...some Tcl script to insert data...
</SCRIPT>
<NOSCRIPT>
 <P>Access the <A href="http://someplace.com/data">data.</A>
</NOSCRIPT>
</cite>In the proposal you ask to a developer to use noscript + the same 
contents of noscript visible in public content.<cite>
"For a Baseline that supports Javascript, There should still be 
redundant
links (for menus) and text alternatives."
</cite>

I think that will cause the same "trap" of client side image maps. We 
need to think that an user can configure an user agent for interact with 
contents. In case of JS, we need to ask that, if JS is supported, JS 
must be accessible.
For people that cannot access to js (disabled in user agent, not 
supported, other, ...) should be present a <noscript> section that give 
the possibility to the user to have the same interaction:
- if js refer to access to some menus, offer the access to them:

Eg:
<script type="text/javascript" src="choosesites.js"></script>
<noscript>
<a href="/">Home Page</a><br />
<a href="http://www.google.com/">Google</a><br />
<a href="http://www.w3.org/">W3C</a><br />
</noscript>

I can see the requirements as: you need to put all also visible, so why 
use JS? This could be good, but this will force a wrong use of the 
specifications and of the freedom of the user: an user, with its 
browser, should access to a script and, if not able to access, should 
disable scripting and access to <noscript> (btw, I think this is an 
assistive technology "problem").

Hope this helps.

Roberto Scano (IWA/HWG)
Received on Wednesday, 13 April 2005 08:58:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:36 UTC