MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Alan Chuter
Following from the discussion in the call yesterday regarding this BP
[1], I would remind people that as well as the script element, XHTML
(and Basic) [4] provides the noscript element. Any content within this
element will be ignored if script is executed but rendered if it is not.
Unless I'm missing something, this would be a much more elegant way of
fulfilling the intent of this BP.

Surprisingly this solution is not mentioned in the BP1 document [2]
either, which simply suggests a test for compliance, although it does
link to WCAG 1.0 checkpoint 6.3 [3] which says "If it is not possible to
make the page usable without scripts, provide a text equivalent with the
NOSCRIPT element, or use a server-side script instead...".

This seems (unless I'm  missing something) like a much more reliable
technique than checking against a DDR.

regards,

Alan


[1] http://www.w3.org/TR/mwabp/#bp-devcap-scripting-support
[2] http://www.w3.org/TR/mobile-bp/#OBJECTS_OR_SCRIPT
[3] http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts
[4]
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_scriptmodule
--
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: 91 375 70 51
[hidden email]
http://www.technosite.es


Reply | Threaded
Open this post in threaded view
|

RE: MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Rotan Hanrahan
While a DDR (if well maintained) can indicate whether or not the client is script-capable, it is also possible that the end user has disabled scripts, so <noscript> can be useful here. Of course, if DCCI/OMADPE were available then you could test dynamically for script-enablement, but these technologies are yet to make any appearance in the market whereas DDRs actually exist today. (They have existed for years, as the venerable WURFL proves, and professional/commercial DDRs are available from many vendors too.)

If your DDR doesn't indicate script-capability, and the script isn't that important, then don't use the script. You'll save a bit of bandwidth too. If the script is important, and there's some doubt about whether the device will execute it, the <noscript> element is advised.

If you don't have a good DDR at your disposal, and you need to detect if script is present, you can try a scripted sniffer at the start of the session. The script merely causes something to be retrieved from the server (or passed in a subsequent request) that tells the server that scripts are being executed. Of course, these sniffers can become complex over time, and there's always the danger that a sniffer may adversely affect the "snifee".

If you are targeting just a few (high-end) devices, scripts can be wonderful enhancements. If you are trying to cover a wide range of devices (1000s of models) then scripts can be quite challenging. So another motivation for providing a non-script version is because you've spent all your time/energy/money dealing with just a few fancy devices :)

---Rotan
CIA/CTO MobileAware.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Alan Chuter
Sent: 25 November 2009 11:39
To: MWI BPWG Public
Cc: David Torres
Subject: MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Following from the discussion in the call yesterday regarding this BP
[1], I would remind people that as well as the script element, XHTML
(and Basic) [4] provides the noscript element. Any content within this
element will be ignored if script is executed but rendered if it is not.
Unless I'm missing something, this would be a much more elegant way of
fulfilling the intent of this BP.

Surprisingly this solution is not mentioned in the BP1 document [2]
either, which simply suggests a test for compliance, although it does
link to WCAG 1.0 checkpoint 6.3 [3] which says "If it is not possible to
make the page usable without scripts, provide a text equivalent with the
NOSCRIPT element, or use a server-side script instead...".

This seems (unless I'm  missing something) like a much more reliable
technique than checking against a DDR.

regards,

Alan


[1] http://www.w3.org/TR/mwabp/#bp-devcap-scripting-support
[2] http://www.w3.org/TR/mobile-bp/#OBJECTS_OR_SCRIPT
[3] http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-scripts
[4]
http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_scriptmodule
--
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: 91 375 70 51
[hidden email]
http://www.technosite.es


Reply | Threaded
Open this post in threaded view
|

Re: MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Alan Chuter
Rotan Hanrahan wrote:
> If your DDR doesn't indicate script-capability, and the script
 > isn't that important, then don't use the script. You'll save a
 > bit of bandwidth too. If the script is important, and there's
 > some doubt about whether the device will execute it, the
 > <noscript> element is advised.

Now I understand, the DDR should be the first line of defence. If you
know that device doesn't support script then don't even bother with
script or noscript.

If you are unsure, and use the noscript element, I would add that it
should contain a minimal explanation and a link to an alternative, to
avoid unnecessarily sending people alternative content they may not need
or ever read.



--
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: 91 375 70 51
[hidden email]
http://www.technosite.es


Reply | Threaded
Open this post in threaded view
|

RE: MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Rotan Hanrahan
> ... I would add that it
should contain a minimal explanation and a link to an alternative, to
avoid unnecessarily sending people alternative content they may not need
or ever read.

Well, maybe. The <noscript> content might itself be a suitable alternative, rather than a link to an alternative or some explanation/apology regarding the absence of the scripted feature. It all depends on what you were trying to achieve with the script.

Still, you are absolutely correct regarding the use of a DDR as a first line of defence. Use the DDR to avoid sending things to the client that won't work or could even be harmful. After that, use it to select what is best for the device from whatever options are available to you. Of course, the BPs should also give you pointers as to how to proceed when you are unfortunate enough to be without a good DDR. Proceed with caution, is perhaps the best advice.

---Rotan

-----Original Message-----
From: Alan Chuter [mailto:[hidden email]]
Sent: 25 November 2009 12:16
To: MWI BPWG Public
Cc: Rotan Hanrahan
Subject: Re: MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Rotan Hanrahan wrote:
> If your DDR doesn't indicate script-capability, and the script
 > isn't that important, then don't use the script. You'll save a
 > bit of bandwidth too. If the script is important, and there's
 > some doubt about whether the device will execute it, the
 > <noscript> element is advised.

Now I understand, the DDR should be the first line of defence. If you
know that device doesn't support script then don't even bother with
script or noscript.

If you are unsure, and use the noscript element, I would add that it
should contain a minimal explanation and a link to an alternative, to
avoid unnecessarily sending people alternative content they may not need
or ever read.



--
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
Fundación ONCE
Tfno.: 91 121 03 30
Fax: 91 375 70 51
[hidden email]
http://www.technosite.es

Reply | Threaded
Open this post in threaded view
|

Re: MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate

Francois Daoust
For linking purpose, I note that the <noscript> point raised by Alan was
also raised by Marc Wilson in a last call comment (LC-2287):
 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-mwabp-20091006/2287 
(member-only link)
 
http://lists.w3.org/Archives/Public/public-bpwg-comments/2009OctDec/0049.html

Francois.


Rotan Hanrahan wrote:

>> ... I would add that it
> should contain a minimal explanation and a link to an alternative, to
> avoid unnecessarily sending people alternative content they may not need
> or ever read.
>
> Well, maybe. The <noscript> content might itself be a suitable alternative, rather than a link to an alternative or some explanation/apology regarding the absence of the scripted feature. It all depends on what you were trying to achieve with the script.
>
> Still, you are absolutely correct regarding the use of a DDR as a first line of defence. Use the DDR to avoid sending things to the client that won't work or could even be harmful. After that, use it to select what is best for the device from whatever options are available to you. Of course, the BPs should also give you pointers as to how to proceed when you are unfortunate enough to be without a good DDR. Proceed with caution, is perhaps the best advice.
>
> ---Rotan
>
> -----Original Message-----
> From: Alan Chuter [mailto:[hidden email]]
> Sent: 25 November 2009 12:16
> To: MWI BPWG Public
> Cc: Rotan Hanrahan
> Subject: Re: MWABP: 3.6.4 Support a non-JavaScript Variant if Appropriate
>
> Rotan Hanrahan wrote:
>> If your DDR doesn't indicate script-capability, and the script
>  > isn't that important, then don't use the script. You'll save a
>  > bit of bandwidth too. If the script is important, and there's
>  > some doubt about whether the device will execute it, the
>  > <noscript> element is advised.
>
> Now I understand, the DDR should be the first line of defence. If you
> know that device doesn't support script then don't even bother with
> script or noscript.
>
> If you are unsure, and use the noscript element, I would add that it
> should contain a minimal explanation and a link to an alternative, to
> avoid unnecessarily sending people alternative content they may not need
> or ever read.
>
>
>