[TECHS] Review of SC with respect to Scripting and baseline issues.

Matt May and I took an action item at the May 25 techniques teleconference 
to review the GL and SC with respect to scripting baselines.   I did the 
initial review and forwarded to Matt for further comment.  I have 
incorporated some of his comments directly into the prose but most are 
marked with "Matt:".



<begin Guideline 1.1>
The current proposal for Guideline 1.1 is, "Provide text alternatives for 
all non-text 
content."

At April 28 meeting the group seemed to agree that widgets (which are 
created via JavaScript) are not part of Guideline 1.1 so there should be 
no baseline implications for the script techniques for this guideline.  If 
we did consider widgets as non-text content, there might be some 
implications for the proposed Level 1 SC 4. 

<begin GL 1.1 L1 SC4>
   4. Non-text content that does not convey information, functionality, 
or create a specific sensory experience is implemented such that it can 
be ignored by assistive technology. [I] 

JavaScript used for purely decorative reasons, like changing an icon type 
in a timing loop, would fall under this guideline. I'm not sure it is 
worthy of any techniques since this type of JavaScript isn't something we 
want to encourage. 

-scripting not in baseline: Author  would need to be implement the code so 
there were no errors or problems when JavaScript was not available. 

-scripting in the baseline:  In this example, the code must not do 
anything to set focus to the changed icon nor alter the navigation through 
the page. 
<end GL 1.1 L1 SC4>

<end Guideline 1.1>

<begin Guideline 1.2>
There are no scripting implications in Guideline 1.2,  "Provide 
synchronized alternatives for multimedia."

Matt: Though we could probably work out techniques on how to use JS as the 
glue for synchronization.

<end Guideline 1.2>

<begin Guideline 1.3>
I am working from the latest proposal for GL 1.3[1] 
Where permitted by the markup languages and technologies in use, ensure 
the separation of        structure, presentation, and behaviour.

At the April 28 meeting where people discussed whether or not widgets (and 
thus, in my mind, JavaScript) belonged in Guideline 1.1, it was suggested 
that they would be covered in 1.3. 

I'm not sure I can see that connection.  The current proposal for L1 SC 4,
4. Markup or coding for presentation or behaviour uses
                 accessibility features available in the technologies
                 being used.,

would likely cover JavaScript as coding for behavior.  Is this the SC that 
will force JavaScript to be accessible if it is assumed to be in the 
baseline?  Otherwise I don't see any JavaScript baseline implications in 
GL 1.3.
<end Guideline 1.3>

<begin Guideline 1.4>
Guideline 1.4 Make it easy to distinguish foreground information from 
background images or sounds.

I don't see any implications for a baseline with no scripting - this 
becomes just an image and audio issue.  With scripting turned on, however, 
there are some possible techniques that can be used to meet this 
guideline. 

For L1 SC 1, 
1.      Any text that is presented over a background image, color, or text 
can be programmatically determined. [I] 

Matt: There are several Image Replacement techniques, each with positives 
and drawbacks, and sIFR, which uses a Flash stub, and is actually my 
favorite.
http://www.mezzoblue.com/tests/revised-image-replacement/
http://www.mikeindustries.com/sifr/

For L2 SC3 
Users can disable background audio that plays automatically on a page so 
that it does not interfere with text reading software they may be using. 
[V] 

JavaScript can be used to provide a button to disable background audio. 
But, that isn't particularly helpful if JavaScript is turned off or 
unavailable so perhaps this guideline should be reworded to prevent audio 
from continuously looping or to limit the length of the audio.  With 
JavaScript in the baseline, the audio might be started via JavaScript and 
a button to turn it off also provided so it would not run unless there was 
also a method to turn it off. This might make a worthwhile technique - 
testing for JavaScript before allowing the audio to play.
< end Guideline 1.4>

<begin Guideline 2.1>
Guideline 2.1 Make all functionality operable via a keyboard or a keyboard 
interface.

For L1 SC1:
All of the functionality of the content, where the functionality or its 
outcome can be described in a sentence, is operable through a keyboard or 
keyboard interface. [I] 
Note:This includes author-provided accessibility features.

In a baseline with no JavaScript, the author must use only standard anchor 
tags and form elements which are given keyboard support via the user 
agent.  Techniques would be  helpful to show how to provide additional 
functionality via JavaScript but also to provide "standard" support via a 
valid href attribute on an anchor tag. I think that relates to this 
guideline because people often use anchor tags to invoke JavaScript 
functions because anchor tags are in the tab order and onclick is invoked 
via the mouse and the keyboard. 

In many of the cases where JavaScript is used to provide keyboard support 
there is often no way to provide fallback support if JavaScript is 
unavailable.  Generally the tabindex attribute is used on elements other 
than anchors and form elements to provide more complicated widgets.  In 
these cases, JavaScript will be required to provide an onclick or onkeyXX 
handler.  If JavaScript is unavailable the functionality will not be, 
either.  So, this is a case where there is no easy fallback and the author 
needs to be sure that JavaScript will be available and turned on.  The 
current technique about changing focus is related to this guideline 
although I'm not sure this is the best match.  I see it under 3.2 and 
extreme change of context, although changing focus isn't always "extreme". 
 The DHTML roadmap makes use of the focus() event in order to implement 
keyboard support and this type of focus change is currently fairly well 
supported by screen readers.  The focus technique probably fits under the 
no scripting or scripting with fallback techniques but not under the 
scripting allowed baseline. 

Matt: This could be a place for a blanket technique to cover loading 
forked code when a JS engine is present.

L2 SC1: 
 Wherever a choice between input device event handlers is available and 
supported, the more abstract event is used. [I] 

I'm not sure I even see the need for this SC.  We have already stated that 
the interface must be operable through a keyboard, so why any specific 
requirement about the type of event handlers?   I think I should see 
baseline implications here, but I don't. 

Matt: I think this is a nudge to use onfocus rather than onmouseover. 
That's already in UAAG.

If scripting is not in the baseline, there should be no issues here. There 
maybe some fallback implications but I can't think of a good example.  For 
JavaScript in the baseline, I think this is covered by L1 SC1 - make the 
interface operable via a keyboard.


L3 SC1 is just a further requirement that all functionality is operable 
via the keyboard.  Thus, a baseline that includes scripting would need to 
provide keyboard equivalents for mouseover effects and any other strictly 
decorative or nonfunctional embellishments. Should we include techniques 
for this as it doesn't necessarily affect accessibility if it is 
nonfunctional?

Matt: If nothing else, there should be a technique that says "don't cause 
anything functional to change in onmouseover". (I think I said something 
like that in the Accessibility Forum Objective Measures group, too...)
</end guideline 2.1>

<begin guideline 2.2>
Guideline 2.2 Allow users to control time limits on their reading or 
interaction.


For L1 SC1:
Content is designed so that time-outs are not an essential part of 
interaction, or at least one of the following is true for each time-out 
that is a function of the content: [I] 
the user is allowed to deactivate the time-out or; 
the user is allowed to adjust the time-out over a wide range which is at 
least ten times the length of the default setting or; 
the user is warned before time expires, allowed to extend the time-out 
with a simple action (for example, "hit any key") and given at least 20 
seconds to respond or;
the time-out is an important part of a real-time event (for example, an 
auction), and no alternative to the time-out is possible or;
the time-out is part of an activity where timing is essential (for 
example, competitive gaming or time-based testing) and time limits can not 
be extended further without invalidating the activity.

There are certainly techniques that can be created when scripting IS in 
the baseline.  I can't think of any scripting techniques that would be 
appropriate for the no script baseline or even for fallbacks.  If 
scripting was going to be used to allow someone to extend timeouts it 
would certainly have to be available and turned on. 

Matt: It would make sense that any timeouts set using setTimeout or 
setInterval would no longer be a problem if JS were disabled...


For L2 SC1: A method is provided to stop content that blinks for more than 
3 seconds. [I] 

Blinking is still a controversial issue but scripting in the baseline 
makes it easier to implement and still meet the GL.   With scripting in 
the baseline, a  page could load with blinking that stopped after 3 
seconds and with a button to toggle the blinking back on/off.  Or, the 
page could load with blinking off, and a button could be provided for the 
user to enable blinking.  Scripting allows the implementation of blinking 
without using the HTML <blink> element. With no scripting in the baseline 
blinking could be stopped by providing a link to an alternative page as 
the first tab stop on the page although the better solution would be to 
not include any blinking in the no scripting baseline. 

Matt: CSS allows elements to be made to blink, too.  I think we may not 
want to cover this one in techniques because it's not a particularly 
common scenario, IMO. Or, we could take this to mean <blink> or 
text-decoration: blink, and use JS as the mechanism for switching that 
functionality on or off.

For L2 SC2: A method is provided to pause and/or permanently stop dynamic 
(moving or time-based) content. [I] 

Although always controversial, scripting in the baseline does allow a way 
to implement scrolling or moving content without the use of the marquee 
element.  And, it can be implemented so the user must select to have the 
content move or it can be set up to stop automatically after a particular 
time limit.  No scripting in the baseline would prevent any type of time 
based content as there would be no way I know of to disable it without 
script. 

I don't see any further implications for L3 SC1: With the exception of 
real-time events, content has been designed in a way that timing is not 
designed to be an essential part of the activity and any time limits in 
the content would pass level 1, success criteria 1 for this guideline. [V] 


For L3 SC2:
Any non-emergency interruptions, such as the availability of updated 
content, can be postponed and/or suppressed by the user. [V] 

I don't see any way to implement this without scripting in the baseline 
other than providing alternative pages for the user to select -one with 
auto updates and another without.  The other alternative is to have no 
interruptions or updated content at all.  A baseline with scripts could 
allow the user to select the option for turning on interruptions or 
updates for specific reasons but would not load the page with the updates 
on by default. But, at the May 26 meeting where we discussed the following 
proposal:
<proposed>
Non-emergency interruptions, such as the availability of updated content, 
are turned off by default. [V]
</proposed>
people had concerns about requiring the updates to be turned off by 
default.  Thus, in order provide a page with auto-updates and to comply 
with this as currently written, the user would need scripting in the 
baseline and it must be turned on or the author must provide an 
alternative page. 
Matt:  I agree. I also have reservations about defaulting to no updated 
content, since with the roadmap and things like AJAX, it should be 
possible to add new content in a usable context without the excess 
screen-reader chatter that I believe is the problem this intends to solve. 
It's also a horrible choice for something like an email site to make: 
either make it unusable to most of your users out of the starting gate, or 
be labeled inaccessible.
<end guideline 2.2>

<begin guideline 2.3>
I have used the updated wording that was approved at the May 26 meeting:
Guideline 2.3 Allow users to avoid content that could cause seizures due 
to photosensitivity.

L1 SC1:
Content that violates international health and safety standards for 
general flash or red flash is marked in a way that the user can avoid its 
appearance. [V] 

If you know scripting is in the baseline and turned on the author could 
create an onload handler to prompt the user about flashing content before 
the page is displayed.  The default would have to be that the page is 
loaded without the flashing in case scripting was turned off.  With either 
baseline the author could just not use any content that violates the 
standards (and thus also meet  L2 SC1) or provide alternative pages - one 
with flash and one without - although providing alternative pages seems 
problematic since the "bad" page could be linked to from other sites. 

Matt: Yes, a confirm() should be a sufficient technique for this.

L2 SC1 and L3 SC1 :  No scripting implications - just don't use content 
that violates the thresholds.

<end guideline 2.3>

<begin guideline 2.4>
Guideline 2.4 Provide mechanisms to help users find content, orient 
themselves within it, and navigate through it.

I'm going to pass on this one until it is discussed again at the next 
working group meeting.  It is my understanding that a small group has been 
working on this and made significant changes.
<end guideline 2.4>

<begin guideline 2.5>
Guideline 2.5 Help users avoid mistakes and make it easy to correct them. 
No L1 SC.

L2 SC1: 
If an input error is detected, the error is identified and provided to the 
user in text.  (new wording adopted at May 19 meeting).

Certainly scripting can help to achieve this SC client side.  It does have 
some issues to make sure it is accomplished with accessibility in mind. 
One method might be to raise an alert to identify the error.  That assumes 
that an alert is not considered an extreme change of context. This is one 
area where setting focus could be used as an advantage to place the cursor 
in the field that needs to be corrected.  Scripting might also be used to 
dynamically change the contents of the page to mark the field in error. Do 
we know that AT supports the focus and content rewrite sufficiently to 
provide techniques?  Generally any web application is going to provide 
server side as well as client side checking so scripting is really a 
performance enhancement unless the page is  completely inoperable without 
scripting available (which is possible in some web applications).

Matt: I think this will need to be tested across ATs. The theoretical best 
answer is to instruct JS developers to use DOM insertions rather than 
document.write(), but I know that a lot of things like that are hacked in 
and possibly better-supported than the DOM. JS should be acknowledged to 
be for the benefit of the user interface and reduced server load for CPU- 
or disk-intensive operations, not as a full replacement for server 
interaction. A technique I wrote got knocked around for not disclosing 
that position, but I think it's still useful.

For a non scripting baseline error checking  would need to be performed 
server side and the returned page would need to describe the error, 
preferably at the top of the page, and mark the fields in error in some 
color-neutral manner.  Are there other non-scripting ways to meet this 
guideline? 

Matt: I would _really_ love to write a technique that would parse the same 
rules on the client and server. Something like an XML file that indicates 
constraints and how to message them, and that can be processed by JS on 
the client and PHP/ASP/JSP/whatever on the server.

L2 SC2: If an input error is detected and suggestions for correction are 
known and can be provided without jeopardizing the security or purpose of 
the content, the error is identified and the suggestions are provided to 
the user. (new wording adopted at the May 19 meeting)

I see the same issues with this SC as the previous one.  Scripting can 
certainly be used to perform this client side but server side checking is 
usually also required unless the page will not operate when scripting is 
not available. 

Skipping L3 SC1 for now since there are many open issues with proposed new 
wording and with the selection of 75 as the threshold. 

L3 SC2: If possible for the natural language of the text, an option is 
provided to check text entries for misspelled words with suggestions for 
correct spellings. 

Spell checking could be implemented without using scripting but this is 
one area where I think scripting can  make the user interface  easier. 
Although, it is not something we are likely to provide a technique for 
since it is rather complicated and involves server side work and the 
availability of language specific dictionaries.  So, I don't really see 
any scripting issues.   An advanced web application might only provide 
this when scripting is enabled and not offer the option is scripting is 
not in the baseline or not turned on.  Since it is at level 3, I don't see 
many issues.

Matt: Using AJAX, this is viable in script on an interactive basis. But 
the accessibility issues of that have yet to be considered, much less 
ironed out. Without script in the baseline, the spell-checker would 
require a submit, and JS wouldn't be able to embellish that in any way I 
can think of.

<end guideline 2.5>

<begin guideline 3.1>
Guideline 3.1 Make text content readable and understandable. (proposed new 
wording)

This Guideline is going through extensive rework and review so I'm only 
going to comment on it in general terms for now.
Most of the SC can be achieved without any scripting.  Scripting could 
possibly be used to improve on the accessibility. For example, I could 
mark up all of the acronyms in a page with some specific CSS and then 
provide a button which uses JavaScript to find all the words and 
associated expansions and display them in an alert.  This doesn't 
necessarily provide any better support than existing AT but it might help 
a non-AT or screen magnifier user.  This type of technique could be used 
to satisfy some of the other proposed SC as well. 
<end guideline 3.1>

<begin guideline 3.2>
Guideline 3.2 Organize content consistently from "page to page" and make 
interactive components behave in predictable ways.
This guideline is just beginning review in the working group.  It has been 
proposed  that L1 SC1, Any extreme change of context is implemented in a 
manner that can be programmatically identified. [I],  be removed.

If we keep this and the other SC related to extreme change of context we 
need to be clear in the scripting techniques on how to use alerts and 
whether or not they are considered "extreme change of context". They 
certainly can change the currently focused element and cause problems but, 
most ATs do deal with them fairly well and, I think they qualify as 
"programmatically determined".   Alex has proposed eliminating this SC 
because it deals mainly with pop-up windows and he feels that the User 
Agents should deal with that issue and not the web author. 

With no scripting in the baseline I think that this SC is really just 
about pop-up windows that are invoked via an anchor tag.  In these cases 
the author can properly mark up the anchor tag and the "programmatically 
determined' part of this SC is achieved. 

I see the L2 SC affected most by scripting.   Certainly if scripting is in 
the baseline, these SC provide some specific guidelines to enforce 
accessibility. 
Numbers 2, 3, and 4 all speak to me about scripting in an accessible 
manner.
2 )All user interface components should be able to receive focus without 
causing activation. [I] 
3) Changing the setting of any input field should not automatically cause 
an extreme change in context such as leaving the "page." [V] 
4) Interactive elements that appear on multiple "pages," including 
graphical elements, are associated with the same functionality wherever 
they appear. [I]

 These SC force any widgets I create to behave in a particular manner and 
requires me to use onchange and other events responsibly.  I don't know 
how you would even cause an extreme change of context by changing the 
setting of an input field in a baseline with no scripting??? 

There are open issues with L2 SC 6:
The destination of each link is identified through words or phrases that 
either occur in the link or can be programmatically determined. [V] 

This could be problematic for baselines with scripting.  IF the author has 
created an anchor tag that invokes a scripting function, can the 
"destination" be identified?  Is this requiring the link to describe the 
outcome of the function?   What if the author uses a <div> tag with a 
tabindex and proper event handlers to invoke a function.  Since it is no 
longer a link, is this SC no longer applicable?  I'm not sure there is 
another SC that would cover properly describing the outcome of actions??? 
The author would need to explain what the interaction element does, we 
just need to make certain it is done accessibly.  I think the following 
might slip through the cracks:
<div onclick="someFunction();" onkeypress=if (event.keyCode == 13) { 
return someFunction(); }" tabindex="0" >Click me</div> 
if there was no title or additional description that AT could pick up but 
the visible placement on the page made it obvious to a sighted user.  This 
might get caught by GL 4.1 since it uses the tabindex attribute on a <div> 
element which would not pass validation against HTML 4.01.
<end guideline 3.2>

<begin guideline 4.1>
Guideline 4.1 Use technologies according to specification.
L1SC1:

1.      Except where the site has documented that a specification was 
violated for backward compatibility or compatibility with assistive 
technology, the technology has: [I] 
a.      passed validity tests for the version of the technology in use 
(whether it be conforming to a schema, Document Type Definition (DTD), or 
other tests described in the specification),
b.      structural elements and attributes are used as defined in the 
specification.

I have issues with this one since often people make use of user agent 
specific "enhancements" when scripting.  As I've mentioned before, the 
DHTML roadmap relies on the use of the tabindex attribute on any element 
and a particular behavior implemented by IE and Firefox 1.1 so be able to 
set focus to any element on the page or to add any element into the tab 
order of the page. While the DHTML roadmap is a standards based project, 
the use of the tabindex attribute is not standard. I have heard that there 
will be no additions to the HTML 4.01 specifications, thus a tabindex 
attribute on elements other than anchor or form elements will never pass 
validation in HTML 4.01 nor XHTML 1.0 or 1.1.   I could claim that the 
DHTML roadmap work does help achieve "compatibility with  assistive 
technology" so perhaps it is covered. But, if I only wanted to implement 
the keyboard accessibility improvements via the tabindex attribute, I'm 
not really dealing with AT. 

I also don't think the group has ever resolved how <blink> and <marquee> 
fit into this category?  Is "specification" generic enough to include 
documentation where the <blink> and <marquee> are introduced?    I am 
going beyond scripting issues here but I think this has implications for 
the use of scripting since it often pushes the envelope with respect to 
specifications.   For example, what about the javascript: URI that is 
often used with the anchor tag href attribute? It, and other URIs  are not 
in a W3C spec but have become somewhat of a defacto standard.   If I know 
that javascript is in my baseline and my page won't run without it, are 
javascript: uris allowed? 
<end guideline 4.1>

<begin guideline 4.2>

Even though I have attended the recent meetings, I'm not entirely sure of 
the current proposal for Guideline 4.2. At the May 19 meeting there were 
modifications suggested that have not made it to the list yet.   There are 
certainly scripting baseline implications in the SC for this GL but I 
think those are well represented and discussed at the meetings so I am 
going to skip them here.
<end guideline 4.2>


[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0248.html





Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com