- From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- Date: Sun, 7 Dec 2003 18:30:58 +0000
- To: Charles McCathieNevile <charles@sidar.org>
- Cc: Phill Jenkins <pjenkins@us.ibm.com>, w3c-wai-ig@w3.org
Being in conformance does not necessarily mean that you are in fact more accessible. In law it would be hard to imagine but not unlikely that conformance had a higher authority :-( It is realistic to imagine situations where certain user groups can be defined, who need scripting. and in this case it is realistic to determine that there may not currently be an accessible alternative. A rather fundamental example is drop down lists, there is still no generally agreed example that has been standardised as accessible. In fact it is possible that able sighted users with touchscreens, may require a significantly different navigational structure to others. One example we have pursued is here: http://www.peepo.co.uk/links/index2.svg <Title> is used with scripting, so that touchscreen users have access to links that mouse and screen reader users would hear or read as descriptions of links. This considerably reduces the mean number of tabs or mouse movements required per link desired. Gosh can I define that as a measure or 'peepo', or did someone else? another example would be most online games necessitate the use of more interactivity than vanilla html provides. To insist that a no-script version of such a page, makes the page conform may be true, but has little value. what one wants are games that are accessible, which is very different. In truth it has to be said that much scripting is redundant, and in many cases it is realistic, easy and good practice to provide no-script default values. The updating of the current rather old de-facto authority on accessible scripting is long overdue: http://www.learningdifficulty.org/develop/script-techs.html and merely quoting the current WCAG guideline does this a gross disservice. thanks On Sunday, December 7, 2003, at 05:33 am, Charles McCathieNevile wrote: > > (apologies to Joe for the top response and the extensive quote) > > It's pretty simple to work out the conformance issue for WCAG. > Checkpoint 6.3 says, in lay terms, > > Make sure the page works when scripts are turned off. > > So if the page doesn't work without scripts, you are not in > conformance with that checkpoint. Which means you cannot meet any of > the defined conformance levels of WCAG. > > As Phill says, many assistive technologies can handle Javascript. When > it is used correctly, many users of assistive technologies can handle > what happens, so they activate Javascript. This is why there are two > requirements - one for those who use a technology that does not handle > javascript, and one for people who are using javascript-capable > systems. (Checkpoint 8.1 also applies to Java applets, Flash movies, > and so on, because again there are people with Java- or Flash- capable > systems who will have it enabled by default, but this isn't the case > for everyone. And WCAG is a list of checkpoints, which sometimes > discuss overlapping areas because there are overlapping needs in the > universe. Conformance is clearly defined as meeting each > checkpoint...) > > There is another question, which the WCAG group has been discussing - > is it still necessary to assume that some people will not have > Javascript activated? > > Certainly there are people who use systems which are not > script-capable (such as blindux, braillesurf, a japanese system whose > name I don't know, and a number of others). There are also people who > turn off scripting support - in some cases for reasons unrelated to > accessibility. For the WCAG group, then, the important question is "is > there a valid accessibility reason to ensure that these systems are > taken into account?". > > In your case, if you need to conform to WCAG the answer is simple. > There is no provision in WCAG for ignoring a checkpoint because a > client doesn't like it, or because you think it is badly framed - if > you don't meet the checkpoints you're not in conformance. (You can > ignore them if they deal with features that you don't have on your > site - for example if there are no forms or form-type interactions on > your site then labelling form controls is not applicable to you). > > I think the 508 situation is more complex, but since I so very rarely > deal with the US federal government I have stopped getting involved > with it. I do recall thinking a couple of years ago that the standard > interpretation of this issue and section 508 seemed more focussed on > what people thought it should say than on the actual text, but that > the text wasn't that clear anyway. > > Cheers > > Chaals > > On Saturday, Dec 6, 2003, at 03:55 Australia/Melbourne, Phill Jenkins > wrote: > >>> Would it be possible to use Remote Scripting and still retain >>> compliance? Can assistive technologies handle it? >> >> Yes, and many assistive technologies handle client-side scripting >> (e.g., >> IBM Home Page Reader, JAWs, magnifiers, etc.). One of the few that I >> know >> of that doesn't is the LYNX browser. If you call that an assistive >> technology, I call it a non scripting capable browser. In my mind, >> scripting is not a disability issue per se, its what authors do with >> it >> that may or may not cause problems. Just like HTML or GUI programs, >> both >> can and cannot be made accessible, it depends on what the author does. >> >> Others claim that if scripting doesn't work with their configuration, >> then >> it isn't accessible to them. True, but then they are mixing the >> disability >> issue with the user's configuration, affordability, or security >> preference >> and not really addressing the capability of a user with a disability >> and a >> supported browser and assistive technology - which is what many refer >> to as >> "technical accessibility". If all the employees in the State, >> Bureau, etc. >> have access to a capable browser & assistive technology, then the >> client >> side scripting can (and should) be made directly accessible to them. >> >> WCAG 1.0 Checkpoint 8.1 [see note 1] requires the direct >> accessibility of >> scripting results, which is viewed by many to be equivalent to the >> Section >> 508 Web part paragraph L [see note 2]. > >> Interesting to see that many see a conflict, or at least an oddity >> between >> WCAG 1.0 Checkpoint 6.3 and 8.1. In other words, why does one need >> to meet >> 8.1 if the site already works without scripting by meeting 6.3? > > Jonathan Chetwynd http://www.peepo.co.uk "A web by people with learning difficulties"
Received on Sunday, 7 December 2003 13:25:25 UTC